Les six phases en détail.

Phase 1 : Frame

Livrables requis : la note de cadrage (runward/framing.md) et le contrat de pilotage (runward/mission-contract.md).

Ce qu'elle produit

Frame transforme une intention vague en un périmètre décidé : ce qui est construit d'abord, ce qui est explicitement reporté, et sous quel déclencheur la complexité est ajoutée plus tard.

La découverte se déroule en cinq familles de questions ordonnées :

1. le processus réel
2. la valeur
3. un critère de succès observable
4. les données
5. les contraintes dures

Le contrat de pilotage relie ce critère aux livrables et à ce qui clôt chaque engagement. Les questions de stack sont explicitement refusées ici : le langage et la topologie restent ouverts.

Définition de fini

• note de cadrage produite (une page : problème, valeur, critère de succès observable, contraintes dures)
• contrat de pilotage rempli avec le sponsor
• le périmètre du plancher listé avec chaque report nommé face à son déclencheur
• frontières présumées énoncées, langage et topologie laissés ouverts

Ce que la garde contrôle

Les deux fichiers doivent atteindre filled : c'est-à-dire diverger matériellement de leurs gabarits et passer sous trois marqueurs. Il n'y a pas de manifeste de règles --strict pour Frame (elle est absente de GATED_DELIVERABLES). La garde confirme que les deux artefacts existent et sont réellement rédigés ; elle ne juge pas si le critère de succès est bon.

Phase 2 : Architect

Livrables requis, au nombre de cinq : la note d'architecture (architecture.md), la topologie d'exécution (execution-topology.md), la matrice de décision (decision-matrix.md), le journal de décisions (adr/, au moins un ADR réel), et les contrats de ports (contracts/, au moins un rempli).

Ce qu'elle produit

Les frontières avant la stack : les ports du domaine, le port modèle comme un port parmi d'autres, et le protocole d'intégration inter-processus, langage et topologie délibérément ouverts.

Une seconde vision, parallèle, est consignée dans execution-topology.md : une ligne par port donnant son adaptateur, sa famille de localisation, sa (ses) classe(s) de données, son niveau de souveraineté, et le déclencheur pour le déplacer. Tout placement hors de l'application donne lieu à un ADR. runward trace cette décision de placement ; il ne déploie jamais.

Définition de fini

• note d'architecture produite frontières d'abord
• matrice de décision adoptée (chaque choix structurant avec un défaut sobre et un déclencheur objectif)
• chaque port nommé avec un contrat et une version initiale
• note de topologie d'exécution produite avec chaque port placé
• un ADR par choix structurant, verrouillé avant que la note ne le mentionne
• chaque règle architect CRITICAL/HIGH prise en compte dans le manifeste de conformité

Ce que la garde contrôle

• Présence : les cinq artefacts doivent être filled. Deux utilisent un décompte spécial : le répertoire ADR est filled seulement quand il contient un vrai ADR-<n>-*.md au-delà de ADR-0000-template.md ; le répertoire contracts/ est filled dès qu'un .md diffère du gabarit brut de contrat de port.
• Conformité stricte aux règles : deux scopes s'exécutent : architect/architecture.md et topology/execution-topology.md. Chacun doit porter une table markdown ## Rule conformance qui prend en compte chaque règle CRITICAL/HIGH mappée à cette phase dans le frontmatter de runward/rules/. Chaque règle a besoin d'une ligne avec le statut applied (+ un pointeur de preuve), deviated (+ un ADR qui existe réellement dans runward/adr/), ou n/a (+ une vraie raison, pas un marqueur).
• Plancher de non-vacuité : le mapping ne peut pas être discrètement dépouillé pour faire passer la garde sur rien : architect doit garder au moins 6 règles mappées et topology au moins 4 ; passer en dessous lève une violation (mapping).
• Dérive : un pointeur applied dont le chemin de fichier ne résout plus est une lacune bloquante sous --strict.
• ADR non ratifiés : une décision reconstruite encore marquée DRAFT-, Status: hypothesis, ou why: UNKNOWN échoue à la garde stricte : la supposition d'un agent ne doit pas passer pour une décision.

Phase 3 : Floor

Livrable requis : la note de plancher (runward/floor.md), "preuve mesurée".

Ce qu'elle produit

Le plus petit système en marche qui prouve la valeur sur du trafic réel : un système qui tourne, pas une démo. Le workflow prescrit exactement six pièces et rien de plus :

• un point d'entrée
• un orchestrateur unique
• un port modèle derrière un SDK direct (avec un repli déterministe pour que l'application tourne pour de vrai une fois une clé posée)
• une persistance immuable
• des garde-fous dans le code
• une observabilité de base avec un identifiant de requête propagé

Le point de départ est le plancher de référence livré floor-ts/ : une ossature hexagonale clonable (un cœur pur et modulaire derrière des ports, des adaptateurs en périphérie) que vous peuplez, sans la réinventer. L'hexagonal est le défaut sobre de la méthode, pas une exigence : la porte vérifie que la décision a été confrontée, et dévier avec un ADR tracé passe au vert.

Définition de fini

• le plancher tourne sur du trafic réel à travers l'infrastructure existante
• valeur mesurée face au critère de succès observable
• une trajectoire complète se rejoue depuis un seul identifiant de requête
• chaque report nommé avec son déclencheur
• chaque règle floor CRITICAL/HIGH prise en compte
• note de plancher produite et relue

Ce que la garde contrôle

• Présence : floor.md doit être filled.
• Conformité stricte : le scope floor doit prendre en compte chaque règle CRITICAL/HIGH mappée à floor, avec un plancher de non-vacuité de 10 règles mappées. La note de plancher est l'endroit où les pointeurs de preuve typés sont fortement préférés : file:PATH[:LINE][#SYMBOL], test:PATH[::NAME], adr:NNNN, que la couche de preuve vérifie de manière déterministe pour leur résolution et leur contenu, plus la regex signature: déclarée par la règle lorsqu'elle est présente.
• Preuve comportementale (indicative, au-dessus de la garde) : quand la garde stricte est par ailleurs au vert, runward lit un Behavioral proof: <command> optionnel (et un Proof artifact: optionnel) déclaré dans floor.md et rapporte seulement la présence et la fraîcheur de l'artefact : il ne lance jamais la commande ni ne lit un verdict. C'est la frontière explicite : la garde est la preuve documentaire que les décisions sont tracées ; la preuve comportementale est votre suite de tests. runward n'est pas un runtime.

Phase 4 : Iterate

Livrable requis : aucun sous forme de fichier fixe, et c'est voulu. Iterate est une phase réelle de la méthode mais n'a pas d'entrée dans le PHASES d'analyse des lacunes ni dans GATED_DELIVERABLES. Sa sortie est plutôt un ADR verrouillé par bascule, chacun avec un déclencheur de réévaluation/rollback.

Ce qu'elle produit

Des évolutions ajoutées seulement sur un déclencheur objectif ou un gain mesuré, jamais "parce que c'est plus moderne". Le workflow fournit une matrice de décision des bascules courantes, chacune avec un défaut sobre et le signal qui commande le changement :

• extraire un service
• ajouter un agent
• changer de palier de modèle
• franchir une frontière de processus
• ajouter une mémoire élaborée
• externaliser l'état
• passer en asynchrone

Définition de fini

• chaque évolution livrée correspond à un déclencheur observé ou un gain mesuré
• un ADR verrouillé par bascule incluant le signal de rollback
• le domaine intact (seuls les adaptateurs et la topologie bougent)
• execution-topology.md rouvert et mis à jour pour toute bascule qui a déplacé le placement d'un port
• mesure post-bascule consignée, rollbacks exécutés là où le gain a échoué

Ce que la garde contrôle

Indirectement, à travers les artefacts que iterate touche. Chaque nouvel ADR est soumis au même cycle de ratification : un ADR DRAFT-/hypothesis/why: UNKNOWN échoue à --strict. Si une itération déplace un placement, le execution-topology.md mis à jour est re-contrôlé par le scope strict topology. Il n'y a pas de "garde iterate" autonome : la discipline est imposée là où les changements atterrissent.

Phase 5 : Govern (day zero)

Livrables requis, au nombre de trois, tous sous governance/ : le modèle de menaces (governance/threat-model.md), la grille d'évaluation (governance/evaluation-rubric.md), et le schéma d'observabilité (governance/observability-schema.md).

Ce qu'elle produit

Govern est transversale : elle démarre au jour zéro du plancher et est maintenue à chaque palier, jamais rajoutée après un incident. Elle :

• route toutes les préoccupations transverses par une chaîne de middleware unique (journalisation, propagation de l'identifiant de requête, provenance, plafonds de coût avec stop-and-synthesize, points d'approbation),
• fait de la résilience le défaut (fail-open en lecture, fail-closed sur les actions),
• contraint la sécurité par l'architecture (la règle deux-sur-trois du "lethal trifecta" tant que du contenu non fiable est dans le contexte),
• et fait tourner une boucle d'évaluation continue sous un hold-out que l'optimiseur ne voit jamais.

Définition de fini

• toutes les préoccupations transverses passent par la chaîne unique et une trajectoire se rejoue depuis un seul identifiant de requête
• chaque règle govern CRITICAL/HIGH prise en compte
• plafonds de coût imposés avec stop-and-synthesize
• modèle de menaces rédigé avec la règle deux-sur-trois du trifecta imposée
• la pyramide de tests et la boucle d'évaluation en place avec juge ancré et hold-out
• le travail en arrière-plan gardé

Ce que la garde contrôle

• Présence : les trois fichiers de gouvernance doivent être filled.
• Conformité stricte : le scope govern lit son manifeste depuis governance/threat-model.md et doit prendre en compte chaque règle govern CRITICAL/HIGH mappée, avec le plancher de non-vacuité le plus élevé de toutes les phases : 12, reflétant que la gouvernance porte le plus de règles critiques pour la sûreté et la sécurité. Mêmes règles de ligne (applied/deviated/n/a), mêmes contrôles de dérive et de ratification d'ADR.

Phase 6 : Hand over

Livrables requis : le runbook de reprise (runward/runbook.md) et la note de passation (runward/handover.md, "le kit, prouvé").

Ce qu'elle produit

L'autonomie, pas la dépendance : la phase n'est prouvée que quand l'équipe qui reçoit refait une tâche réelle seule, de bout en bout. La note de passation :

• indexe un kit en six parties (assets réutilisables, note d'architecture, journal d'ADR, runbook, preuve dans le code, et la charte AGENTS.md finalisée et neutre vis-à-vis du harnais),
• consigne la preuve de la tâche refaite,
• nomme la succession,
• et journalise un exercice de bascule de fournisseur.

Définition de fini

• kit complet incluant le AGENTS.md finalisé
• note de passation produite avec index du kit, preuve de tâche refaite, succession nommée, exercice de bascule de fournisseur journalisé
• chaque règle handover CRITICAL/HIGH prise en compte
• sessions de transfert tenues avec l'équipe aux commandes (pas en spectatrice)
• au moins une tâche réelle refaite seule et consignée

Ce que la garde contrôle

• Présence : runbook.md et handover.md doivent tous deux être filled.
• Conformité stricte : le scope handover lit handover.md et doit prendre en compte chaque règle handover CRITICAL/HIGH mappée, plancher de non-vacuité 4, jusqu'aux pointeurs de preuve typés.