# Les six phases en détail Cadrer, architecturer, plancher, itérer, gouverner, transmettre : le livrable et la définition de « fait » que runward vérifie à chaque porte, phase par phase. ## 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--*.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](https://runward.dev/docs/concepts/evidence/) 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: ` 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. ## Voir aussi - [Les six phases](https://runward.dev/docs/concepts/six-phases/) - [Sceller, règles et méthode](https://runward.dev/docs/concepts/six-phases/sealing-and-method/) - [Preuve et intégrité](https://runward.dev/docs/concepts/evidence/) - [Catalogue des règles](https://runward.dev/docs/reference/rules/)