Despliegue y límites operativos
Esta guía describe el árbol inspeccionado; no acredita un despliegue. Las Functions pendientes permanecen sin desplegar y el PR #93 es trabajo separado de main: no asumir que está integrado ni incorporarlo a una entrega documental. No ejecutar despliegues, merges ni cambios de credenciales como parte de actualizar documentación.
| Superficie | Directorio | Preparación local | Destino/configuración |
|---|---|---|---|
| Constructor, sitios públicos y APIs Node | raíz | bun install --frozen-lockfile, npm run build |
Proyecto Vercel del editor; vercel.json, adaptadores api, salida cliente dist. |
| Panel administrativo | apps/admin |
npm --prefix apps/admin ci, npm --prefix apps/admin run build |
Proyecto Vercel propio, raíz apps/admin; salida dist relativa a esa raíz. |
| Sitio comercial | apps/marketing |
Archivos estáticos; sin script build | Proyecto Vercel propio, raíz apps/marketing; configuración local vercel.json. |
| Reglas Firestore | firestore.rules |
npm run test:rules |
firebase.json declara una base con nombre y reglas; cambio independiente de frontend. |
El workflow de verificación no contiene un paso de despliegue. Las conexiones Git, ramas productivas, variables y destinos efectivos de Vercel deben verificarse en el alojamiento; no se deducen de un build local. No hay script npm deploy, configuración de Firebase Hosting ni sección functions en firebase.json. Las APIs Node existentes de Vercel no demuestran que las Firebase Functions pendientes estén publicadas. No existe en este árbol una receta verificable para desplegar esas Functions.
Antes de una entrega autorizada, identificar commit, rama, proyecto de alojamiento y entorno; revisar resultados de CI y variables sin copiar secretos; preparar por separado los tres artefactos necesarios. Para MCP seguir su orden de activación: reglas protectoras, credencial Admin, configuración, runtime y descubrimiento coherentes. No publicar metadatos de un issuer distinto al runtime.
Después de una entrega autorizada, comprobar la URL real y el commit servido, acceso al editor, publicación de prueba autorizada, CTA comercial y panel con/sin claim. Probar APIs y OAuth como JSON/protocolo, no solamente que la SPA cargue. Las verificaciones locales no acreditan conexiones reales con clientes externos.
Reversión: seleccionar una versión previamente verificada en cada proyecto afectado; preservar datos y reglas que protegen historial. No revertir reglas a una variante insegura para acompañar un frontend antiguo. DNS/TLS y migraciones de dominios tienen guías específicas en despliegues y wildcard; sus notas son históricas y requieren comprobar el estado remoto actual.