After Framework

Crea productos sobre un framework operativo compartido.

Construye una vez. Lanza en todos los dominios.

After Framework da a los productos una base compartida: arquitectura, identidad, IA, sistemas de diseño, herramientas y módulos de dominio reutilizables.

supercore/packages7 paquetes · 2 líneas de producto · 1 contrato de composición
SuperGarageAfterHubSuperHospitalafter_ecosystemafter_aiafter_consumerafter_enterpriseafter_firebaseafter_coreafter_design_system
Leyenda:dependencia de pubspecstack de referencia documentado

01 · Arquitectura del framework

Un kernel. Dos líneas de producto. Productos ligeros encima.

Todos los productos comparten las mismas capas. Añadir un Life Domain o un Industry Domain añade un módulo arriba; las capas inferiores no cambian.

Específico del producto

Plataforma compartida

Adaptadores de la raíz de composición

Selecciona una capa para ver qué le pertenece y de qué depende.

after_core

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.

Depende de
Ninguna: capa base
Usado por
Capa de dominio del producto · Capa de ecosistema · Capacidades de IA · Módulos consumer · Módulos enterprise · Sistema de diseño · Adaptadores de Firebase

Reutilización compartida, experiencia propia

La doctrina de la plataforma apunta a que cada producto herede un noventa por ciento o más de su capacidad en tiempo de ejecución. Un producto posee su dominio, funcionalidades verticales, perfil de IA, catálogos y marca; nada más.

Reglas que sostienen el sistema

  1. 01Puertos antes que SDK: el código vertical depende de interfaces de After, nunca de SDK de proveedores.
  2. 02Los módulos verticales viven solo en repositorios de producto, en lib/features/.
  3. 03Cada puerto incluye un mock, así los scaffolds funcionan sin backend.
  4. 04Generar, no empezar de cero: los productos nuevos parten de una spec, no de una arquitectura nueva.

02 · Fábrica de productos

De la idea al producto funcional sobre una base reutilizable.

La fábrica de productos convierte un pequeño product.spec.yaml en una app Flutter hermana que depende de los paquetes compartidos. La spec contiene solo lo exclusivo del producto.

  1. 01

    Idea

    Nombra el producto y elige una línea: consumer o enterprise, con SuperGarage o SuperHospital como referencia.

  2. 02

    Dominio

    Escribe product.spec.yaml: dominio, funcionalidades verticales, pestañas, permisos, widgets de dashboard, habilidades de IA, marca, idiomas.

  3. 03

    Módulos

    Todo lo que no está en la spec —auth, membresía u organización, RBAC, calendario, tareas, notificaciones, búsqueda— se hereda.

  4. 04

    Shell del producto

    generate_product.ps1 genera el manifiesto, la raíz de composición, el catálogo de funcionalidades, el shell, los archivos l10n y un workflow de CI.

  5. 05

    Despliegue

    El workflow de CI generado ejecuta formato, análisis y tests con cobertura en cada push y pull request a main.

El producto posee

  • Nombre, paquete, bundle, línea de producto
  • Funcionalidades verticales y claves i18n
  • Pestañas de navegación
  • Cadenas de permisos RBAC
  • Widgets de dashboard
  • Habilidades de IA y enlaces a herramientas
  • Color de acento y monograma

La plataforma aporta

  • Auth y superadmin
  • Membresía u organización
  • Motor RBAC y registro de auditoría
  • Calendario, tareas, documentos
  • Notificaciones y analítica
  • Motores de workflow, dashboard y búsqueda
  • Sistema de diseño, splash, CI

Volver a ejecutar el generador con una spec actualizada renueva los archivos esqueleto sin destruir el código de funcionalidades escrito a mano.

03 · Paquetes y capacidades

Siete paquetes. Dependencias explícitas.

Todos los paquetes están en la versión 1.0.0 en el repositorio supercore y se consumen mediante dependencias de ruta. Selecciona un paquete para ver de qué depende y qué depende de él.

Kernel compartido

after_core

Puertos e implementaciones por defecto para auth, red, almacenamiento, DI, analítica, feature flags, configuración remota, IA, notificaciones, deep links y derechos premium. Los productos sobrescriben providers de Riverpod con sus propios adaptadores.

Depende de
Ninguna: capa base
Usado por

API clave

  • AppPlatformManifest
  • PlatformConfig
  • AfterStandardOverrides
  • AfterBootstrapMode
  • AfterAuthRepository
  • AfterApiClient
  • AfterHttpClientFactory
  • AfterFeatureFlags
  • AfterRemoteConfig
  • AfterAiCredentialVault

Dependencias de terceros destacadas

flutter_riverpod · dio · flutter_secure_storage · shared_preferences · google_sign_in · app_links · flutter_local_notifications

after_ecosystemafter_aiafter_consumerafter_enterpriseafter_firebaseafter_coreafter_design_system

Ejemplo

dart
import 'package:after_core/after_core.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:shared_preferences/shared_preferences.dart';

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  final prefs = await SharedPreferences.getInstance();

  runApp(
    ProviderScope(
      overrides: [
        afterSharedPreferencesProvider.overrideWithValue(prefs),
        afterAuthRepositoryProvider.overrideWithValue(MyFirebaseAuthRepository()),
        afterAnalyticsProvider.overrideWithValue(MyFirebaseAnalytics()),
        // ... store-specific adapters
      ],
      child: const MySuperApp(),
    ),
  );
}

Fuente supercore/packages/after_core/README.md (se abre en una pestaña nueva)

04 · CLI y flujo de desarrollo

Scripts y comandos de Flutter, sin magia.

Las herramientas viven en supercore/scripts como scripts de PowerShell, junto a la toolchain estándar de Flutter. No existe un binario CLI empaquetado aparte.

Inicializar

Valida una spec sin Flutter y luego genera la app hermana y arráncala.

validate_product_spec.ps1
powershell -File scripts\validate_product_spec.ps1 -SpecPath factory\specs\examples\super_airport.product.spec.yaml

Fuente supercore/factory/README.md (se abre en una pestaña nueva)

generate_product.ps1
# From a spec
powershell -File scripts\generate_product.ps1 -SpecPath factory\specs\examples\super_airport.product.spec.yaml

# From a name only (quick starter)
powershell -File scripts\generate_product.ps1 -Name SuperAirport -Reference SuperHospital

# Preview without writing files
powershell -File scripts\generate_product.ps1 -SpecPath factory\specs\examples\super_airport.product.spec.yaml -DryRun

Fuente supercore/factory/README.md (se abre en una pestaña nueva)

flutter
cd ..\superairport
flutter create .
flutter pub get
flutter analyze
flutter test

05 · Del framework a productos reales

Capacidades compartidas, experiencias propias de cada producto.

SuperGarage es la referencia consumer ya publicada. Cada pantalla es una captura real de la tienda; la superposición indica qué viene de la plataforma y qué es del producto.

Captura de SuperGarage: Puntuación de salud del vehículo y recordatorios en el dashboard del garaje.

Mapa de capacidades de SuperGarage

Identificadores importados por supergarage/lib, agrupados por paquete propietario.

after_core

  • AfterUserPlan
  • AfterAiCredentialVault
  • AfterLocalNotifications

after_consumer

  • FamilyShellHeader
  • AfterRegionalLocation

after_firebase

  • AfterFirebaseBootstrap

Funcionalidades del producto

  • features/vehicle
  • features/maintenance
  • features/obd
  • features/expenses
  • features/fleet
  • features/trips
  • features/assistant
  • features/community

Familia de productos

Estado según supercore/catalog/products.yaml. Solo SuperGarage figura como publicado.

  • Icono de SuperGarage

    SuperGarage

    Consumer · Referencia

    Movilidad: vehículos, mantenimiento, seguros, combustible, OBD, flotas

    after_core · after_design_system · after_firebase · after_consumer

  • Icono de AfterHub

    AfterHub

    Consumer · Shell del SO

    Shell de SO consumer: identidad, dashboard, IA, calendario, búsqueda, After+

    Scaffold

    after_ai · after_consumer · after_core · after_firebase · after_design_system · after_ecosystem

  • Icono de SuperHospital

    SuperHospital

    Enterprise · Referencia

    Operaciones hospitalarias: referencia enterprise

    Scaffold
  • Icono de SuperHealth

    SuperHealth

    Consumer

    Salud personal: medicación, historiales, sueño, nutrición

  • Icono de SuperFinance

    SuperFinance

    Consumer

    Finanzas personales: suscripciones, presupuestos, inversiones

    Scaffold
  • Icono de SuperHome

    SuperHome

    Consumer

    Vivienda y hogar: mantenimiento, suministros, garantías

    Scaffold
  • Icono de SuperTravel

    SuperTravel

    Consumer

    Viajes: escapadas, vuelos, hoteles, itinerarios

    Scaffold
  • Icono de SuperPet

    SuperPet

    Consumer

    Mascotas: atención veterinaria, comida, historial de salud

    Scaffold
  • Icono de SuperNews

    SuperNews

    Consumer

    Noticias personalizadas con IA y resúmenes

  • Icono de SuperSports

    SuperSports

    Consumer

    Deporte y rendimiento: fitness, resultados, calendario

  • Icono de SuperAirport

    SuperAirport

    Enterprise

    Operaciones aeroportuarias: vuelos, puertas, pistas

    Scaffold
  • Icono de SuperMaritime

    SuperMaritime

    Enterprise

    Operaciones portuarias y de buques

    Scaffold
  • Icono de SuperFactory

    SuperFactory

    Enterprise

    MES y mantenimiento en planta

    Scaffold
  • Icono de SuperFarm

    SuperFarm

    Enterprise

    Operaciones agrícolas: cultivos, ganado, maquinaria

    Scaffold

06 · Sistema de diseño

Coherencia sin uniformidad.

after_design_system da a todos los productos el mismo chrome, densidad y movimiento. Los productos cambian su acento, monograma, funcionalidades y textos, no el sistema.

Tokens

Color, espaciado, radio y movimiento son constantes de Dart, compartidas por consumer y enterprise.

Color

  • accent#38BDF8
  • accentDeep#0284C7
  • graphite950#0B0C0F
  • graphite800#222831
  • steel#8A919D
  • lightBackground#FAFBFC
  • success#22C55E
  • warning#F59E0B
  • danger#EF4444

Espaciado · escala de 4 pt

  • xs4
  • sm8
  • md12
  • lg16
  • xxl24
  • xxxl32
  • massive48
  • hero64

Radio

  • 6
  • 8
  • 12
  • 16
  • 20

Movimiento

  • instant100ms
  • fast · micro180ms
  • normal · page280ms
  • slow · modal420ms
  • emphasis560ms

Componentes

Botones, tarjetas, campos, navegación, diálogos, gráficos, dashboard, estados vacíos y de carga, secciones de ajustes y la barra superior del shell.

  • buttons.dart
  • cards.dart
  • inputs.dart
  • navigation_bar.dart
  • dialogs.dart
  • charts.dart
  • dashboard.dart
  • empty_states.dart
  • loading.dart
  • settings_section.dart
  • shell_top_bar.dart

Accesibilidad

Los esquemas de color claro y oscuro se incluyen juntos. Las series de los gráficos se ordenan para seguir siendo distinguibles, y los tokens de movimiento mantienen transiciones breves y con propósito.

Comportamiento adaptable

El padding de página y el ancho del contenido se adaptan al ancho del viewport mediante AfterSpacing.

Ancho del viewportAncho máx. del contenidoPadding de página
< 360width14 / 10 / 14 / 28
360 – 41952016 / 12 / 16 / 28
420 – 71964020 / 12 / 20 / 28
≥ 72076020 / 12 / 20 / 28

Extensión de marca

Cada spec de producto declara un acento y un monograma. El tema recibe el acento mediante accentOverride; todo lo demás se mantiene en la familia.

  • SuperGarage#22D3EE
  • SuperKids#F472B6
  • SuperHospital#F43F5E
  • SuperFactory#F59E0B

07 · Documentación

Documentación pensada para escanear.

Cada página se deriva del repositorio supercore y enlaza a su archivo fuente.

  • Búsqueda instantánea con atajo de teclado
  • Índice fijo con enlaces profundos
  • Botones de copia y resaltado de sintaxis en ambos temas
  • Páginas de paquetes con grafos de dependencias
  • Diagramas de arquitectura con alternativas estáticas
  • Disponible en diez idiomas, con soporte de derecha a izquierda
Abrir la documentación

08 · Límites enterprise

Límites que fallan de forma cerrada.

El aislamiento enterprise se aplica en el código y se documenta en registros de decisiones de arquitectura.

  • Tenencia fail-closed

    Los puertos enterprise con ámbito de organización exigen un EnterpriseScope. Si falta organizationId se lanza una excepción; nunca devuelven todos los tenants.

  • Permisos antes de persistir

    Las funcionalidades verticales comprueban PermissionSet.allows(...) antes de cualquier llamada que modifique datos. Los productos declaran sus propias cadenas de permisos.

  • Auditoría solo de adición

    Cada acción enterprise que modifique datos debe añadir un AuditLogEntry al AuditLogRepository de solo adición.

  • Solo interoperabilidad segura

    Las llamadas entre productos pasan por AfterSecureInteropBridge: audiencia de After ID, scopes, RBAC y pertenencia a la organización, y luego una entrada de auditoría obligatoria.

  • Arranque fail-fast

    En modo producción, un adaptador ausente lanza una excepción al arrancar, así los providers mock no pueden llegar a producción sin avisar.

  • Modular por diseño

    Los backends reales sustituyen a MockEnterpriseRepository en la raíz de composición. La capa de SO nunca conoce el nombre del proveedor.

enterprise_scope.dart
/// Fail-closed tenant + actor context for enterprise ports (ADR-002).
class EnterpriseScope {
  final String organizationId;
  final String actorId;
  final PermissionSet permissions;

  /// Throws if [organizationId] is missing/blank — never allow all-tenant lists.
  static String requireOrganizationId(String? organizationId) {
    final id = organizationId?.trim() ?? '';
    if (id.isEmpty) {
      throw StateError(
        'EnterpriseScope: organizationId is required (fail-closed tenancy).',
      );
    }
    return id;
  }
}

Fuente supercore/packages/after_enterprise/lib/src/scope/enterprise_scope.dart (se abre en una pestaña nueva)

Estos son controles de arquitectura documentados en el repositorio supercore. After Framework no afirma tener certificaciones ni cumplimiento normativo.

Límites enterprise

Haz el producto más pequeño. Haz la base más sólida.

Empieza por la arquitectura, lee la documentación de los paquetes o explora el código.