runward

RW™ · V0.8.0

Durcissement de la porte de conformité.

La porte déterministe de Runward, celle 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.

Un test terrain avait révélé le trou : un agent pouvait citer une règle de craft sans jamais l'appliquer, et la porte passait quand même au vert. La v0.8.0 ferme ce trou et durcit la porte contre le contournement, sans jamais trahir le pari fondateur.

Ce qui change

  • Non-vacuité. Un plancher de règles routées par phase et des raisons n/a non triviales : on ne neutralise plus la porte en une édition silencieuse.
  • Lint de forme. Un manifeste qui liste une règle deux fois, ou référence un slug qui n'existe pas (une coquille qui masquait un trou), est attrapé avant le contrôle de fond.
  • Détection de dérive. Un pointeur applied dont le fichier ne résout plus est signalé : le manifeste cesse de pourrir en silence quand le code bouge.
  • Migrations guidées. Une règle renommée devient une migration guidée, pas une casse.
  • Messages actionnables. Chaque violation porte désormais son correctif.
  • Vérification LLM, en advisory. Un workflow verify adversarial (« ce code applique-t-il la règle qu'il nomme, ou il la cite seulement ? »), jamais dans le code de sortie, jamais bloquant.
  • Seam de hooks. runward check --hooks lance des commandes d'opérateur autour de l'audit, en opt-in : un clone n'exécute rien par surprise.

L'invariant tenu

La porte reste déterministe, zéro-LLM, zéro-run. La couche de vérification LLM et les hooks vivent à côté de la porte, subordonnés et optionnels, jamais dedans. Une porte qui ne se laisse pas jailbreaker par injection, c'est l'argument de fond : on ne le sabote pas.

Chaque durcissement a été décidé avant le code, verrouillé en ADR, prouvé par des tests : la méthode de Runward appliquée à Runward.


Installer : npx runward init

Release v0.8.0 sur GitHub · CHANGELOG

← Toutes les nouveautés