# Le périmètre : runward et son voisinage

Une carte, deux axes : quel moment de l'arc de livraison chaque outil gouverne, et qui rend le verdict. Spec-driven, harnais, custody d'artefact, admission — et la case que runward occupe seul. Constats datés d'août 2026.

Cette page situe runward parmi ses voisins — en amont, en aval, et dans les harnais — sur les deux seules questions qui les distinguent mécaniquement : **quel moment de l'arc de livraison chacun gouverne**, et **qui rend le verdict**. Constats datés d'**août 2026**, pris de la documentation de chaque outil.

> **Schéma.** Deux axes, et ils suffisent à situer tout le voisinage. En abscisse, le moment gouverné : de l’intention (la spec) jusqu’à l’exécution en production, en passant par la construction, le build, la custody d’artefact et la promotion. En ordonnée, qui rend le verdict : un modèle qui juge (avis, non bloquant), un humain qui relit, ou du code déterministe. Les outils spec-driven (Spec Kit, OpenSpec, BMAD) occupent le moment de l’intention avec un verdict de modèle ; les harnais (Bugbot, Copilot review) jugent le code au moment de la revue, toujours par modèle ; Chainloop, Kosli et JFrog gouvernent l’artefact publié, sa custody et sa promotion, par du code ; Kyverno et OPA admettent à l’exécution. runward est seul sur son point : le moment de la construction, avant le merge, avec un verdict de code déterministe. Personne ne dispute cette case, et c’est ce que la carte montre — pas une supériorité, une position.

## Ce que la carte dit

Trois amas, et une case tenue par un seul outil.

**En bas à gauche : l'intention, jugée par un modèle.** Spec Kit, OpenSpec, BMAD et les harnais de revue occupent le début de l'arc. Ils cadrent l'intention, produisent du code, et quand ils rendent un verdict, c'est un modèle qui l'a rendu — leurs propres docs le disent : « advisory … fournit des recommandations, ne bloque pas », « ne bloque pas l'archivage ».

**À droite : l'artefact publié, gouverné par du code.** Chainloop, Kosli, JFrog Evidence, puis Kyverno et OPA à l'admission. Verdicts déterministes, mais sur un **objet déjà construit** : sa provenance, sa custody, sa promotion, son admission.

**Entre les deux, une case que personne d'autre n'occupe** : le moment de la construction — après l'intention, avant le merge — avec un verdict rendu par du code. C'est là que runward se tient. Ce n'est pas une supériorité, c'est une position : les autres n'y sont pas parce que ce n'est pas leur métier.

## Le tableau, outil par outil

| Outil | Objet gouverné | Moment | Verdict rendu par | Ingère | Émet |
|---|---|---|---|---|---|
| **Spec Kit** | la spécification et sa cohérence | intention | un modèle (`/analyze` produit un rapport Markdown) | — | des artefacts de spec |
| **OpenSpec** | le delta de spécification | intention | déterministe pour la **structure** (`openspec validate`), un modèle pour le fond (`/opsx:verify`, « ne bloque pas ») | — | des propositions archivées |
| **BMAD** | le cycle par personas | intention → code | un modèle (« Quality Gate Decision », qualifiée d'advisory par ses docs) | — | PRD, stories |
| **Spec Kitty** | la revue et l'entrée du code | code | des gardes déterministes e2e, **plus** une revue IA pour l'acceptation | — | du YAML maison |
| **Harnais** (Bugbot, Copilot review, Codex) | le code proposé | revue | un modèle | le diff | des commentaires |
| **runward** | **les décisions de construction** | **avant le merge** | **du code déterministe** | des rapports committés (JUnit, SARIF, couverture, lint, SBOM) | un verdict attesté, re-dérivable hors ligne (in-toto, VSA, SARIF) |
| **Chainloop** | ce que le build a produit | build | du code (contrat de pipeline) | 17 types de preuve (SBOM, VEX, SARIF…) | des attestations in-toto signées, stockées |
| **Kosli** | l'artefact et son trail | build → release | du code | des fichiers de preuve, y compris externes | un Evidence Vault immuable |
| **JFrog Evidence** | l'artefact, le build, le Release Bundle | build → promotion | du code | des preuves externes signées | des attestations attachées à l'artefact |
| **Kyverno · OPA** | le workload admis | exécution | du code | des attestations signées | une admission, ou un refus |

## Les deux questions à se poser

Devant un outil du voisinage, deux questions suffisent à savoir s'il chevauche runward :

1. **Gouverne-t-il l'arbre de travail avant le merge, ou un artefact après le build ?** Si c'est le second, il n'y a pas de recouvrement : le verdict de runward devient une preuve de plus dans sa chaîne ([l'étage release](https://runward.dev/docs/compare/release-layer/) détaille les recettes).
2. **Qui rend son verdict ?** Si c'est un modèle, le verdict est un avis : il ne se re-dérive pas, deux exécutions peuvent diverger, et l'agent qui a produit le code participe au jugement. Ce n'est pas une critique, c'est une propriété — mais elle décide de ce que le verdict peut servir à prouver.

## Ce que la carte ne dit pas

Elle ne classe pas par qualité, par maturité, ni par adoption : ce sont des axes réels, et ils n'appartiennent pas à une page technique. Elle ne dit pas non plus qu'occuper une case libre est un avantage — une case peut être libre parce qu'elle n'intéresse personne. Ce qu'elle dit est plus étroit et vérifiable : **pour un système agentique, les décisions porteuses sont prises avant le merge, et aucun autre outil de cette carte ne rend de verdict déterministe à ce moment-là.**

## Voir aussi

- [Après la spec : le comparatif](https://runward.dev/docs/compare/)
- [L'étage release : Kosli, JFrog, Chainloop](https://runward.dev/docs/compare/release-layer/)
- [Concepts : la porte déterministe](https://runward.dev/docs/concepts/the-gate/)
- [Preuve et intégrité](https://runward.dev/docs/concepts/evidence/)