runward

RW™ · V0.18.0

Installer runward là où vous travaillez déjà.

Une avance ne vaut que si elle se distribue. On a vérifié, canal par canal, où la porte déterministe peut s'installer en un geste, et avec quelle force. Résultat : une famille de paquets, une même ligne partout, et un classement honnête de ce que chaque canal peut vraiment bloquer.

Une porte, tous les canaux, classés sans mentir

  • GitHub Action : la porte dure. Une action publiée, posée en contrôle requis, bloque au merge. C'est le canal le mieux aligné avec la gouvernance, ouvert, sans secret. Le levier maximal.
  • Plugin Claude Code, et ses jumeaux. Un plugin qui lance la porte en fin de tour, plus les mêmes déclinaisons pour Gemini CLI, Codex et Copilot : la même ligne, runward check --strict, au bon moment.
  • Les canaux à porte souple, dits souples. Cursor et Kiro laissent brancher un hook, mais leur fin de tour ne bloque pas dur : la porte y est par appel d'outil, et on le dit noir sur blanc plutôt que de le maquiller.
  • MCP : découverte, jamais une porte. Un outil MCP est appelé par le modèle, qui peut donc l'ignorer. On publie un descripteur pour être trouvable, et un README qui martèle : ce n'est pas un gate. Prétendre le contraire, ce serait vendre un juge mou déguisé en juge dur, exactement ce que runward refuse.

L'honnêteté comme argument

Dans un marché qui survend, dire « dure ici, souple là, simple découverte pour MCP » est en soi un signal de crédibilité. L'invariant tient partout : c'est l'opérateur qui installe, runward ne câble jamais rien tout seul ; chaque paquet est une fine coquille autour du même code de sortie ; et aucun agent n'est privilégié. La surface neutre reste AGENTS.md et les skills partagés.

Le geste de soumettre aux marketplaces reste le vôtre, comme la publication npm : les paquets sont prêts, jamais soumis dans votre dos.


Installer : npx runward init

Release v0.18.0 sur GitHub · La carte des canaux · CHANGELOG

← Toutes les nouveautés