ESPECIFICACIÓN FASE 4-B/C/D + 4-F/4-G

Panel de Licencias + Multi-contexto + Respaldos Centrales + Reorganización de Navegación + Panel de Control + Gobernanza + Correcciones de la Matriz Forense

1. Contexto y Principios de Negocio

• Fase 4-A (RLS real) clausurada con evidencia adversaria (18/18).
• Modelo de negocio cerrado: Licencias operativas por correo.
  • 1 correo = 1 licencia = 1 condominio administrado.
  • Administradores NO tienen selector multi-condominio.
  • Residentes son free con accesos configurados por su administrador.
  • Selector multi-contexto SOLO para usuarios con múltiples roles/condominios (ej: admin en Z + residente en X).
  • Infraestructura del superadmin (Supabase, Resend, Vercel).
• Decisión confirmada: El socio-propietario administrará 1 solo condominio con su correo. El #2 lo administrará su colaboradora con otro correo.

2. Estado de Ejecución por Bloques (Auditoría en Tiempo Real)

Bloque	Descripción	Prioridad	Estado Actual
Bloque 1	Bugs de hallazgos de matriz forense (B1, B3, B6)	P1	COMPLETADO
Bloque 2	Reestructuración de navegación y configuración (N1, N2, N3, N4)	P2	COMPLETADO
Bloque 3	Gobernanza de respaldos centrales (H1, H2, H3, H4)	P3	COMPLETADO
Bloque 4	Branding y textos de correos (E1, E2, E3)	P4	COMPLETADO
Bloque 5	Documentación de identidad y gobernanza (G1, G2, G3)	P5	COMPLETADO
Bloque 6	Acceso a respaldos locales exclusivo del superadmin (J1)	P6	COMPLETADO
Bloque 7	Modelo de licencias y selector multi-contexto (L1, L2, L3, L4, L5)	P7	COMPLETADO
Fase 4-D.1	Restauración de condominio individual desde JSON desde Cockpit	P1	COMPLETADO

---

Detalle de Bloques y Estado por Ítem

═══ BLOQUE 1 — BUGS DE HALLAZGOS DE LA MATRIZ FORENSE ═══ [Estado: COMPLETADO]

• BUG B1 — Panel de Control: "En memoria" + condominio en blanco hasta F5: [COMPLETADO]
  • [x] Etiqueta "En memoria" reemplazada por "Activo en sesión" con styling discreto.
  • [x] Loading state explícito en carga de Cockpit que consulta Supabase antes de renderizar y filtra entidades fantasma no hidratadas.
• BUG B3 — Suspensión de licencia: no propagada en vivo + texto superpuesto + política de 30 días: [COMPLETADO]
  • [x] Pantalla informativa SuspendedLicenseScreen implementada.
  • [x] a) Verificación periódica en vivo (intervalo polling cada 2 min y en visibilitychange a visible) en App.tsx para expulsar la sesión activa de un administrador suspendido sin requerir F5.
  • [x] b) Corrección de CSS en encabezado de correo de suspensión mediante tabla de presentación y espaciado explícito para impedir colisión/superposición.
  • [x] c) Texto formal en correo de suspensión: "Tus registros contables, adeudos, cobros y comprobantes se conservarán íntegros durante 30 días desde la suspensión; después de ese plazo serán eliminados definitivamente si la licencia no es reactivada."
• BUG B6 — Aviso de borrado de condominio distingue mal administradores vinculados: [COMPLETADO]
  • [x] Modal de borrado con confirmación de frase estricta ("Deseo eliminar el condominio").
  • [x] Distinción explícita de los 3 casos en el modal:
    • (a) Cuentas de residentes y directorio asignadas a este condominio serán eliminadas.
    • (b) Cuentas de administradores con licencia serán desvinculadas (condo_id -> null).
    • (c) Superadmins globales permanecen intactos sin alteración.
  • [x] Advertencia textual requerida: "Esta acción es definitiva e irreversible — NO existe restauración automática del conjunto. La recuperación solo sería posible mediante respaldos previos del superadmin."

═══ BLOQUE 2 — REESTRUCTURACIÓN DE NAVEGACIÓN ═══ [Estado: COMPLETADO]

• N1. Trasladar al panel derecho del administrador (AdminRightDrawer): [COMPLETADO]
  • [x] "Invitaciones y Accesos de Residentes" (onboarding de residentes) - visible admin y superadmin.
  • [x] "Cobranza Masiva: Estados de Cuenta por Correo" (cobranza mensual) - visible admin y superadmin.
  • [x] Opciones de sincronización en la nube (Wipe & Re-upload, sincronización manual, descarga de datos frescos).
  • [x] Conectados modales en App.tsx y accesibles directamente desde el Drawer.
• N2. Eliminar definitivamente de Configuración: [COMPLETADO]
  • [x] "Cargar datos demo" eliminado.
  • [x] "Borrar todo" eliminado.
  • [x] Duplicado de Historial de Acciones eliminado (accesible exclusivamente en panel/drawer).
• N3. Cambiar de condominio / Nuevo condominio: [COMPLETADO]
  • [x] Solo existe para el Superadmin en el Panel de Control.
  • [x] Eliminado de la vista de Configuración de administradores de licencia.
• N4. Estructura final de Configuración: [COMPLETADO]
  • [x] Ficha del condominio limpia con branding, RUC, dirección, teléfono institucional, aclaración de correo institucional y accesos directos a módulos.

═══ BLOQUE 3 — GOBERNANZA DE RESPALDOS CENTRALES ═══ [Estado: COMPLETADO]

• H1. Eliminar opción de RESTAURAR respaldo central de la UI: [COMPLETADO]
  • [x] Interfaz de CentralBackupsModal solo permite crear respaldo manual y descargar.
  • [x] Eliminada cualquier función de restauración directa de snapshots globales.
• H2. Descarga como ZIP multi-condominio: [COMPLETADO]
  • [x] Descarga client-side en formato .zip que contiene un archivo .json independiente por cada condominio y _manifest.json utilizando jszip.
• H3. Retención automática: [COMPLETADO]
  • [x] Respaldos automáticos daily_automated implementados en servicio.
  • [x] Política de retención de los últimos snapshots y script SQL de purga accesible desde la UI y documentado.
• H4. Documentación: [COMPLETADO]
  • [x] Documentada en /docs/ARQUITECTURA-RESPALDOS-Y-GOBERNANZA.md la persistencia JSONB en la tabla central_backups, RLS exclusivo y descarga en ZIP/JSON.

═══ BLOQUE 4 — BRANDING Y TEXTOS DE CORREOS ═══ [Estado: COMPLETADO]

• E1. Título de correos: [COMPLETADO]
  • [x] Reemplazado "Portal de Residentes" por "ITECEL ADM" en asunto y encabezado general.
• E2. Cuerpo del correo: [COMPLETADO]
  • [x] Texto unificado: "La administración de [Condominio] le ha habilitado acceso a ITECEL ADM como [administrador / miembro del directorio / residente]".
• E3. Correo de suspensión: [COMPLETADO]
  • [x] Fix de CSS en encabezado (tabla de presentación contra solapamiento) + advertencia explícita de política de conservación por 30 días.

═══ BLOQUE 5 — DOCUMENTACIÓN DE IDENTIDAD Y GOBERNANZA ═══ [Estado: COMPLETADO]

• G1. Ficha vs Identidad: [COMPLETADO]
  • [x] Banner y documentación en ficha de condominio aclarando el rol de condos.email (correo de contacto público/institucional) vs app_users.email / auth.users (identidad de autenticación RLS).
• G2. Historial local por diseño: [COMPLETADO]
  • [x] Documentado en docs/ARQUITECTURA-RESPALDOS-Y-GOBERNANZA.md y banner en ActionHistoryModal que los puntos de restauración son snapshots locales por diseño para evitar colisiones multi-usuario.
• G3. Trazabilidad [Superadmin]: [COMPLETADO]
  • [x] Documentada la auditoría inmutable de acciones del operador superadmin en docs/ARQUITECTURA-RESPALDOS-Y-GOBERNANZA.md.

═══ BLOQUE 6 — ACCESO A RESPALDOS LOCALES: EXCLUSIVO DEL SUPERADMIN ═══ [Estado: COMPLETADO]

• J1. Restricción: [COMPLETADO]
  • [x] En ActionHistoryModal: La descarga de archivo JSON local y la restauración de copias JSON externas están condicionadas a isSuperadmin.
  • [x] Administradores ordinarios únicamente visualizan y aplican sus puntos de restauración automáticos locales.

═══ BLOQUE 7 — MODELO DE LICENCIAS Y SELECTOR MULTI-CONTEXTO ═══ [Estado: COMPLETADO]

• L1. Creación de licencia + condominio nuevo en 1 paso: [COMPLETADO]
  • [x] En LicensesPanelModal, el selector de condominio incluye condominios libres y la opción "+ Crear nuevo condominio" para aprovisionar propiedad y licencia de forma atómica con rollback en caso de error.
• L2. Check de invitación obligatorio: [COMPLETADO]
  • [x] Checkbox "Enviar correo de invitación" siempre activo y bloqueado (disabled) para impedir desmarcarlo.
• L3. Logo configurable en correos: [COMPLETADO]
  • [x] Opciones includeCondoLogoInEmails e includeItecelLogoInEmails implementadas en CondoProfile y en ficha de Configuración.
• L4. Selector multi-contexto: [COMPLETADO]
  • [x] Pantalla UserContextSelectorScreen cubre todos los casos de usuarios con múltiples roles o condominios.
• L5. Nota en TECHNICAL_DEBT: [COMPLETADO]
  • [x] Registrada deuda técnica en docs/TECHNICAL_DEBT.md y docs/DEUDA-TECNICA.md para futura sincronización diferencial.

═══ FASE 4-D.1 — RESTAURACIÓN DE CONDOMINIO INDIVIDUAL DESDE ARCHIVO JSON LOCAL (COCKPIT) ═══ [Estado: COMPLETADO]

• D1. Ubicación y Acceso: [COMPLETADO]
  • [x] Integrado en SuperadminCockpitScreen (tarjeta de respaldos y barra de herramientas). Exclusivo de superadmin.
• D2. Flujo y Detección: [COMPLETADO]
  • [x] Carga de archivo JSON individual con FileReader y parsing con deserializeCondoState.
  • [x] Detección de condominio (ID, nombre, viviendas, secciones, adeudos, pagos, gastos, proveedores, cuentas, movimientos).
  • [x] Modal de confirmación con detalle de entidades y advertencia de reemplazo en la nube.
• D3. Seguridades Obligatorias (Doble Seguridad): [COMPLETADO]
  • [x] Respaldo central previo automático del estado completo de la nube como punto de retorno antes de tocar datos.
  • [x] Verificación de paridad post-restauración en Supabase (cotejo 1:1 de conteos por tabla en postgrest con reporte visual).
• D4. Mecánica y Reutilización: [COMPLETADO]
  • [x] Reutilizadas supabaseDeleteCondoCascade (limpieza topológica de ese condominio únicamente) y supabaseSyncFullCondo (re-upload del motor unificado).
  • [x] Aislamiento total: otros condominios permanecen intactos.
  • [x] Re-vinculación de licencia en app_users si existe licencia asignada.
• D5. Casos Cubiertos: [COMPLETADO]
  • [x] Condominio existente en Supabase -> reemplazo con punto de retorno automático.
  • [x] Condominio nuevo -> carga limpia.
• D6. Comportamiento para Operadores: [COMPLETADO]
  • [x] El operador asignado no requiere acciones forzadas; en su próxima sincronización o recarga recibe el estado restaurado desde Supabase vía RLS.