After Framework

Crie produtos sobre um framework operacional compartilhado.

Construa uma vez. Entregue em todos os domínios.

O After Framework oferece aos produtos uma base compartilhada: arquitetura, identidade, IA, design systems, ferramentas e módulos de domínio reutilizáveis.

supercore/packages7 pacotes · 2 linhas de produto · 1 contrato de composição
SuperGarageAfterHubSuperHospitalafter_ecosystemafter_aiafter_consumerafter_enterpriseafter_firebaseafter_coreafter_design_system
Legenda:dependência no pubspecstack de referência documentada

01 · Arquitetura do framework

Um kernel. Duas linhas de produto. Produtos enxutos no topo.

Todo produto compartilha as mesmas camadas. Adicionar um Domínio de Vida ou Domínio de Indústria adiciona um módulo no topo — as camadas abaixo não mudam.

Específico do produto

Plataforma compartilhada

Adaptadores da raiz de composição

Selecione uma camada para ver o que ela contém e do que depende.

after_core

Kernel compartilhado

Auth, rede reforçada, armazenamento, DI com Riverpod, flags, remote config, SDK de IA BYOK, direitos premium, notificações, deep links e os motores de dashboard, plugins, busca e configurações.

Depende de
Nenhuma — camada base
Usado por
Camada de domínio do produto · Camada de ecossistema · Recursos de IA · Módulos consumer · Módulos enterprise · Sistema de design · Adaptadores Firebase

Reuso compartilhado, experiência específica do produto

A doutrina da plataforma visa que noventa por cento ou mais dos recursos de runtime sejam herdados por produto. Um produto é dono de seu domínio, features verticais, perfil de IA, catálogos e marca — nada mais.

Regras que mantêm o sistema de pé

  1. 01Ports em vez de SDKs: o código vertical depende de interfaces After, nunca de SDKs de fornecedores.
  2. 02Módulos verticais vivem apenas nos repositórios de produto, em lib/features/.
  3. 03Todo port vem com um mock, então os scaffolds rodam sem backend.
  4. 04Gere, não comece do zero: novos produtos partem de uma spec, não de uma nova arquitetura.

02 · Fábrica de produtos

Da ideia ao produto funcionando sobre uma base reutilizável.

A fábrica de produtos transforma um pequeno product.spec.yaml em um app Flutter irmão que depende dos pacotes compartilhados. A spec contém apenas o que é exclusivo do produto.

  1. 01

    Ideia

    Dê nome ao produto e escolha uma linha: consumer ou enterprise, com SuperGarage ou SuperHospital como referência.

  2. 02

    Domínio

    Escreva o product.spec.yaml: domínio, features verticais, abas, permissões, widgets de dashboard, skills de IA, marca, idiomas.

  3. 03

    Módulos

    Tudo o que não está na spec — auth, assinatura ou organização, RBAC, calendário, tarefas, notificações, busca — é herdado.

  4. 04

    Shell do produto

    generate_product.ps1 gera o manifesto, a raiz de composição, o catálogo de features, o shell, os arquivos de l10n e um workflow de CI.

  5. 05

    Deploy

    O workflow de CI gerado executa formatação, análise e testes com cobertura a cada push e pull request para main.

O produto é dono de

  • Nome, pacote, bundle, linha de produto
  • Features verticais e chaves de i18n
  • Abas de navegação
  • Strings de permissão RBAC
  • Widgets de dashboard
  • Skills de IA e vínculos de ferramentas
  • Cor de destaque e monograma

A plataforma fornece

  • Auth e superadmin
  • Assinatura ou organização
  • Motor RBAC e log de auditoria
  • Calendário, tarefas, documentos
  • Notificações e analytics
  • Motores de workflow, dashboard e busca
  • Sistema de design, splash, CI

Executar o gerador novamente com uma spec atualizada renova os arquivos de esqueleto sem destruir o código de features escrito à mão.

03 · Pacotes e recursos

Sete pacotes. Dependências explícitas.

Todos os pacotes estão na versão 1.0.0 no repositório supercore e são consumidos por dependências de caminho. Selecione um pacote para ver do que ele depende e o que depende dele.

Kernel compartilhado

after_core

Ports e implementações padrão para auth, rede, armazenamento, DI, analytics, feature flags, remote config, IA, notificações, deep links e direitos premium. Os produtos sobrescrevem providers Riverpod com seus próprios adaptadores.

Depende de
Nenhuma — camada base
Usado por

APIs principais

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

Dependências de terceiros relevantes

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

Exemplo

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(),
    ),
  );
}

Fonte supercore/packages/after_core/README.md (abre em uma nova aba)

04 · CLI e fluxo de desenvolvimento

Scripts e comandos Flutter, sem mágica.

As ferramentas ficam em supercore/scripts como scripts PowerShell, junto com o toolchain padrão do Flutter. Não há um binário de CLI empacotado à parte.

Inicializar

Valide uma spec sem Flutter, depois gere o app irmão e faça o bootstrap.

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

Fonte supercore/factory/README.md (abre em uma nova aba)

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

Fonte supercore/factory/README.md (abre em uma nova aba)

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

05 · Do framework a produtos reais

Recursos compartilhados viram experiências específicas de produto.

O SuperGarage é a referência consumer já lançada. Cada tela abaixo é uma captura real da loja; a sobreposição mostra o que vem da plataforma e o que pertence ao produto.

Captura de tela do SuperGarage: Pontuação de saúde do veículo e lembretes no dashboard da garagem.

Mapa de recursos do SuperGarage

Identificadores importados por supergarage/lib, agrupados pelo pacote proprietário.

after_core

  • AfterUserPlan
  • AfterAiCredentialVault
  • AfterLocalNotifications

after_consumer

  • FamilyShellHeader
  • AfterRegionalLocation

after_firebase

  • AfterFirebaseBootstrap

Features do produto

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

Família de produtos

Status conforme registrado em supercore/catalog/products.yaml. Apenas o SuperGarage está marcado como lançado.

  • Ícone de SuperGarage

    SuperGarage

    Consumer · Referência

    Mobilidade: veículos, manutenção, seguro, combustível, OBD, frota

    after_core · after_design_system · after_firebase · after_consumer

  • Ícone de AfterHub

    AfterHub

    Consumer · Shell do SO

    Shell de SO consumer: identidade, dashboard, IA, calendário, busca, After+

    Scaffold

    after_ai · after_consumer · after_core · after_firebase · after_design_system · after_ecosystem

  • Ícone de SuperHospital

    SuperHospital

    Enterprise · Referência

    Operações hospitalares — referência enterprise

    Scaffold
  • Ícone de SuperHealth

    SuperHealth

    Consumer

    Saúde pessoal: medicamentos, prontuários, sono, nutrição

  • Ícone de SuperFinance

    SuperFinance

    Consumer

    Finanças pessoais: assinaturas, orçamentos, investimentos

    Scaffold
  • Ícone de SuperHome

    SuperHome

    Consumer

    Imóvel e casa: manutenção, contas de consumo, garantias

    Scaffold
  • Ícone de SuperTravel

    SuperTravel

    Consumer

    Viagens: roteiros, voos, hotéis, itinerários

    Scaffold
  • Ícone de SuperPet

    SuperPet

    Consumer

    Pets: cuidados veterinários, alimentação, registros de saúde

    Scaffold
  • Ícone de SuperNews

    SuperNews

    Consumer

    Notícias personalizadas por IA com resumos

  • Ícone de SuperSports

    SuperSports

    Consumer

    Esporte e desempenho: fitness, placares, calendário de jogos

  • Ícone de SuperAirport

    SuperAirport

    Enterprise

    Operações aeroportuárias: voos, portões, pistas

    Scaffold
  • Ícone de SuperMaritime

    SuperMaritime

    Enterprise

    Operações portuárias e de embarcações

    Scaffold
  • Ícone de SuperFactory

    SuperFactory

    Enterprise

    MES e manutenção do chão de fábrica

    Scaffold
  • Ícone de SuperFarm

    SuperFarm

    Enterprise

    Operações agrícolas: lavouras, rebanho, equipamentos

    Scaffold

06 · Sistema de design

Consistência sem mesmice.

after_design_system dá a todo produto o mesmo chrome, densidade e movimento. Os produtos mudam destaque, monograma, features e textos — não o sistema.

Tokens

Cor, espaçamento, raio e movimento são constantes Dart, compartilhadas por consumer e enterprise.

Cor

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

Espaçamento · escala de 4pt

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

Raio

  • 6
  • 8
  • 12
  • 16
  • 20

Movimento

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

Componentes

Botões, cards, inputs, navegação, diálogos, gráficos, dashboard, estados vazios e de carregamento, seções de configurações e a barra superior do 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

Acessibilidade

Esquemas de cores claro e escuro são entregues juntos. As séries dos gráficos são ordenadas para continuarem distinguíveis, e os tokens de movimento mantêm as transições curtas e intencionais.

Comportamento responsivo

O padding da página e a largura do conteúdo se adaptam à largura da viewport por meio de AfterSpacing.

Largura da viewportConteúdo máx.Padding da página
< 360width14 / 10 / 14 / 28
360 – 41952016 / 12 / 16 / 28
420 – 71964020 / 12 / 20 / 28
≥ 72076020 / 12 / 20 / 28

Extensão de marca

Cada spec de produto declara um destaque e um monograma. O tema recebe o destaque via accentOverride; todo o resto permanece na família.

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

07 · Documentação

Documentação feita para leitura rápida.

Cada página é derivada do repositório supercore e aponta para seu arquivo-fonte.

  • Busca instantânea com atalho de teclado
  • Sumário fixo com links diretos
  • Botões de copiar e realce de sintaxe nos dois temas
  • Páginas de pacotes com grafos de dependências
  • Diagramas de arquitetura com alternativas estáticas
  • Disponível em dez idiomas, com suporte a escrita da direita para a esquerda
Abrir a documentação

08 · Limites enterprise

Limites que falham fechados.

O isolamento enterprise é imposto no código e registrado em registros de decisão de arquitetura.

  • Multi-tenancy fail-closed

    Ports enterprise com escopo de organização exigem um EnterpriseScope. Um organizationId ausente lança uma exceção — eles nunca retornam todos os tenants.

  • Permissões antes da persistência

    Features verticais verificam PermissionSet.allows(...) antes de qualquer chamada de mutação. Os produtos declaram suas próprias strings de permissão.

  • Auditoria só de acréscimo

    Toda ação enterprise de mutação deve acrescentar um AuditLogEntry ao AuditLogRepository, que é só de acréscimo.

  • Apenas interoperabilidade segura

    Chamadas entre produtos passam pelo AfterSecureInteropBridge: audiência do After ID, escopos, RBAC e vínculo com a organização, depois uma entrada de auditoria obrigatória.

  • Bootstrap fail-fast

    No modo produção, um adaptador ausente lança uma exceção na inicialização, para que providers mock não cheguem silenciosamente à produção.

  • Modular por construção

    Backends reais substituem o MockEnterpriseRepository na raiz de composição. A camada de SO nunca conhece o nome do fornecedor.

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;
  }
}

Fonte supercore/packages/after_enterprise/lib/src/scope/enterprise_scope.dart (abre em uma nova aba)

Estes são controles de arquitetura documentados no repositório supercore. O After Framework não alega certificação nem conformidade regulatória.

Limites enterprise

Torne o produto menor. Torne a base mais forte.

Comece pela arquitetura, leia as docs dos pacotes ou explore o código-fonte.