Sceller, règles et 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é (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é.

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.