After Framework

Créez vos produits sur un framework opérationnel partagé.

Construire une fois. Livrer dans tous les domaines.

After Framework offre aux produits une base commune : architecture, identité, IA, systèmes de design, outillage et modules métier réutilisables.

supercore/packages7 packages · 2 lignes de produits · 1 contrat de composition
SuperGarageAfterHubSuperHospitalafter_ecosystemafter_aiafter_consumerafter_enterpriseafter_firebaseafter_coreafter_design_system
Légende:dépendance pubspecpile de référence documentée

01 · Architecture du framework

Un noyau. Deux lignes de produits. Des produits légers au sommet.

Tous les produits partagent les mêmes couches. Ajouter un domaine de vie ou un domaine sectoriel ajoute un module au sommet — les couches inférieures ne changent pas.

Spécifique au produit

Plateforme partagée

Adaptateurs de la racine de composition

Sélectionnez une couche pour voir ce qu’elle possède et ce dont elle dépend.

after_core

Noyau partagé

Auth, réseau renforcé, stockage, DI Riverpod, feature flags, configuration à distance, SDK d’IA BYOK, droits premium, notifications, liens profonds, ainsi que les moteurs de tableau de bord, de plugins, de recherche et de paramètres.

Dépend de
Aucune — couche de base
Utilisé par
Couche domaine produit · Couche écosystème · Capacités d’IA · Modules grand public · Modules entreprise · Système de design · Adaptateurs Firebase

Réutilisation partagée, expérience propre au produit

La doctrine de la plateforme vise au moins quatre-vingt-dix pour cent des capacités d’exécution héritées par produit. Un produit possède son domaine, ses fonctionnalités verticales, son profil d’IA, ses catalogues et son image de marque — rien d’autre.

Les règles qui font tenir le système

  1. 01Des ports plutôt que des SDK : le code vertical dépend des interfaces After, jamais des SDK des fournisseurs.
  2. 02Les modules verticaux vivent uniquement dans les dépôts produit, sous lib/features/.
  3. 03Chaque port est livré avec un mock, pour que les squelettes tournent sans backend.
  4. 04Générer plutôt que repartir de zéro : un nouveau produit part d’une spec, pas d’une nouvelle architecture.

02 · Fabrique de produits

De l’idée au produit fonctionnel, sur une base réutilisable.

La fabrique de produits transforme un petit product.spec.yaml en une app Flutter sœur qui dépend des packages partagés. La spec ne contient que ce qui est propre au produit.

  1. 01

    Idée

    Nommez le produit et choisissez une ligne : grand public ou entreprise, avec SuperGarage ou SuperHospital comme référence.

  2. 02

    Domaine

    Rédigez product.spec.yaml : domaine, fonctionnalités verticales, onglets, permissions, widgets du tableau de bord, compétences IA, image de marque, langues.

  3. 03

    Modules

    Tout ce qui n’est pas dans la spec — auth, adhésion ou organisation, RBAC, calendrier, tâches, notifications, recherche — est hérité.

  4. 04

    Shell produit

    generate_product.ps1 génère le manifeste, la racine de composition, le catalogue de fonctionnalités, le shell, les fichiers l10n et un workflow CI.

  5. 05

    Déploiement

    Le workflow CI généré exécute formatage, analyse et tests avec couverture à chaque push et pull request vers main.

Le produit possède

  • Nom, package, bundle, ligne de produits
  • Fonctionnalités verticales et clés i18n
  • Onglets de navigation
  • Chaînes de permissions RBAC
  • Widgets du tableau de bord
  • Compétences IA et liaisons d’outils
  • Couleur d’accent et monogramme

La plateforme fournit

  • Auth et superadmin
  • Adhésion ou organisation
  • Moteur RBAC et journal d’audit
  • Calendrier, tâches, documents
  • Notifications et analytique
  • Moteurs de workflow, de tableau de bord et de recherche
  • Système de design, écran de démarrage, CI

Relancer le générateur avec une spec modifiée met à jour les fichiers squelettes sans détruire le code de fonctionnalités écrit à la main.

03 · Packages et capacités

Sept packages. Des dépendances explicites.

Tous les packages sont en version 1.0.0 dans le dépôt supercore et sont consommés via des dépendances par chemin. Sélectionnez un package pour suivre ses dépendances et ce qui dépend de lui.

Noyau partagé

after_core

Ports et implémentations par défaut pour l’auth, le réseau, le stockage, la DI, l’analytique, les feature flags, la configuration à distance, l’IA, les notifications, les liens profonds et les droits premium. Les produits remplacent les providers Riverpod par leurs propres adaptateurs.

Dépend de
Aucune — couche de base
Utilisé par

API clés

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

Dépendances tierces notables

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

Exemple

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

Source supercore/packages/after_core/README.md (s’ouvre dans un nouvel onglet)

04 · CLI et workflow développeur

Des scripts et des commandes Flutter, pas de magie.

L’outillage se trouve dans supercore/scripts sous forme de scripts PowerShell, aux côtés de la chaîne d’outils Flutter standard. Il n’existe pas de binaire CLI packagé séparé.

Initialiser

Validez une spec sans Flutter, puis générez l’app sœur et amorcez-la.

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

Source supercore/factory/README.md (s’ouvre dans un nouvel onglet)

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

Source supercore/factory/README.md (s’ouvre dans un nouvel onglet)

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

05 · Du framework aux vrais produits

Des capacités partagées deviennent des expériences propres à chaque produit.

SuperGarage est la référence grand public en production. Chaque écran ci-dessous est une vraie capture des stores ; la surcouche indique ce qui vient de la plateforme et ce qui appartient au produit.

Capture d’écran SuperGarage : Score de santé du véhicule et rappels sur le tableau de bord du garage.

Carte des capacités de SuperGarage

Identifiants importés par supergarage/lib, regroupés par package propriétaire.

after_core

  • AfterUserPlan
  • AfterAiCredentialVault
  • AfterLocalNotifications

after_consumer

  • FamilyShellHeader
  • AfterRegionalLocation

after_firebase

  • AfterFirebaseBootstrap

Fonctionnalités produit

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

Famille de produits

Statut tel qu’enregistré dans supercore/catalog/products.yaml. Seul SuperGarage est marqué en production.

  • Icône SuperGarage

    SuperGarage

    Grand public · Référence

    Mobilité : véhicules, entretien, assurance, carburant, OBD, flotte

    after_core · after_design_system · after_firebase · after_consumer

  • Icône AfterHub

    AfterHub

    Grand public · Shell OS

    Shell OS grand public : identité, tableau de bord, IA, calendrier, recherche, After+

    Squelette

    after_ai · after_consumer · after_core · after_firebase · after_design_system · after_ecosystem

  • Icône SuperHospital

    SuperHospital

    Entreprise · Référence

    Opérations hospitalières — référence entreprise

    Squelette
  • Icône SuperHealth

    SuperHealth

    Grand public

    Santé personnelle : médicaments, dossiers, sommeil, nutrition

  • Icône SuperFinance

    SuperFinance

    Grand public

    Finances personnelles : abonnements, budgets, investissements

    Squelette
  • Icône SuperHome

    SuperHome

    Grand public

    Logement et foyer : entretien, charges, garanties

    Squelette
  • Icône SuperTravel

    SuperTravel

    Grand public

    Voyages : séjours, vols, hôtels, itinéraires

    Squelette
  • Icône SuperPet

    SuperPet

    Grand public

    Animaux : soins vétérinaires, alimentation, dossiers de santé

    Squelette
  • Icône SuperNews

    SuperNews

    Grand public

    Actualités personnalisées par l’IA, avec résumés

  • Icône SuperSports

    SuperSports

    Grand public

    Sport et performance : forme physique, scores, rencontres

  • Icône SuperAirport

    SuperAirport

    Entreprise

    Opérations aéroportuaires : vols, portes, pistes

    Squelette
  • Icône SuperMaritime

    SuperMaritime

    Entreprise

    Opérations portuaires et navires

    Squelette
  • Icône SuperFactory

    SuperFactory

    Entreprise

    MES d’atelier et maintenance en usine

    Squelette
  • Icône SuperFarm

    SuperFarm

    Entreprise

    Exploitation agricole : cultures, bétail, équipements

    Squelette

06 · Système de design

Cohérent sans être uniforme.

after_design_system donne à chaque produit le même chrome, la même densité et le même mouvement. Les produits changent leur accent, leur monogramme, leurs fonctionnalités et leurs textes — pas le système.

Tokens

Couleurs, espacements, rayons et mouvements sont des constantes Dart, partagées par le grand public et l’entreprise.

Couleur

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

Espacement · échelle de 4 pt

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

Rayon

  • 6
  • 8
  • 12
  • 16
  • 20

Mouvement

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

Composants

Boutons, cartes, champs, navigation, boîtes de dialogue, graphiques, tableau de bord, états vides et de chargement, sections de paramètres et barre supérieure du 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

Accessibilité

Les palettes claire et sombre sont livrées ensemble. Les séries des graphiques sont ordonnées pour rester distinguables, et les tokens de mouvement gardent des transitions courtes et utiles.

Comportement adaptatif

Les marges de page et la largeur du contenu s’adaptent à la largeur de la fenêtre via AfterSpacing.

Largeur de la fenêtreContenu max.Marge de page
< 360width14 / 10 / 14 / 28
360 – 41952016 / 12 / 16 / 28
420 – 71964020 / 12 / 20 / 28
≥ 72076020 / 12 / 20 / 28

Extension de marque

Chaque spec produit déclare un accent et un monogramme. Le thème reçoit l’accent via accentOverride ; tout le reste demeure dans la famille.

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

07 · Documentation

Une documentation pensée pour être parcourue.

Chaque page est issue du dépôt supercore et renvoie à son fichier source.

  • Recherche instantanée avec raccourci clavier
  • Table des matières fixe avec liens profonds
  • Boutons de copie et coloration syntaxique dans les deux thèmes
  • Pages de packages avec graphes de dépendances
  • Diagrammes d’architecture avec alternatives statiques
  • Disponible en dix langues, avec prise en charge de la lecture de droite à gauche
Ouvrir la documentation

08 · Frontières entreprise

Des frontières qui refusent par défaut.

L’isolation entreprise est imposée dans le code et consignée dans des enregistrements de décisions d’architecture.

  • Multilocation en refus par défaut

    Les ports entreprise liés à une organisation exigent un EnterpriseScope. Un organizationId manquant lève une exception — ils ne renvoient jamais tous les locataires.

  • Permissions avant persistance

    Les fonctionnalités verticales vérifient PermissionSet.allows(...) avant tout appel de mutation. Les produits déclarent leurs propres chaînes de permissions.

  • Audit en ajout seul

    Chaque action entreprise de mutation doit ajouter un AuditLogEntry à l’AuditLogRepository en ajout seul.

  • Interop sécurisée uniquement

    Les appels interproduits passent par AfterSecureInteropBridge : audience After ID, portées, RBAC et appartenance à l’organisation, puis une entrée d’audit obligatoire.

  • Amorçage à échec rapide

    En mode production, un adaptateur manquant lève une exception au démarrage : les providers mock ne peuvent pas atteindre la production en silence.

  • Modulaire par construction

    Les vrais backends remplacent MockEnterpriseRepository à la racine de composition. La couche OS ne connaît jamais le nom du fournisseur.

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

Source supercore/packages/after_enterprise/lib/src/scope/enterprise_scope.dart (s’ouvre dans un nouvel onglet)

Il s’agit de contrôles d’architecture documentés dans le dépôt supercore. After Framework ne revendique aucune certification ni conformité réglementaire.

Frontières entreprise

Allégez le produit. Renforcez les fondations.

Commencez par l’architecture, lisez la documentation des packages ou explorez la source.