# Sceller, règles et méthode

Sceller un franchissement via --freeze dans evidence-lock.json, où vivent les règles et le mapping, les frontières que runward ne franchit pas, et la méthode.

## Sceller un franchissement : `--freeze`

Une fois une garde stricte entièrement au vert, vous pouvez la sceller : `runward check --freeze` (implique `--strict`) hache les fichiers de preuve résolubles dans `runward/evidence-lock.json`. runward refuse de sceller une garde au rouge : "un sceau certifie un franchissement, pas un espoir". Un fichier scellé qui change ou disparaît ensuite échoue à `check --strict` jusqu'à ce que vous re-vérifiiez et re-scelliez.

Le pack scellé est une **preuve d'appui prête pour l'audit** qui *alimente* un [programme de conformité](https://runward.dev/docs/compliance/evidence/) (assemblez-le avec `runward compliance <regime>` ; la commande se décrit elle-même comme "a readiness draft, never a compliance claim") ; l'acceptation relève de l'auditeur : runward ne formule aucune revendication de conformité qui lui soit propre.

## Où vivent les règles et le mapping

Les règles CRITICAL/HIGH sont des fichiers markdown sous `runward/rules/` (la copie propre à la mission si présente, sinon les règles livrées avec le paquet). Le frontmatter YAML de chaque règle porte `impact:`, `phases: [...]`, et un `signature:` optionnel. Le mapping de phase est donc une propriété des règles elles-mêmes, et les planchers `EXPECTED_MAPPED` existent précisément pour que le mapping ne puisse pas être discrètement dépouillé afin de faire passer la garde sur un ensemble vide. La mission de référence livrée (`examples/request-triage/runward/`) est un exemple rempli de tout ce qui précède et ne livre pas de `rules/` propre, ce qui exerce le repli sur les règles du paquet.

## Frontières que runward ne franchira pas

- **runward encadre ; il ne génère pas.** L'agent écrit les livrables et le code ; runward lit les fichiers de la mission et les garde.
- **La garde est déterministe, zéro-LLM, zéro-réseau** (le contrôle ne lit que des fichiers locaux) : elle vérifie qu'une décision est *tracée* et pointe vers quelque chose de réel ; elle n'ouvre jamais le code du projet, ne lance pas de test, ne juge pas la qualité de l'implémentation. Le LLM vit dans votre harnais, pas dans la garde.
- **runward n'installe jamais de git hooks et n'écrit jamais dans `.git/`.** L'option `--hooks` exécute seulement des hooks écrits par l'opérateur depuis `runward/hooks.json` et est opt-in ; les adaptateurs livrés sous `templates/adapters/` sont des échantillons inertes que l'opérateur câble lui-même. Un agent peut *piloter* runward de bout en bout, y compris réaliser ce câblage sur votre consigne, mais runward ne modifie jamais votre dépôt en silence.

## Les workflows de méthode

Les phases sont des jalons gardés ; la *méthode* que votre agent suit pour les atteindre est livrée en workflows sous `runward/workflows/` :

- **`method`** est le chef d'orchestre : il séquence les six phases et délègue le détail de chacune à son propre workflow (`frame`, `architect`, `floor`, `iterate`, `govern`, `handover`, plus `brownfield` pour un démarrage non greenfield).
- **`decision-loop`** gouverne chaque décision structurelle : verrouiller une position avant de toucher au document, challenger et demander avant tout changement, un ADR par décision. Ne jamais éditer à l'instinct.
- **`review`** est un panel d'experts en lecture seule qui juge un document d'architecture sur sa solidité, sa cohérence et sa qualité éditoriale. Il critique, il ne réécrit jamais sans validation, et il se marie avec `decision-loop` (review fournit les yeux, decision-loop la méthode).
- **`verify`** est la passe indicative cite-vs-apply lancée au-dessus d'une garde stricte verte, couverte sur la [page Preuve & intégrité](https://runward.dev/docs/concepts/evidence/).

Ces workflows sont des consignes que l'agent lit et applique ; la garde déterministe reste la seule autorité.

## Pourquoi ce choix

Iterate (phase 4) n'a délibérément pas de fichier livrable gardé fixe, contrairement aux cinq autres phases. L'alternative, inventer un seul livrable "iterate.md" pour rendre les six phases uniformes, a été rejetée parce que l'itération est ouverte : chaque évolution est sa propre décision, donc l'artefact honnête est un ADR par bascule, soumis aux mêmes contrôles de ratification d'ADR et de dérive là où ces changements atterrissent. L'uniformité aurait forcé un fichier creux qui passe la garde sur rien.

De même, les planchers `EXPECTED_MAPPED` existent pour que le mapping de règles `phases: [...]` ne puisse pas être discrètement dépouillé pour faire passer `--strict` à vide : abaisser un plancher doit être une édition délibérée et tracée, pas un moyen invisible d'affaiblir la garde.

## Voir aussi

- [Les six phases](https://runward.dev/docs/concepts/six-phases/)
- [Les six phases en détail](https://runward.dev/docs/concepts/six-phases/frame-to-handover/)
- [Preuve et intégrité](https://runward.dev/docs/concepts/evidence/)
- [La preuve de conformité du système que vous livrez](https://runward.dev/docs/compliance/evidence/)