ADR 0011 — Phase narrative pre-G1¶

Contexte¶

Le kit sdeg dispose d'une skill DDD stratégique solide (business-domain-design) qui produit des Bounded Contexts classés Core / Supporting / Generic. Mais la skill saute directement à la classification stratégique : aucune étape narrative préalable n'est outillée pour expliciter le domaine via des scénarios concrets ou une ligne de temps d'événements.

Sur un projet as-is connu et concret (ex. la fixture Assistant Conseil Temps-Réel), ce saut n'est pas problématique : les acteurs, objets et flux sont implicitement partagés. Mais sur un sujet à forte abstraction conceptuelle (modèle formel, second brain, domaine mathématisable — l'émergence vient du projet Kagi, graphe multidimensionnel à arêtes typées par domaine inspiré de la théorie des catégories), l'absence de phase narrative pousse l'agent ou le sponsor à inférer implicitement les Bounded Contexts depuis la Vision. Risque réel de minimum local d'inférence — « l'implicite est notre ennemi, on = humains + agents ».

Deux briques classiques de domain discovery comblent ce manque :

Domain Storytelling (Hofer & Schwentner) — raconter le domaine sous forme de scénarios concrets Comme [acteur], dans [contexte], je [action] sur [objet] pour [intention], avec acteurs / objets / flèches numérotées. Outil de référence : egon.io (format DST JSON).
Event Storming Big Picture (Brandolini) — aligner les événements métier au passé sur une timeline, identifier hotspots, commands, agrégats, pivots inter-BC.

L'enjeu de cette ADR : intégrer ces deux briques avant business-domain-design dans la phase pre-G1, sans rendre le surcoût narratif obligatoire pour les projets concrets où il serait disproportionné.

Options envisagées¶

Sur la place dans la spirale¶

A. Une seule skill fusionnée « domain-discovery » couvrant stories + events. Cohérence narrative mais SRP violé (deux outils de pensée distincts).
B. Deux skills distinctes chaînées (domain-storytelling puis event-storming), business-domain-design les consomme en aval. SRP respecté, chaque skill a un format de sortie propre.
C. Un nouveau skill « avant business-domain-design » intégré à l'existant — modifie business-domain-design pour qu'il produise d'abord des stories puis classifie. Couplage fort, dilue la responsabilité.

Sur la rigueur des prerequisites¶

i. Prerequisites stricts — business-domain-design refuse de démarrer sans domain-stories.md + event-storming.md. Discipline forte mais surcoût disproportionné sur projets concrets à as-is connu.
ii. Prerequisites recommandés (warn, pas block) — un nouveau champ dans le bloc sdeg: signale les artefacts narratifs comme fortement conseillés mais leur absence n'arrête pas la skill ; le coach signale leur manque.
iii. Aucun lien formel — chaque skill est invoquée à la discrétion du coach, pas de déclaration. Risque d'oubli sur sujets abstraits, le coach n'a pas de signal pour proposer.

Sur le format de sortie¶

α. egon.io DST natif partout (stories + events) — outil de référence Hofer & Schwentner, format ouvert ré-éditable graphiquement. Mais Event Storming n'a pas de notation egon.io officielle, et le diff git d'un JSON n'est pas exploitable par les agents IA.
β. Mermaid embarqué dans markdown partout — markdown-first du kit, lisible humain + agent, diff-friendly. Mais pas de notation native event-storming dans Mermaid (pas de post-it orange / bleu / lilas).
γ. Mixte — DST egon.io pour les stories (outil canonique pour ce besoin), Mermaid timeline pour event-storming (à défaut de notation native, on définit une convention provisoire).

Sur l'auto-invocation de `ubiquitous-language`¶

a. Manuelle — le coach doit explicitement enchaîner ubiquitous-language après chaque séance narrative. Risque d'oubli.
b. Documentée comme protocole de fin de séance dans les deux nouvelles skills + dans le coach. Pas d'automatisation par code (cohérent avec le statut « non consommé par code » du bloc sdeg: per ADR-0010), mais signal clair pour humains et agents.

Décision¶

B (deux skills) + ii (recommandés) + γ (mixte) + b (protocole documenté).

Cinq décisions reliées :

D1 — Deux skills pre-G1 distinctes (option B)¶

.github/prompts/domain-storytelling.prompt.md et .github/prompts/event-storming.prompt.md, miroirs Claude Code dans .claude/plugins/sdeg-vision/{domain-storytelling,event-storming}/SKILL.md. Frontmatter sdeg: complet (ADR-0010), porte primaire pre-g1, porte secondaire g1 et g2, posture [collaborative, hermeneutic].

event-storming recommends (cf. D2) domain-stories.md — la timeline d'événements gagne à s'appuyer sur des scénarios narratifs déjà explicités. business-domain-design recommends les deux — la classification stratégique gagne en pertinence quand acteurs, objets, événements et flux ont été explicités.

D2 — Nouveau champ `recommends` dans le bloc `sdeg:` (option ii)¶

Le bloc sdeg: (ADR-0010) gagne un nouveau champ optionnel recommends : liste libre d'artefacts ou conditions dont l'absence émet un signal recommandé mais ne bloque pas l'invocation. Sémantique parallèle à prerequisites (qui reste, lui, bloquant dans la sémantique du futur dispatcher).

sdeg:
  prerequisites:
    - "be.status in [VISION_EN_COURS, ENGAGE]"   # bloquant
  recommends:
    - "domain-stories.md exists"                  # warn, pas block
    - "event-storming.md exists"                  # warn, pas block

Champ	Sémantique	Verdict si absent
`prerequisites`	Précondition stricte	NO-GO (skill inactivable)
`recommends`	Précondition recommandée	NEEDS-REVIEW (skill activable, signal au coach)

Le futur dispatcher métacognitif lit les deux champs ; aujourd'hui aucun code ne les consomme — c'est une déclaration en attente d'usage, comme le reste du bloc sdeg:.

business-domain-design est modifiée pour déclarer recommends: [domain-stories.md, event-storming.md]. Pas de prerequisites ajoutés (toujours invocable directement sur projet concret).

D3 — Formats de sortie mixtes (option γ)¶

Skill	Format primaire	Format secondaire	Justification
domain-storytelling	egon.io DST (`domain-stories.dst`, JSON exportable)	Synthèse markdown (`domain-stories.md`)	Outil de référence Hofer & Schwentner, format ouvert, ré-édition graphique possible
event-storming	Mermaid timeline embarqué dans markdown (`event-storming.md`)	—	Markdown-first du kit, diff-friendly, lisible humain + agent

Convention Mermaid pour Event Storming Big Picture (provisoire) : timeline natif de Mermaid pour la séquence temporelle des événements ; sections successives nommées par phase métier ; suffixes typographiques pour différencier les éléments à défaut de couleurs natives :

timeline
    title Event Storming — <Bounded Context>
    section Phase 1 — <nom>
        Événement A : <description>
        Événement B : <description>
    section Phase 2 — <nom>
        Événement C : <description>

Pour signaler hotspots, commands, aggregates, policies sans couleur native Mermaid : préfixer le libellé (⚠ HOTSPOT —, → COMMAND —, ◆ AGGREGATE —, ↻ POLICY —). Cette convention est provisoire : si elle se révèle inadaptée à l'usage (lisibilité, expressivité), elle sera révisée — voire remplacée par flowchart avec classes CSS Mermaid colorées.

Pour les sessions multi-Bounded-Contexts ou multi-acteurs, multi-timeline (sections parallèles ou diagrammes successifs) est admis.

D4 — Auto-invocation de `ubiquitous-language` documentée (option b)¶

Les deux skills narratives terminent leur workflow par un appel à ubiquitous-language pour extraire les termes émergents et alimenter glossary.md. Le coach coach-emergent.agent.md est enrichi pour proposer ce protocole de fin de séance.

Pas d'automatisation par code (cohérent avec le statut déclaratif du bloc sdeg:). Le déclenchement reste un geste explicite — du coach, ou du contributeur humain.

D5 — Question d'orientation pre-G1 dans le coach¶

Le coach gagne une question d'orientation pre-G1 dans son protocole de démarrage de phase Vision :

« Avant de classifier le domaine en Bounded Contexts, voulez-vous expliciter les scénarios narratifs (#domain-storytelling) et la timeline d'événements (#event-storming) ? Recommandé sur sujets à forte abstraction (modèle formel, second brain, ontologie) ; optionnel sur sujets concrets à as-is connu. »

Cette question est posée une fois au début de la phase Vision — pas à chaque tour. Le coach trace la décision dans .product/.events/<date>-cadrage-narratif.md.

Conséquences¶

Positives
Les sujets à forte abstraction (Kagi, ontologies, modèles formels) gagnent une discipline d'explicitation avant la classification stratégique. « L'implicite est l'ennemi. »
Le bloc sdeg: gagne un champ exprimant une intention recommandée distincte d'une précondition stricte — utile au-delà de cette ADR (ex. prd-architect pourrait recommends: [bounded-contexts.md]).
Mermaid timeline pour Event Storming reste markdown-first et diff-friendly ; pas de dépendance à un outil tiers.
Le coach gagne un signal explicite pre-G1 ; le projet reste piloté par l'humain (pas d'automatisation).
Négatives
Convention Mermaid pour Event Storming provisoire — pas de notation native couleur. Risque d'inconfort visuel sur sessions denses ; révision possible si l'usage démontre l'inadaptation.
Deux skills supplémentaires à maintenir (FR + Claude Code), 7→9 dans sdeg-vision.
Le champ recommends n'est consommé par aucun code aujourd'hui (comme le reste du bloc sdeg:). Rappel : c'est volontaire — déclaration avant usage.
Surcoût narratif sur projets concrets — atténué par le statut recommandé (pas bloquant) et par la question d'orientation pre-G1 du coach.
Neutres
Pas de modification de sdlc/schema.js — les skills narratives ne sont pas une porte décisionnelle, juste des outils de cadrage. La transition VISION_EN_COURS → ENGAGE (G1) reste régie par les artefacts existants.
Pas de modification de sdlc/evaluator.js ni validators.js — le champ recommends est purement déclaratif, pas validé au commit.

Références¶

ADR-0010 — bloc sdeg: dans le frontmatter ; cette ADR ajoute recommends:.
Hofer & Schwentner, Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software (Addison-Wesley, 2021).
Brandolini, Introducing EventStorming (Leanpub).
Evans, Domain-Driven Design (référence pour l'ubiquitous language partagé).
egon.io — outil de référence pour Domain Storytelling (Hofer & WPS Hamburg).
Émergence : projet pilote Kagi (consommateur en cours de bootstrap, sujet à très forte abstraction conceptuelle). Mémoire feedback : « l'implicite est notre ennemi, on = humains + agents ».
Issue #4 du dépôt — proposition initiale et arbitrages amont.