# Maintenir & diagnostiquer

runward update maintient la mission à jour, runward doctor diagnostique l'installation, runward status montre l'avancement, runward explain lit une règle, et les flags globaux.

## Garder une mission à jour : `runward update`

`runward update` rafraîchit la méthode livrée sous `runward/workflows/`, les [règles de craft](https://runward.dev/docs/reference/rules/) sous `runward/rules/`, et les [échantillons d'adaptateurs de garde](https://runward.dev/docs/operating/wire-the-gate/) 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 :

```bash
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 :

```bash
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` :

```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.

## Voir aussi

- [Commandes CLI](https://runward.dev/docs/reference/cli/)
- [Brancher la porte](https://runward.dev/docs/operating/wire-the-gate/)
- [Catalogue des règles](https://runward.dev/docs/reference/rules/)
- [Reprendre un système existant](https://runward.dev/docs/operating/resume-existing/)