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 ne crée ni ne rafraîchit jamais votre carte de territoire non plus.
• Elle distingue un changement amont d'une édition locale. runward enregistre dans runward/scaffold-lock.json l'empreinte de ce qu'il a écrit. Un fichier que vous avez modifié est signalé drift (locally modified) et laissé de côté ; un fichier que vous n'avez pas touché et qui a changé en amont est simplement rafraîchi, sans --force.
• Quand elle ne peut pas savoir, elle le dit. Sur une mission créée avant l'existence du verrou, il n'y a aucun enregistrement pour un fichier donné : runward annonce alors qu'il ne peut pas déterminer si vous l'avez édité ou s'il a changé en amont, plutôt que d'attribuer la modification à l'un ou à l'autre.
• Elle rapporte ce qui a changé. Chaque fichier est compté comme à jour, ajouté, rafraîchi depuis l'amont, ou dérivé localement.
• 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.

Pourquoi ce verrou existe. Avant lui, update comparait votre copie d'une règle au template courant : un changement amont était indiscernable d'une édition locale. Chaque version qui touchait une règle livrée annonçait donc aux opérateurs qu'ils avaient modifié des fichiers qu'ils n'avaient jamais ouverts, et retenait le rafraîchissement derrière --force. Une mission qui suivait la consigne de ne pas éditer ses règles ne recevait jamais la mise à jour.

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 ;
• la couverture de territoire : combien de fichiers parcourus portent une catégorie, et quelles lignes de votre carte ne touchent plus aucun fichier, avec leur numéro de ligne. runward ne tranche pas entre une ligne morte et une ligne simplement en avance : il la nomme, vous jugez ;
• 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.