Relevé · journal de bord
Nouveautés.
Releases, évolutions de la porte de conformité et alignements écosystème. Daté, sourcé, sur preuve.
-
Treize agents ont audité runward. Verdict : pas fini.
Un test rouge invisible derrière un homonyme vert, dans l'outil qui vend « un test rouge n'est pas une preuve ». Et une profondeur de vérification écrite par l'auteur, silencieusement ignorée.
-
2 726 octets de texte suffisaient à passer notre porte
Le pire cas produisait la sortie la plus rassurante : 36 sur 36, 100 % vérifié, sur un projet vide. Et la moitié des correctifs écrits le matin refusaient des missions honnêtes l'après-midi.
-
Nous avons muté notre propre code. Six tests n'ont rien vu.
Sept erreurs dans la première version de cet article, dont deux défauts réels que nous avions déclarés inoffensifs. Corrigé, avec le raisonnement fautif laissé visible.
-
Le détecteur de fumée que personne n'a jamais testé
Nous avons cassé notre propre code à quarante-deux endroits pour voir combien de fois nos tests s'en apercevaient. Six fois, rien n'a sonné. Voici la méthode, en langage simple, et pourquoi elle compte si vous livrez sur preuve.
-
Deux règles violées, la porte au vert
Deux règles écrites, violées en une après-midi, sur du code que l'agent venait d'écrire, avec check --strict au vert. La porte se comportait comme déclaré ; la déclaration était incomplète. runward 0.26.0 la complète et ajoute rules --for.
-
Exécutable, inspectable, à état, gouverné : et gardé
Le survey « Code as Agent Harness » ferme sur quatre propriétés : executable, inspectable, stateful, governed. runward les incarne côté livraison, et occupe seul la case que le corpus laisse vide : la porte humaine déterministe de livraison.
-
La release est une porte, elle aussi
La chaîne de publication de runward applique le principe de sa porte à sa propre supply chain : la release est un geste humain, tout le reste est déterministe. OIDC sans jeton long-vécu, provenance SLSA, SBOM attestée, actions épinglées par SHA. Vérifiable, pas déclaré.
-
runward se pilote depuis votre agent
Un agent IA découvre, installe et exploite runward sans humain au clavier. Nouveau : runward wire reconnaît l'outil qui l'exécute ou vous demande lequel c'est, un défaut d'init neutre qui ne privilégie aucun agent, et runward check --json, un verdict machine déterministe.
-
Installer runward là où vous travaillez déjà
Une famille de paquets distribuables, une même ligne partout : runward check --strict. GitHub Action (porte dure en CI), plugin Claude Code, déclinaisons Gemini, Codex, Copilot, Cursor, Kiro. Chacune classée honnêtement par la force de sa porte. MCP = découverte, jamais une porte.
-
Un second audit, fermé au grand jour
On a relancé notre propre méthode sur nous-mêmes. Cinq failles introduites la veille, corrigées au grand jour : traversal, ReDoS, écart OSCAL/spec, portée du scellement. La date EU AI Act mise à jour, et la porte déterministe se branche dans BMAD comme reviewer. Deux releases dans la journée, la seconde répare la première.
-
La passation est gardée
« La passation se prouve par une tâche refaite sans vous » : la promesse était écrite, aucune porte ne la vérifiait. La sixième phase passe sous la porte : preuve de la tâche refaite, succession nommée, charter finalisé. Le mapping OSCAL devient une spec citable, et Kiro rejoint les adaptateurs.
-
Une preuve creuse ne passe plus
La porte vérifiait qu'une décision était tracée ; elle vérifie maintenant que la trace pointe vers quelque chose de réel. Pointeurs typés, signatures de règles, dérive bloquante, scellement d'un vert. Et runward passe désormais sa propre porte en CI, y compris coupé du réseau.
-
La porte ne peut plus mentir
Un audit multi-agent a confirmé que la chaîne tourne verte de bout en bout, et signalé des défauts d'intégrité de la porte : ces chemins par lesquels une mission pouvait sembler finie sans l'être. La v0.14.0 les ferme. Un vert de porte redevient une vérité sur laquelle s'appuyer.
-
Les deux visions, un seul chemin gardé
runward package les deux visions de la doctrine : le domaine applicatif et la topologie d'exécution, où tourne chaque port et sous quelle souveraineté. La section 15 orpheline devient un livrable gaté, avec sa propre phase de conformité vérifiée par la porte. Déterministe, jamais un runtime.
-
Des packs de preuve, pas de la doc morte
runward complianceassemble ton travail de conformité en un dossier de preuve cadré par régime (ISO 42001, NIST, EU AI Act) et l'exporte en OSCAL. Couche de provenance amont, jamais un claim de conformité. -
Rétro-documentation et compliance régionale
runward reconstruit le kit de passation d'un système existant (la transmission à rebours), et la conformité devient un profil régional, sécurité d'abord. La porte reste déterministe, zéro-LLM, read-only.
-
La spec, c'est la partie facile
Le spec-driven a automatisé l'écriture de l'intention. Mais ~95% des projets GenAI calent après, sur le run, pas sur la spec. Là où runward commence.
-
Alignement audit-ready
Le manifeste de conformité devient une preuve d'appui prête pour l'audit (OWASP ASI, 54 règles), intrant de votre dossier ISO 42001 / EU AI Act, et la porte déterministe se câble dans chaque harnais : git, CI, Claude Code. Sans jamais devenir un runtime.
-
Durcissement de la porte de conformité
La porte déterministe qui vérifie, règle par règle, que le code livré porte une décision tracée devient difficile à tromper. Toujours zéro-LLM, toujours possédée par l'opérateur.