WookcomDocsIr a Wookcom ↗

Separación inicial de Wookcom — referencia histórica

Documento histórico de la separación inicial. Describe una fase anterior, no el estado funcional actual de main en 0e6c41f. En particular, la limitación del panel a inicio de sesión, perfil y cierre de sesión ya no corresponde al código actual: ownerConsole.js incorpora gestión de clientes, publicaciones, facturación, promoción y actividad, con servicios en server/admin y server/billing. Las URLs que siguen son referencias registradas durante esa fase y no acreditan destinos o disponibilidad actuales.

Para la arquitectura vigente consulta visión general, backend, funcionalidades y despliegue. La separación de directorios y la necesidad de validar permisos en servidor siguen siendo relevantes; las propuestas de evolución y comprobaciones siguientes conservan su contexto histórico.

Objetivo y alcance histórico

Tres aplicaciones publicadas por separado comparten únicamente servicios centrales de Firebase. El sitio comercial presenta el producto y envía al constructor. El constructor conserva sus proyectos, rutas de sitios publicados y APIs actuales. La administración permite iniciar sesión, ver el perfil de un administrador y cerrar sesión; no incorpora métricas, gestión de usuarios ni configuración todavía.

Aplicación Directorio Despliegue Acceso
Sitio comercial apps/marketing Proyecto Vercel independiente, estático Público
Constructor y publicaciones existentes raíz del repositorio Proyecto Vercel editor-web existente Firebase Auth para edición; sitios publicados públicos
Administración apps/admin Proyecto Vercel independiente, Vite Firebase Auth + custom claim admin: true

Enlaces de producción: venta https://wookcom-ventas.vercel.app/, constructor https://editor-web-eta.vercel.app/, administración https://wookcom-panel.vercel.app/.

No se cambian los slugs ni se trasladan documentos published_sites. La URL pública del constructor sigue resolviendo ?site=...; cambiar el host de los sitios publicados requiere una migración de enlaces distinta.

Datos y autorización

Firebase Auth es la identidad compartida. Firestore sigue siendo el almacenamiento del constructor y de sus módulos (form_sites, course_sites y datos comerciales). Un documento de perfil editable por un usuario no concede acceso administrativo. El panel verifica un ID token actualizado y exige admin === true; se niega acceso a cuentas sin ese claim. Las operaciones administrativas futuras necesitarán validar ese mismo claim en el servidor y en reglas de Firestore, además de la comprobación visual. Nunca se confía en una variable de entorno VITE_ ni en un correo para otorgar privilegios.

El administrador se asigna exclusivamente con Firebase Admin SDK desde un entorno de confianza: se obtiene el usuario por UID, se comprueba su correo, se conservan claims existentes y se establece admin: true. No se publica un endpoint de autoconcesión ni se guarda un token de servicio en el repositorio. Google Sign-In requiere autorizar el dominio del nuevo panel en Firebase Auth; el acceso con correo y contraseña funciona para cuentas con ese proveedor habilitado.

Con credenciales de servicio disponibles de forma privada, ejecuta node scripts/grant-admin-role.mjs <uid> <correo-confirmado> desde la raíz. El script valida ambos identificadores antes de conceder el rol. No ejecutes esta operación con un correo inferido de un formulario o de un sitio publicado.

Módulos y evolución

En esta fase el constructor continúa como monolito modular. Editor, formularios, cursos y comercio conservan sus datos y lógica actuales, sin migración destructiva. El catálogo de cursos ya utiliza un manifiesto tipado registrado en src/modules/registry.ts; los módulos existentes de formularios y comercio se migrarán gradualmente a este contrato. Un bus de eventos local entrega eventos después de acciones confirmadas y aísla errores de suscriptores; no reemplaza operaciones persistentes ni entrega transaccional entre servicios. Una compra que concede acceso deberá usar una operación de servidor idempotente, no un evento en el navegador como fuente de verdad.

Cuando un módulo requiera escalado independiente, su adaptador de almacenamiento y sus endpoints podrán separarse. Se conservará el contrato público, se migrarán los datos con verificación y se cambiará el adaptador; no se crea una base de datos ni un broker adicional en esta fase.

Publicación y verificación

Cada proyecto de Vercel apunta a su propio directorio del mismo repositorio y tiene su propia compilación y URL. Vercel puede iniciar compilaciones de los tres proyectos para un mismo commit, aunque los artefactos y las versiones publicadas sean independientes. Verificar: constructor y una publicación existente; página comercial y CTA; panel sin sesión, cuenta sin claim, cuenta con claim y cierre de sesión. La configuración inicial del claim y el dominio autorizado de Google requieren acceso administrativo a Firebase.