Après la spec : le comparatif.

runward, Spec Kit, BMAD, Kiro, OpenSpec et Spec Kitty façonnent tous la manière dont un agent IA construit ; ils se séparent sur deux axes : jusqu'où chacun va dans le cycle, et comment il vérifie le résultat.

Cette page cartographie ce que chacun fait vraiment, décrit d'après ses propres docs (sources en fin de page), et où le terrain de runward est différent. Une distinction lève l'essentiel de la confusion d'abord.

Harnais ou scaffold

Un harnais est ce qui fait tourner votre agent : Claude Code, Cursor, Codex, GitHub Copilot. Il lit vos fichiers, appelle des outils, édite votre code en boucle, avec un modèle IA qui fait le raisonnement. C'est le moteur.

Un scaffold est la méthode posée par-dessus le harnais pour que l'agent construise comme un ingénieur plutôt qu'à l'improvisation : des consignes, des règles et des skills qui lui disent comment travailler, et, pour certains, un contrôle sur le résultat. Spec Kit, BMAD, Kiro, OpenSpec, Spec Kitty et runward sont tous des scaffolds. La boucle appartient au harnais et le raisonnement au modèle ; le scaffold façonne comment l'agent construit.

Tous font écrire du code par votre agent, runward compris. Donc la vraie question au moment de choisir n'est pas « est-ce que ça construit ? », ils le font tous. C'est ce que chacun fait en plus de générer du code, parce que c'est là qu'ils se séparent.

Une ligne par outil

• GitHub Spec Kit transforme une spec écrite en code par un flux figé (/constitution → /specify → /plan → /tasks → /implement). Le meilleur pour cadrer l'intention avant que l'agent construise. Natif GitHub, portée énorme.
• BMAD fait tourner une équipe agile simulée de personas IA (analyste, PM, architecte, dev, QA) qui mènent un projet du brief au code. Ludique, agréable à regarder, une communauté grosse et active.
• AWS Kiro est un IDE IA bâti autour des specs (requirements → design → tasks), avec des fichiers de pilotage et des hooks. Intégration AWS profonde ; vit dans l'éditeur.
• OpenSpec est une boucle de spec légère (propose → apply → archive) qui se branche sur beaucoup d'agents.
• Spec Kitty est un « delivery control plane » : une boucle de spec avec tableau Kanban, lanes de work-packages, gardes déterministes et un journal de preuve persistant. Ce qui approche le plus le terrain de runward.
• runward pose une porte déterministe et zéro-LLM sur les décisions porteuses derrière la livraison de votre agent : la preuve vérifiée et scellée, la passation gardée, et la trace qui s'exporte en pack OSCAL standardisé qu'un auditeur lit. Fait pour la livraison à enjeux, régulés compris.

Comment chacun vérifie le résultat

C'est la différence la plus tranchante, et elle se vérifie dans les docs de chacun. Quand un scaffold rend son verdict sur la livraison, le travail est-il acceptable, est-ce terminé, la plupart laissent l'IA elle-même juge, et le verdict est advisory : rien ne bloque.

• Spec Kit : /analyze est une « analyse de cohérence et de qualité inter-artefacts, non destructive » qui produit un rapport Markdown ; /checklist écrit des « tests unitaires pour les exigences », donc il vérifie la spec, pas le code. [1]
• BMAD : le persona QA rend une « Quality Gate Decision : PASS / CONCERNS / FAIL » que les docs qualifient, mot pour mot, d'« advisory … fournit des recommandations, ne bloque pas ». [2]
• OpenSpec : /opsx:verify demande au modèle de valider « complétude, correction et cohérence » et « ne bloque pas l'archivage » ; le déterministe openspec validate ne vérifie que la structure de la spec. [4]
• Kiro : l'exception partielle. Il génère des property-based tests depuis les exigences EARS et les exécute contre l'implémentation, mais l'exécution est optionnelle et le résultat interprété par un humain, sans porte imposée. [3]
• Spec Kitty : le vrai outsider. Il pose des gardes déterministes (une « hard pass/fail gate » e2e, pytest code non nul ⇒ FAIL) et il garde la passation, mais son verdict d'acceptation reste une revue IA, et sa preuve est du YAML maison, pas un format standardisé. [5]

Le contrôle de runward est du code déterministe, sans aucun modèle dans le chemin de la porte : la même entrée donne le même verdict, et aucun prompt ne l'embobine (ADR-0001). Une règle que l'agent devait suivre mais a sautée en douce échoue quand même. Son verdict est volontairement plus étroit et plus dur : il prouve que les décisions porteuses ont été prises, tracées, et adossées à une preuve qui résout, y compris les tests qui, eux, exercent le code ; il ne juge jamais la qualité du code lui-même, et le dit. Une garantie dure ne se fabrique pas à partir d'un juge mou.

Scaffold	Le verdict est rendu par	Passation gardée	Audit lisible par machine
Spec Kit	l'IA (/analyze, Markdown advisory) [1]	non [1]	non [1]
BMAD	un persona IA (« advisory … ne bloque pas ») [2]	convention seulement [2]	YAML maison [2]
Kiro	des tests générés par l'IA, optionnels + lus par un humain [3]	non (confirmation humaine) [3]	non [3]
OpenSpec	l'IA (/opsx:verify, non bloquant) [4]	non [4]	JSON structurel seulement [4]
Spec Kitty	une revue IA enveloppée de gardes déterministes [5]	oui, déterministe [5]	YAML maison [5]
runward	du code déterministe, aucun LLM dans la porte	oui, gardée	oui : OSCAL standardisé

Ce que runward réunit, et personne d'autre

Quatre terrains, et un contrôle au niveau du code (juillet 2026) confirme qu'aucun autre scaffold ne les réunit. Chacun existe quelque part ; c'est la combinaison qui est distincte, et chacun est une décision datée, écrite, pas un slogan.

1. Il vérifie la preuve, pas seulement l'affirmation. Quand une règle est marquée « appliquée », runward vérifie que le pointeur résout vers un contenu réel, non vide (ADR-0019) ; une règle peut déclarer la forme que sa preuve doit contenir, si bien que citer un garde jamais livré fait rougir le contrôle (ADR-0020). Voir preuve et intégrité.

2. Preuve scellée. runward check --freeze empreinte chaque fichier de preuve (SHA-256) dans evidence-lock.json ; si un fichier scellé change en douce ensuite, la porte rougit jusqu'à re-vérification (ADR-0021). Pas « une case cochée » : « ce que la case désigne est vraiment là », et le reste.

3. Passation gardée. La passation est une phase gardée, pas un dossier qu'on dépose : « la succession se prouve par une tâche réelle que l'équipe qui reprend refait sans vous » passe ou échoue comme toute autre porte (ADR-0026). Personne d'autre ne porte la mission au-delà du code testé, sauf Spec Kitty, d'où la frontière tracée exactement plus bas.

4. Preuve lisible par machine, dans un format publié. runward compliance émet un pack de preuve OSCAL, construit à partir des décisions tracées et du statut réel de la porte, qu'un outil de conformité (Vanta, Drata) ou un auditeur peut lire, et le mapping décision → ADR → manifeste → OSCAL est publié comme une spécification versionnée et citable (ADR-0025). Il alimente un dossier ISO 42001 ou EU AI Act, voir preuve de conformité, et ne dit jamais que vous êtes « conforme » ; aucun outil ne confère ça.

Sous ces quatre terrains, deux invariants. La porte est un port avec adaptateurs de harnais, donc aucun agent n'est privilégié et runward n'installe jamais de hook ni ne se câble tout seul (ADR-0012). Et la porte est déterministe et zéro-LLM (ADR-0001) : le modèle vit dans votre harnais, en amont ; la porte, elle, n'appelle jamais de modèle, voir la porte déterministe.

La frontière : runward vs Spec Kitty

Des cinq, seul Spec Kitty approche : il garde la passation de façon déterministe et émet une trace d'audit lisible par machine. L'écart est étroit, et mérite d'être tracé exactement.

Deux choses les séparent. D'abord le verdict d'acceptation : chez Spec Kitty, « les critères d'acceptation sont-ils satisfaits » est une revue IA enveloppée de gardes déterministes [5] ; chez runward, le verdict de conformité aux règles est du code, sans aucun modèle dans le chemin (ADR-0001). Ensuite l'artefact d'audit : la preuve de Spec Kitty est du YAML maison, par mission [5] ; celle de runward est de l'OSCAL standardisé qu'un outil GRC ingère, avec un mapping publié et citable (ADR-0025). Même ambition de forme : la preuve de runward est interopérable, et son verdict n'a aucun juge mou à l'intérieur.

Pourquoi « déterministe » compte, maintenant

Deux signaux de 2026 font de ce parti pris plus qu'une préférence. Le programme fédéral américain FedRAMP (RFC-0024) a tracé une ligne dure : les sorties probabilistes générées par IA ne doivent pas servir de preuve de conformité factuelle. Et l'affaire Delve, une startup exclue de Y Combinator pour des audits SOC 2 pré-remplis par IA, a montré au marché pourquoi. Une preuve produite par un modèle est une preuve qu'on ne peut pas croire. Une porte déterministe, sans aucun modèle dans son chemin, est la réponse que les deux désignent.

Ce qui est pareil pour tout le monde

Deux choses qu'on prend pour une différence, et qui n'en sont pas :

• Encadrer l'agent. Tout scaffold le fait. C'est la catégorie, pas un avantage.
• Les skills. Le format SKILL.md (« Agent Skills ») est devenu un standard partagé, et Spec Kit, BMAD, OpenSpec et runward en shippent tous. Les skills sont du table-stakes. Ce qui distingue runward, c'est le contrôle en code sous les skills, la seule chose qu'aucun des autres n'a.

Quand choisir lequel

• Spec Kit si vous voulez la meilleure boucle « spec vers code » et l'écosystème GitHub.
• BMAD si le côté « équipe agile IA » et une communauté vivante vous parlent.
• Kiro si vous vivez dans un éditeur natif AWS.
• OpenSpec si vous voulez une boucle de spec légère sur beaucoup d'agents.
• Spec Kitty si vous voulez un tableau de livraison avec gardes déterministes et un journal de preuve par mission.
• runward si vous voulez que votre agent construise un vrai système qui survit à la prod, et que vous voulez défendre comment il a été construit, le transmettre proprement, et montrer à un auditeur un pack de preuve standardisé. Vous ne troquez pas la livraison contre le contrôle : vous avez les deux.

Et les orchestrateurs ? (LangGraph, CrewAI, OpenAI Agents SDK)

Autre question, donc pas un concurrent. Ces frameworks résolvent l'exécution : comment l'agent tourne, sa mémoire, ses outils, son graphe d'étapes. runward résout la livraison : comment le projet se cadre, se décide, se construit et se transmet. Deux choses à dire, parce qu'elles tranchent dans l'autre sens que les scaffolds :

• runward n'en a pas besoin. Sa doctrine nomme les standards de l'écosystème comme des contrats de port versionnés plutôt que de les implémenter (ADR-0011) : vous gardez une architecture propre et modulaire, chaque capacité derrière un port stable, remplaçable sans toucher au reste, sans couche d'abstraction imposée, plus maintenable, plus lisible, moins de lock-in.
• runward compose avec. Si un déclencheur réel justifie un orchestrateur, il entre comme un adaptateur optionnel derrière un port, et runward gouverne sa livraison comme le reste. runward ship même des adaptateurs inertes vers les scaffolds concurrents (ADR-0027) : il tourne à l'intérieur, en complément, jamais privilégié.

Donc runward tient seul, et fonctionne avec eux si vous voulez. Il n'en dépend jamais.

Le double vide

Le même constat se lit depuis l'autre rive, celle de la recherche sur les harnais. Le survey de champ « Code as Agent Harness » (arXiv 2605.18747 ; affiliations affichées : Meta, Stanford, UIUC), qui cartographie le code comme milieu d'action des agents, ne mentionne ni Spec Kit, ni OpenSpec, ni BMAD, ni aucune méthode de livraison : zéro occurrence dans ses sources, vérifié en juillet 2026. Il traite même l'intention du développeur en « latent state », un état que l'agent doit inférer, jamais l'intrant d'une méthode de livraison. Le vide est donc double : le monde spec-driven cadre l'intention et s'arrête avant le run ; le monde des harnais fait tourner l'agent et ne dit rien de la livraison. Un survey décrit un paysage, il n'arbitre pas entre outils ; ce qu'il montre ici, c'est une case que personne n'occupe. runward tient cette intersection : la spec comme intrant, la porte déterministe comme verdict, la livraison comme objet.

En une ligne

runward, c'est l'ingénierie qui fait tenir un système agentique : chaque décision porteuse prise, tracée et prouvée avant la prod, vérifiée par du code, prête pour l'audit.

Votre agent construit le vrai système, dans des garde-fous ; runward exige et vérifie les décisions qui le font tenir : 64 règles d'ingénierie, six portes franchies sur preuve, chaque décision datée et justifiée, un contrôle déterministe que rien ne peut embobiner, une preuve vérifiée et scellée plutôt que simplement citée, une passation gardée sur une tâche que l'équipe refait sans vous, et une trace d'audit prête pour Vanta, Drata ou votre auditeur, dans un format publié et citable. C'est la méthode Forward Deployed Engineer, packagée depuis une doctrine de 60 pages (Concevoir et exécuter des systèmes agentiques, CC BY-ND 4.0), rendue exécutable.

Essayez en une commande : npx runward init --example pose une référence complète et fonctionnelle, à lire et relancer. Pour vous lancer : npx runward init, ou runward.dev.

Sources

Les descriptions des concurrents sont tirées de leur propre documentation, en juillet 2026, pas de résumés tiers.

• [1] Spec Kit : github.com/github/spec-kit (README, templates/commands/analyze.md, checklist.md, spec-driven.md).
• [2] BMAD-METHOD : github.com/bmad-code-org/BMAD-METHOD (docs/user-guide.md, bmad-core/templates/qa-gate-tmpl.yaml).
• [3] AWS Kiro : kiro.dev/docs (specs, specs/correctness, quick-plan, pricing).
• [4] OpenSpec : github.com/Fission-AI/OpenSpec (docs/concepts.md, commands.md, cli.md).
• [5] Spec Kitty : github.com/Priivacy-ai/spec-kitty (ADR e2e-hard-gate, retrospective-gate, review guidelines.md, retrospective.yaml).