Backend, autenticación y publicación
Ejecución y rutas
Las entradas api delegan en archivos .mjs generados desde los servicios TypeScript de server. package.json ejecuta build-mcp-runtime.cjs antes de Vite. En desarrollo, el plugin de vite.config.ts conecta los mismos servicios mediante middleware. No hay un servidor Express general arrancado por npm run dev; la presencia de la dependencia Express no demuestra esa topología.
| Entrada | Responsabilidad y fuente |
|---|---|
/api/publish |
Publicar el borrador guardado: publish.ts. |
/api/publication, /llms.txt |
Lectura pública y representación de publicaciones: publication.ts. |
/api/admin, /api/promotion |
Administración, controles y promoción: runtime.ts, promotion.ts. |
/api/collaboration |
Acceso compartido y operaciones: runtime.ts, service.ts. |
/api/billing, /api/funnels |
Facturación y embudos: runtime de billing, runtime de funnels. |
/api/mcp, /api/connections, OAuth y metadatos |
Transporte, herramientas, consentimiento y conexiones: runtime.ts, transport.ts, oauth.ts. |
Las reescrituras exactas están en vercel.json. La tabla agrupa responsabilidades; no sustituye las operaciones y validaciones de cada manejador.
Autenticación y autorización
El cliente usa Firebase Auth mediante AuthContext. Para publicar, serverPublisher.ts envía Authorization: Bearer con un ID token. Los servicios usan Firebase Admin; por ejemplo admin/runtime.ts verifica el token con comprobación de revocación y propaga uid y el claim admin. La autorización administrativa y la de colaboración se validan en sus servicios, no por ocultar botones.
MCP tiene además su propio flujo OAuth: clientes, concesiones y tokens en auth. No debe confundirse un token OAuth de una conexión con la sesión Firebase del editor. El runtime comparte infraestructura Admin y ofrece herramientas por dominio; no constituye un servicio desplegado independiente por cada carpeta.
Guardar, publicar y visitar
- La sesión escribe su copia local y coordina el guardado remoto. firestoreRepository.ts exige la revisión remota esperada en una transacción.
- El cliente envía identificador y revisiones esperadas a
/api/publish. El servidor lee el proyecto guardado; no publica un documento arbitrario enviado en esa solicitud. - publishSavedSite comprueba propiedad o rol compartido, derecho de plataforma, control administrativo, estructura, slug y revisiones. Dentro de la transacción crea/actualiza
published_sites/{slug}y metadatos de publicación. - publishedSites.ts solicita
/api/publication?site=.... Para un dominio consulta primerodomain_mappings. El manejador público vuelve a consultar el control administrativo antes de devolver contenido. El visor React renderiza el resultado; publicar no genera necesariamente un despliegue Vercel por sitio.
La exportación de código es otro flujo: codeGenerator.ts genera HTML y el dominio MCP incluye vercel-export.ts. Exportación, publicación del snapshot y despliegue del producto tienen efectos diferentes.
Alcance operativo
Las credenciales, dominios, estado de proveedores y revisión desplegada requieren comprobación operativa adicional. La migración Functions de PR #93 está separada, pendiente y no desplegada; las rutas anteriores reflejan esta base, no aquella migración. Véase visión general.