# Les six phases

Comment runward check, la porte de livraison, lit une mission, ce que « gardé » veut dire, et l'arc des six phases, chacune franchie sur preuve.

La livraison est une suite de six jalons gardés, chacun franchi sur une preuve plutôt que sur une affirmation.

> **Schéma.** La livraison va de l’idée à la production en six phases : cadrer, architecturer, plancher, itérer, gouverner, transmettre. Chaque porte se franchit sur une preuve, jamais sur une affirmation. Itérer (phase 4, en pointillés) n’a pas de fichier livrable : elle est gardée par la discipline (un ADR par bascule), pas par une porte de présence.

## Comment la garde lit une mission

### Trouver la mission

Une mission vit dans un répertoire `runward/`. `runward check` la trouve en remontant depuis le répertoire courant à la recherche de `runward/framing.md` : un répertoire simplement *nommé* `runward` (comme le dépôt de l'outil lui-même) ne compte pas.

### États des livrables

Les phases et leurs livrables requis sont déclarés comme des données (le tableau `PHASES`). Pour chaque livrable, la garde calcule un `ArtifactState` : `missing`, `untouched`, `in-progress` ou `filled` :

- **missing** : le fichier n'existe pas.
- **untouched** : le fichier est identique octet pour octet au gabarit livré (`content.trim() === template.trim()`).
- **in-progress** : trois marqueurs de texte entre crochets ou plus, comme `[the real process as observed…]`, subsistent, *ou* l'édition a ajouté moins de 3 nouvelles lignes / moins de 20 nouveaux mots au-delà du gabarit.
- **filled** : il s'écarte de manière significative de l'ossature. Cette "garde de divergence" existe parce que des gabarits comportant peu de marqueurs (par exemple la matrice de décision) pourraient sinon être validés par une édition d'un seul octet ; elle est calibrée sur la mission de référence livrée, dont le remplissage le plus léger ajoute 5 lignes / 215 mots.

### Quand une phase est complète

Une phase est **complète** seulement quand chacun de ses artefacts est `filled`. La "garde courante" est la première phase incomplète.

### Codes de sortie

- `0` = propre
- `1` = lacunes
- `2` = aucune mission trouvée

Une réserve sur `0` : la garde compte les livrables non remplis sur *les six* phases, pas seulement sur la frontière courante. Ainsi `0` signifie que toute la chaîne est remplie (et, sous `--strict`, chaque règle mappée prise en compte et chaque hook au vert), tandis qu'une mission neuve renvoie `1` jusque-là.

Un agent devrait se piloter sur le code de sortie, ou sur `runward check --json`, qui émet [un objet machine stable](https://runward.dev/docs/operating/from-an-agent/machine-contract/) avec `verdict`, `currentGate`, l'état par livrable et les lacunes de conformité. Le contrat de code de sortie est inchangé en mode JSON.

### Options

- `--strict` : vérifier les manifestes de conformité aux règles
- `--freeze` : sceller une garde stricte au vert, implique `--strict`
- `--hooks` : exécuter les hooks de l'opérateur autour de l'audit
- `--coverage` : ratios indicatifs, ne gardent jamais
- `--json` : sortie machine

## Une note sur les "six phases" et ce que la garde impose

Les six phases sont toutes réelles et séquencées par le workflow `method`, qui les liste explicitement : Frame, Architect, Floor, Iterate, Govern, Handover. Mais elles ne sont *pas* imposées de manière identique, et c'est délibéré :

- **Cinq phases portent un livrable gardé.** Le tableau `PHASES` d'analyse des lacunes les étiquette `1 · Frame`, `2 · Architect`, `3 · Floor`, `5 · Govern (day zero)`, `6 · Hand over`. Un lecteur qui compte les étiquettes voit 1, 2, 3, 5, 6 : un trou là où serait iterate.
- **Iterate (phase 4) n'a pas de fichier livrable fixe**, elle est donc intentionnellement absente de la garde d'analyse des lacunes. Iterate est gardée par la *discipline*, pas par un fichier : "un ADR par bascule". On ne peut pas avoir un seul "iterate.md" parce que l'itération est ouverte : chaque évolution produit son propre ADR et, si elle déplace le placement d'un port, rouvre `execution-topology.md`.
- **La conformité aux règles sous `--strict` s'exécute sur une liste légèrement différente**, `GATED_DELIVERABLES` : `architect` → `architecture.md`, `topology` → `execution-topology.md`, `floor` → `floor.md`, `govern` → `governance/threat-model.md`, `handover` → `handover.md`. À noter, `topology` est un scope strict *distinct* même si l'affichage d'analyse des lacunes regroupe visuellement la note de topologie sous la phase Architect (c'est l'un des cinq artefacts d'Architect). L'affichage humain et la liste des scopes stricts ne s'alignent pas un pour un. Frame n'a pas de scope strict : la note de cadrage ne porte pas de manifeste de conformité aux règles.

Donc : six phases dans la méthode, cinq avec une garde de présence, quatre-plus-topology (cinq scopes) avec une garde de règles stricte, et iterate gardée par la discipline des ADR. Les sections ci-dessous couvrent chacune.

## La suite de cette section

- [Les six phases en détail](https://runward.dev/docs/concepts/six-phases/frame-to-handover/)
- [Sceller, règles et méthode](https://runward.dev/docs/concepts/six-phases/sealing-and-method/)

## Voir aussi

- [Concepts : la porte déterministe](https://runward.dev/docs/concepts/the-gate/)
- [Les six phases en détail](https://runward.dev/docs/concepts/six-phases/frame-to-handover/)
- [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/)