Componentes de la instalación y separación de modos
EMP se compone de un frontend Next.js con proxy de servidor que protege el origen y las cookies HttpOnly, una API NestJS que valida la identidad y ejecuta la lógica de dominio, y un proceso worker independiente que consume la cola transaccional durable (outbox) para despachar efectos hacia Meta, Google, CalDAV, proveedores de IA y avisos salientes.
El sistema admite una demostración local explícita en memoria para recorridos visuales y un modo persistente respaldado por PostgreSQL y Supabase Auth. En producción (NODE_ENV=production) la aplicación exige persistencia real y rechaza cualquier intento de acceso demo.
Contratos de seguridad, aislamiento SQL y cifrado en servidor
Toda consulta o mutación de negocio atraviesa controles de autorización e integridad transaccional que impiden cruzar datos entre negocios.
| Capa | Mecanismo aplicado | Qué previene en operación |
|---|---|---|
| Autenticación y tenant | JWT verificado de Supabase Auth + selección de membresía almacenada vía x-tenant-slug. | Ignora cualquier cabecera x-role o tenantId enviado en el cuerpo como fuente de permisos. |
| Base de datos PostgreSQL | ApplicationRepository.transaction con rol restringido mr_calendar_app, RLS y tenantLock en mutaciones. | Aísla cada negocio a nivel de fila, serializa mutaciones críticas y prohíbe privilegios a roles anon/authenticated. |
| Cifrado y navegador | Secretos cifrados con AES-256-GCM en servidor; el frontend solo importa @mr-calendar/shared/browser. | Evita filtrar claves privadas, tokens OAuth o código criptográfico de servidor en el bundle del cliente. |
Alcance de los conectores y cómo verificar cambios
EMP ofrece conectores acotados y avisos firmados dentro del producto; no expone un portal público de API abierta para terceros sin membresía. Todo cambio de arquitectura debe verificarse ejecutando chequeo de tipos, pruebas unitarias y de aceptación, build de producción, smoke de API, probe de salud del worker y pruebas sobre PostgreSQL temporal con recuperación de respaldo cifrado.
Antes de continuar
- Deriva siempre identidad y rol desde el JWT verificado y la membresía en base de datos.
- Ejecuta todas las consultas de negocio dentro de ApplicationRepository.transaction sin paralelizar sobre la misma conexión pg.
- Verifica con transportes simulados y bases PostgreSQL temporales sin realizar llamadas a cuentas reales en pruebas.
La demo conserva datos en memoria. Las conexiones de proveedores requieren configuración, autorización y verificación en tu entorno persistente.