La frontière : runward ne se câble jamais tout seul.

La seule frontière que runward ne franchit jamais : câbler la garde

La contradiction apparente

Voici la contradiction apparente à résoudre de front : comment runward peut-il être « opérable de bout en bout par un agent » alors que chaque guide dit vous installez le déclencheur manuellement ?

La résolution

Câbler la garde dans votre dépôt est la seule chose que runward ne fait jamais de manière autonome, et la seule chose qu'il ne fait pas même pour lui-même. runward wire détecte et affiche une recommandation ; il « ne câble rien, vous êtes les mains de l'opérateur (ADR-0012) ». runward n'écrit jamais dans .git/, ne modifie aucun .claude/settings.json, n'enregistre aucune CI (décision ADR-0012). Les adaptateurs sont du texte d'échantillon inerte sous runward/adapters/ qui ne fait rien tant qu'un opérateur ne les copie pas en place.

« Opérable de bout en bout par un agent » ne veut pas dire que runward mute silencieusement votre dépôt. Cela veut dire qu'un agent peut piloter chaque étape, y compris réaliser le câblage, mais le câblage requiert spécifiquement l'approbation explicite de l'opérateur. La charte est précise : « Proposez-le et n'agissez que sur approbation explicite ; ne le câblez jamais en silence... vous êtes les mains de l'opérateur, et l'opérateur possède la garde ». L'amendement du 2026-07-12 d'ADR-0012 le précise : l'agent propose et l'opérateur décide : « la différence, c'est le consentement : l'agent propose et l'opérateur décide, contre runward agissant sans l'acte de l'opérateur ».

Pourquoi cette frontière est une fonctionnalité, pas une capacité manquante

• Aucun outil ne touche silencieusement à votre git ou à votre CI. Installer automatiquement un hook dans .git/hooks/ ou modifier un fichier de configuration est « une exécution surprise câblée dans un dépôt sans l'acte de l'opérateur » : rejeté pour raisons de sécurité. Une garde qu'un outil installe dans votre dos est exactement la classe de piège que runward refuse de devenir.
• Le cadre ne doit jamais devenir un runtime. Un démon, un observateur de fichiers ou un runtime de hooks géré par runward « transformeraient chacun runward d'un cadre en un runtime : la seule chose que la doctrine lui interdit de devenir ». Garder le câblage dans les mains de l'opérateur maintient runward comme un cadre.
• La détection reste honnête. ADR-0030 préserve ADR-0012 exactement : « la détection informe, le geste approuvé de l'opérateur câble ». runward, au plus, affiche la commande exacte.

Ce que le CHANGELOG voulait dire

Concrètement : le « installer et exploiter » du CHANGELOG renvoie à la mise en place de la mission (init) et à l'exécution de toute la chaîne (check, manifest, compliance, ...) de manière autonome, plus le câblage du déclencheur assisté par l'agent et gardé par approbation. Il n'a jamais signifié que runward atteigne .git/ de lui-même. Il n'y a pas de contradiction : l'étape manuelle et approuvée est la couture de consentement délibérée.

Conformité et périmètre, dit clairement

La garde est déterministe et hors ligne

La garde est déterministe, zero-LLM et hors ligne : l'audit « reste déterministe, zero-LLM, zero-run », il lit et hache des fichiers, il n'exécute jamais votre code. Le prisme par défaut de runward est l'artisanat d'ingénierie et la sécurité ; un régime réglementaire est un prisme optionnel, et l'adaptateur CI est la couture où cette preuve est produite.

Ce qu'est la sortie, et ce qu'elle n'est pas

Ce que runward produit est une preuve d'appui prête pour l'audit qui alimente ou appuie un programme de conformité (régimes : iso-42001, nist-ai-rmf, eu-ai-act) ; il ne rend pas un système conforme ni certifié. La CLI elle-même présente la sortie comme « un brouillon de préparation, jamais une revendication de conformité ». Cette détermination relève de l'auditeur.

Pourquoi ce choix

Le choix porteur et l'alternative rejetée

Le choix de conception porteur est que runward ne câble jamais la garde lui-même, même s'il est « opérable de bout en bout par un agent ». L'alternative rejetée était le câblage automatique orienté détection : à l'init ou à la détection du harnais, installer silencieusement le hook git dans .git/hooks/ ou modifier le fichier de configuration du harnais.

Elle a été rejetée pour deux raisons

• Sécurité : l'installation silencieuse est « une exécution surprise câblée dans un dépôt sans l'acte de l'opérateur », la classe de piège exacte que runward refuse de devenir.
• Doctrine : un démon, un observateur ou un runtime de hooks géré par runward « transformerait runward d'un cadre en un runtime : la seule chose que la doctrine lui interdit de devenir ».

Le modèle retenu

Le modèle retenu garde le câblage comme un geste de consentement de l'opérateur qu'un agent peut réaliser sur approbation explicite (amendement du 2026-07-12 d'ADR-0012). La détection (ADR-0030) est superposée par-dessus, au mieux et en lecture seule, avec wires:false comme invariant vérifiable par machine, précisément pour que la reconnaissance ne puisse jamais glisser vers l'action silencieuse. Cela fait de la frontière une couture de consentement conçue, pas une capacité manquante.

Ce qui vient ensuite

ADR-0030 fixe un complément additif et non cassant : étendre la couverture --json au-delà de check à status, doctor, manifest et compliance à mesure que la boucle de pilotage autonome réclame chaque chemin de lecture.

Le déclencheur de réévaluation daté de l'ADR rouvre la conception de la détection si :

• une convention d'exécution transversale aux harnais pour l'identité d'agent émerge (un marqueur d'environnement standard adopté par plus de deux harnais majeurs), ou
• la boucle de pilotage a besoin d'un chemin de lecture qui n'a pas encore de --json

toujours sans que runward n'écrive lui-même un canal.