Maintenir & diagnostiquer.

Garder une mission à jour : runward update

runward update rafraîchit la méthode livrée sous runward/workflows/, les règles de craft sous runward/rules/, et les échantillons d'adaptateurs de garde sous runward/adapters/, en tirant chacun du paquet runward installé. Lancez-la après avoir mis à jour le paquet, pour que votre mission garde face aux règles courantes et suive les workflows courants.

Elle est délibérément prudente :

• Elle ne touche jamais l'état de la mission. Vos framing.md, note d'architecture, ADR et fichiers de gouvernance restent exactement tels quels.
• Elle préserve vos éditions locales. Un fichier que vous avez modifié est signalé comme drift (locally modified) et laissé de côté, pas écrasé. Passez --force pour remplacer les fichiers dérivés par la version du paquet.
• Elle rapporte ce qui a changé. Chaque fichier est compté comme à jour, ajouté, ou dérivé.
• Sortie 2 s'il n'y a pas de mission runward/ ici (lancez runward init d'abord). Prévisualisez tout avec runward --dry-run update.

Comme update peut changer les règles que votre garde applique, lisez le diff avant de relancer runward check --strict.

Diagnostiquer l'installation : runward doctor

runward doctor lance trois auto-vérifications et affiche un rapport :

• Environnement : Node >= 20 et git présents.
• Intégrité du paquet : les templates de mission, l'ensemble des workflows, les comptes attendus de règles et d'adaptateurs, et les planchers de mappage des règles sont tous intacts.
• Ce répertoire : si vous êtes dans une racine de mission, si AGENTS.md et git sont présents, et quels profils d'outil sont détectés.

Ses codes de sortie sont inversés, volontairement. Contrairement à toutes les autres commandes (0 propre, 1 manques, 2 pas de mission / mésusage), doctor utilise 0 = tout va bien, 1 = avertissements, 2 = un échec critique, et il traite « pas de mission ici » comme un avertissement, pas un 2 dur. Un agent qui branche uniformément sur les codes de sortie doit traiter doctor à part.

Voir où en est une mission : runward status

runward status est l'instantané « où en suis-je », et la première commande naturelle pour une équipe qui reçoit une mission. Il lit, et ne change rien. Il affiche :

• le titre de la mission et la porte courante ;
• la progression par phase le long de l'arc gardé, porte par porte, avec un repère ← you are here ;
• le journal des décisions (ADR ratifiés) et l'activité récente ;
• un avertissement si un workflow attendu manque.

Lire une règle avant de l'appliquer : runward explain

Avant d'appliquer une règle de craft ou d'y déroger, lisez son contrat :

runward explain <rule>          # impact, phases, le « pourquoi », la signature de preuve, corps complet
runward explain <rule> --json   # la même chose, en contrat machine pour un agent

Pour restreindre le catalogue à une phase, filtrez-le :

runward rules --phase floor     # architect | topology | floor | govern
runward rules --json            # l'ensemble complet en contrat versionné et additif

Couverture indicative : check --coverage

runward check --coverage rapporte un ratio de livrables remplis, le nombre de décisions ratifiées, et la liste des ADR non ratifiés. C'est indicatif et ça ne garde jamais : servez-vous-en pour voir jusqu'où une mission est allée, pas pour la faire passer ou échouer.

Hooks de l'opérateur : runward/hooks.json

Vous pouvez faire tourner vos propres commandes autour de l'audit. Créez runward/hooks.json :

{
  "pre":  ["npm run lint"],
  "post": ["./scripts/notify.sh"]
}

Les commandes pre tournent avant l'audit, post après. Elles ne tournent que si vous passez runward check --hooks : la garde de runward elle-même ne les lance jamais, donc cloner un dépôt n'exécute rien par surprise. Sous --json, la sortie des hooks est routée vers stderr pour ne pas corrompre l'unique objet JSON sur stdout.

Flags globaux

Ils s'appliquent à n'importe quelle commande :

• --dry-run : affiche les écritures prévues sans toucher au disque (identique à RUNWARD_DRY_RUN=1).
• --verbose : affiche les traces de pile complètes quand quelque chose échoue (identique à VERBOSE=1).
• --no-color : désactive la sortie colorée, utile dans les logs et les environnements non-TTY.