runward

RW™ · V0.22.0

Docs · Comprendre · Les six phases

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.

Les six phases gardées, de l’idée à la productionLa 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. CadrerArchitecturerPlancherItérerGouvernerTransmettre
Les six phases gardées, de l’idée à la production

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 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 : architectarchitecture.md, topologyexecution-topology.md, floorfloor.md, governgovernance/threat-model.md, handoverhandover.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

← Docs