Arquitectura

De arriba abajo: dominio del producto, ecosistema e IA, una capa de línea de producto y, por último, el kernel y el sistema de diseño. Los adaptadores de Firebase se enlazan en la raíz de composición.

• Capa de dominio del producto

  Solo funcionalidades verticales, en lib/features/<vertical>/ de cada repositorio de producto: garage, patients, flights. Nunca en paquetes compartidos.

• Capa de ecosistema

  After ID, After+, el bus de eventos, las API entre productos y los servicios compartidos. Los productos se comunican a través de este tejido, nunca con imports entre hermanos.

• Capacidades de IA

  Una sola plataforma de IA con capacidades modulares: conversación, OCR, visión, resumen, llamadas a herramientas y más. Los productos las activan o desactivan; no incluyen stacks de IA propios.

• Módulos consumer

  Capa B2C ligera: puente de membresía, catálogo de funcionalidades consumer, bóveda personal, consentimiento de lanzamiento y ubicación regional. Referencia: SuperGarage.

• Módulos enterprise

  Catorce puertos B2B —organización, RBAC, workflow, tareas, calendario, documentos, mensajería, informes, auditoría, sincronización offline—, cada uno con un mock en memoria. Referencia: SuperHospital.

• Kernel compartido

  Auth, red reforzada, almacenamiento, DI con Riverpod, flags, configuración remota, SDK de IA BYOK, derechos premium, notificaciones, deep links y los motores de dashboard, plugins, búsqueda y ajustes.

• Sistema de diseño

  Una sola familia visual para consumer y enterprise: tokens de color, espaciado, radio, movimiento y tipografía, más componentes compartidos.

• Adaptadores de Firebase

  Firebase Auth, sincronización de blobs en Firestore y de medios en Storage detrás de puertos de after_core. Se enlazan solo en la raíz de composición; el código de dominio nunca importa Firebase.

Las dependencias solo apuntan hacia abajo. Los productos se comunican entre sí mediante eventos y API seguras en la capa de ecosistema. Añadir un dominio añade un módulo en la capa superior y deja este diagrama igual.

• SuperGarage es la referencia consumer; SuperHospital es la referencia enterprise.
• Los módulos sectoriales y verticales viven solo en repositorios de producto.
• Los módulos de SO compartidos viven solo en after_core, after_consumer y after_enterprise.
• Generar, no empezar de cero.
• Puertos antes que SDK.
• Prima la identidad de familia: chrome, movimiento, densidad, splash y shell son idénticos.
• Cada puerto incluye una implementación mock.

Todos los productos, consumer o enterprise, arrancan con la misma secuencia.

main.dart
  → PlatformConfig.current = manifest
  → ProviderScope(overrides: After*Overrides…)
  → ColdStart (OVERSTEIN splash)
       → AuthGate
            → ProductShell (tabs from platform + spec)
                 → Home = Dashboard Engine (+ plugins)
                 → OS modules = platform screens
                 → Vertical = product feature modules only