Plan produit 2026-Q4¶
Document de référence du dépôt
Guilhem-Bonnet/Grimoire-kitpour le dernier trimestre 2026. Source : cadrage arbitré avec Guilhem le 2026-09-16 (cible, promesse, métriques, critères d'arrêt, gouvernance, risques, phases) et la veille du même jour (panorama, matrice de parité, idées à récolter). Ce document ne les paraphrase pas en les affaiblissant ; il les organise et vérifie chaque affirmation sur le kit contre le code, fichier cité.Doctrine : ce plan vit dans le dépôt Grimoire-kit, pas dans les
planning-artifactsde la Forge — la Forge est l'atelier, Grimoire-kit est le produit.Issue de suivi générale : #557. Une issue par phase : #551 (phase 1), #552 (phase 2), #553 (phase 3), #554 (phase 4), #555 (phase 5), #556 (phase 6). Phase 2bis « Cœur », insérée le 2026-09-17 : #582.
Mise à jour du même jour (matin du 2026-09-16, décisions Guilhem) : délégation optimale plutôt que coût (§2 métriques 4-5 et 4bis, §3), banc à trois bras sans plafond en dollars (§3, §7), deux axes phase/finition déclarés et propagés dans les tâches (§4 phase 4 réordonnée, nouvelles sections « Phase et finition » et « Délégation optimale »). Ces décisions ne s'affaiblissent pas d'un cadrage à l'autre ; elles se précisent.
Mise à jour du 2026-09-17 (verdict du banc à trois bras, graine 551, rapport, diagnostic
docs/bench/diagnostic-surcout-kit-2026-09-17.md) : ARRÊT du critère d'arrêt §3 (§2 métriques mesurées, §3 verdict, §7 risques). Les extras du plan (phases 3/4) sont gelés jusqu'à un rejeu du banc au coût et à la réussite requis ; nouvelle phase 2bis « Cœur » (issue #582) insérée entre les phases 2 et 3 pour retravailler le cœur avant toute reprise de parité. Correction du lot 5.5 (§6).
1. Cible et promesse¶
Répartition cible des utilisateurs (décision Guilhem) :
- Développeur seul : 50 %
- Entreprise : 30 %
- Équipe : 20 %
Promesse : « La couche qui rend le travail de tes agents de code prouvé, moins cher et portable entre hôtes. »
| Segment | Ce que la promesse tient |
|---|---|
| Développeur seul | Moins de coût, moins de manques d'agents, un reçu à chaque tâche, sans usine à monter. |
| Entreprise | Reçu vérifiable par un tiers, politiques de session, SLO de coût, traces OTel. |
| Équipe | Mémoire et propositions partagées, flotte pilotée, revue de mise à jour. |
2. Métriques de succès¶
Valeurs mesurées le 2026-09-16 sur un projet jetable (grimoire init . --backend
local, GRIMOIRE_NO_COCKPIT=1, HOME isolé), venv grimoire-kit==3.53.0
installé depuis ce worktree. Détail des commandes dans la note sous le tableau.
| # | Métrique | Valeur actuelle | Cible | Comment mesurée | Phase |
|---|---|---|---|---|---|
| 1 | Temps jusqu'au premier reçu (install → premier flow gouverné avec reçu) | pas de commande grimoire receipt aujourd'hui (n'existe pas dans le code, voir §6) ; proxy grimoire init seul = 0,24 s (mesuré, /usr/bin/time -v) ; un flow complet avec preuve exige une boucle hôte (LLM) donc à mesurer sur le banc |
60 s | Banc à trois bras, chrono install → premier grimoire flow run clos avec pack de preuve |
1, 4 |
| 2 | Commandes à connaître pour la première heure | 49 commandes de premier niveau dans grimoire --help (comptage exhaustif, voir note) |
≤ 5 | grimoire --help, liste des commandes citées dans docs/getting-started.md |
2 |
| 3a | Surcoût du kit — latence hook | ~0,05 s (50 ms) mesuré (5 exécutions, time echo '{}' \| grimoire-hook --host claude --event PreToolUse) |
≤ 60 ms | Moyenne sur 5 exécutions à froid, projet jetable | 2 |
| 3b | Surcoût du kit — tokens injectés par tour | SessionStart : 1409 caractères ≈ 352 tokens (persona d'entrée, additionalContext) ; PreToolUse (hôte Claude Code) : 0 — l'hôte est blocking_hooks, le kit répond par permissionDecision/permissionDecisionReason, jamais additionalContext, voir src/grimoire/hosts/runtime.py:166-174 |
≤ 1500 tokens par tour | Taille de hookSpecificOutput.additionalContext retourné par grimoire-hook, caractères / 4 |
2 |
| 4 | Délégation optimale — part des tâches résolues au palier choisi au départ, sans escalade subie | mesuré 2026-09-17 (banc, graine 551, rapport ci-dessous) : la cascade de dispatch n'est jamais sollicitée sur le chemin claude -p (dispatch_stats.overall.total == 0 sur 60/60 runs kit) — la métrique ne s'applique pas à ce chemin ; mécanisme de décision (flows/pilot.py, missions/dispatch.py::start_tier_for) réel mais non exercé ici |
en hausse, comparé à l'hôte nu — à mesurer sur un bras « flow du kit » séparé (phase 2bis) | Banc à trois bras, proportion de tâches closes sans franchir max_escalations (flows/pilot.py) |
1, 4 |
| 5 | Délégation optimale — escalades justifiées vs subies, temps avant demande d'aide (quand elle était nécessaire), boucles détectées avant N tours | mesuré 2026-09-17 (banc, graine 551) : tours médians 6,0 (nu) / 7,0 (ecc) / 19,0 (kit), pass^k 90 % / 90 % / 85 % — le surcoût de tours du kit n'est pas compensé par une meilleure détection d'échec (diagnostic §1.4) | escalades majoritairement justifiées, boucles détectées avant le palier suivant | Banc à trois bras, ordre de comparaison qualité (gates/revue/finition) puis temps puis coût, traces missions/dispatch_history.py |
1, 4 |
| 4bis | Coût par tâche résolue vs hôte nu, à réussite égale (mesuré en conséquence de la délégation, jamais visé pour lui-même) | mesuré 2026-09-17 (banc, graine 551) : 1,247 $ (kit) vs 0,399 $ (nu) = 312 % du coût de nu, pour une réussite égale ou légèrement inférieure (90,0 % vs 91,7 %, IC95% chevauchants) — voir verdict §3 | ≤ 50 % | Banc à trois bras (Claude Code nu / Claude Code + ecc / Claude Code + grimoire-kit, mêmes modèles, k = 3), coût réel par tâche — dernier critère de comparaison, après qualité et temps | 1 |
| 6 | Manques d'agents par session (courbe d'apprentissage) | à mesurer (banc) — le mécanisme existe (grimoire agent-miss, src/grimoire/missions/*, propositions), aucune série session 1 → session 10 publiée |
-50 % entre session 1 et session 10 | grimoire agent-miss cumulés par session sur un projet suivi |
4 |
| 7 | Hôtes à parité (même flow, même reçu) | 2 émetteurs riches (src/grimoire/hosts/emitters/claude_code.py, copilot.py) + 1 émetteur générique en prose (generic.py) pour tous les autres hôtes |
5 (Claude Code, Copilot, Cursor, Codex, Gemini) | Un émetteur riche par hôte dans src/grimoire/hosts/emitters/ |
3 |
| 8 | Sécurité — suite d'injections / CVE | aucune suite d'injections trouvée dans tests/ (recherche *injection* vide) ; CVE ouvertes : 3 waivers chromadb actifs, expires_at: "2027-02-28" (.github/security/dependency-waivers.yaml — corrige la date 2026-11-30 du cadrage, expirée depuis renouvelée) |
≥ 90 % bloqué, 0 CVE critique ouverte | Suite d'injections dédiée (à créer) + scripts d'audit dépendances existant (.github/workflows/dep-audit-cron.yml) |
5 |
| 9 | Adoption | 10 projets réels gouvernés, tous à Guilhem (mémoire projet, non vérifiable dans le code de ce dépôt) | 3 utilisateurs externes avec reçus dans le trimestre | Registre de flotte / retours structurés (hors code, déclaratif) | 6, transversal |
| 10 | Entreprise — reçu vérifiable par un tiers | grimoire receipt verify n'existe pas dans src/grimoire/cli/ (49 commandes recensées, aucune receipt) ; l'équivalent actuel est interne : grimoire standard verify/gate sur l'EvidencePack (src/grimoire/evidence/, framework/agentic-standard/templates/evidence-pack.md) |
receipt verify fonctionnel par un tiers, politiques et SLO documentés |
Commande grimoire receipt verify sur un pack exporté, hors du projet source |
4 |
Note de comptage (métrique 2) : grimoire --help liste 7 catégories (Info,
Project, Agents, Validation, Data, Utilities, Configuration) pour un total de
49 noms de commande de premier niveau, alias compris à part (i, d, s,
v, l, m, dbg, ck). Aucune liste séparée « premier pas » n'existe
aujourd'hui dans docs/getting-started.md — c'est l'écart que la cible ≤ 5
mesure.
Résultats du banc à trois bras (2026-09-17, graine 551)¶
Campagne réelle du 2026-09-16/17 (issue #551), 20 tâches (benchmark polyglot
Aider) × 3 bras × k = 3, 180/180 runs joués. Rapport complet : branche
bench-reports, commit
c43483ac.
Ces chiffres remplacent les « à mesurer (banc, phase 1) » des métriques 4, 5
et 4bis ci-dessus.
| Bras | Succès | pass^k (k=3) | Temps médian | Tours médians | Coût médian/tâche résolue | Coût moyen/tour |
|---|---|---|---|---|---|---|
| nu | 91,7 % | 90 % | 64 s | 6,0 | 0,399 $ | 0,0741 $ |
| ecc | 93,3 % | 90 % | 61 s | 7,0 | 0,629 $ | 0,0970 $ |
| kit | 90,0 % | 85 % | 189 s | 19,0 | 1,247 $ | 0,0675 $ |
Lecture (métrique 4/5, délégation optimale) : le coût moyen par tour du bras
kit n'est pas plus élevé que celui du bras nu — le surcoût (×3,17 tours,
×3,36 temps, ×3,19 coût, médianes appariées par tâche) n'est donc pas un
effet de contexte plus lourd par tour, c'est un effet de nombre de tours
(diagnostic docs/bench/diagnostic-surcout-kit-2026-09-17.md §1.1). Sur les
60/60 runs kit, dispatch_stats.overall.total == 0 : la cascade de dispatch
par vérifiabilité n'est jamais sollicitée sur le chemin claude -p — voir
« Décision hors-lot » en phase 2bis ci-dessous, cette mesure ne couvre que le
chemin hôte gouverné par hooks, pas un flow lancé par le kit.
Lecture (métrique 4bis, coût par tâche résolue) : kit à 1,247 $ contre 0,399 $ pour nu, soit 312 % du coût de nu (cible ≤ 50 %, loin d'être atteinte) — voir verdict §3.
3. Critères d'arrêt¶
- Après le banc à trois bras (phase 1) : si le kit est moins bon que l'hôte nu à la fois en réussite ET en coût, on arrête les extras et on retravaille la boucle de cœur (dispatch, contexte injecté, mémoire) avant toute parité. Si réussite égale et coût ≤ 70 %, on continue le plan.
Verdict du 2026-09-17 (campagne réelle, graine 551, 180/180 runs, rapport, issue #551) : ARRÊT. Le kit coûte ×3,1 le coût médian par tâche résolue de l'hôte nu (1,247 $ vs 0,399 $) et met ×3,0 plus de temps (189 s vs 64 s médian) ; la réussite est égale ou inférieure (90,0 % vs 91,7 %, IC95% chevauchants — pas de signal statistique isolé sur ce seul axe, mais qui ne compense pas le coût). Le critère de coût déclenche seul l'arrêt, sans ambiguïté statistique.
Décision : les extras du plan (reçu portable, rejeu, skills, parité
première heure — phases 3 et 4) sont gelés jusqu'à un rejeu du banc
(même harnais, même protocole) où le kit atteint réussite ≥ nu et
coût ≤ 70 % du nu. La plomberie déjà en vol qui ne dépend pas du verdict
(unification des systèmes de tâches, lot 4.1 / issue #559) continue, car
elle est hors du chemin d'exécution mesuré par le banc (claude -p).
Nouvelle phase 2bis « Cœur » (§4, issue #582) insérée avant toute reprise
des extras. Diagnostic détaillé des causes :
docs/bench/diagnostic-surcout-kit-2026-09-17.md.
- Le banc lui-même s'arrête sur clarté statistique, jamais sur un
plafond en dollars : intervalles de confiance disjoints entre les trois
bras, ou n suffisant atteint. Une alerte (pas un arrêt) se déclenche si le
coût dépasse trois fois le coût attendu de la campagne. Aucune boucle de
réveils, aucun plafond aveugle qui bloquerait la campagne (leçon retenue :
un plafond de ce type a déjà verrouillé une session entière — voir mémoire
projet, budget de session auto-blocage).
- Par lot : un lot est « fait » quand sa métrique a bougé sur le banc
hebdomadaire ; sinon pas de lot suivant sur le même thème sans relecture.
- Phase cloud (6, exécution distante) : ne démarre que si un utilisateur
entreprise ou équipe le demande. Fournisseurs cloud et backends managés
(Bedrock/Vertex/Azure/OVH) ne sont pas conditionnés à cette demande.
- Écartés du plan : SDK multi-langage, hébergement, edge, marketplace MCP,
cycle produit BMAD (voir §9 « Hors plan »).
4. Phases¶
Chaque lot = une release (cadence quotidienne à hebdomadaire, voir §8). Le
banc hebdomadaire (_grimoire-output/bench-reports) arbitre le passage au
lot suivant.
Phase 0 — Cadrage¶
Objectif : figer cible, promesse, métriques, critères d'arrêt avant tout dispatch. Fait : ce document et les deux entrées qui le sourcent.
Critère de fait : ce document publié, référencé depuis docs/index.md,
avec ses 6 issues de phase (#551-#556) et l'issue de suivi générale (#557).
Phase 1 — Veille en un bloc + banc à trois bras (issue #551)¶
Objectif : recibler la veille sur le segment « couches agentiques pour développeurs sur un hôte », arbitrer chevaucher/envelopper/ignorer face à Anthropic, prouver (ou infirmer) l'avantage coût/réussite du kit.
| Lot | Description | Métrique | Existe déjà (chemin) | Effort |
|---|---|---|---|---|
| 1.1 | Banc à trois bras (Claude Code nu / Claude Code + ecc / Claude Code + grimoire-kit, mêmes modèles, k = 3), jeu de tâches public et léger — recommandation : benchmark polyglot d'Aider, exercices Exercism multi-langages avec tests, sans Docker — 20 tâches, extensible ; arrêt sur clarté statistique (IC disjoints ou n suffisant), alerte à 3× le coût attendu, jamais un plafond bloquant | #4, #5, #4bis | dispatch stats, pass_k_rate (src/grimoire/traces/ledger.py), src/grimoire/missions/dispatch.py, src/grimoire/flows/pilot.py (paliers, plafond de coût par nœud) |
M |
| 1.2 | Verdict écrit et publié : chevaucher/envelopper/ignorer par capacité Anthropic (Agent Teams, plugins, skills, mémoire) | — (gouvernance) | framework/agentic-industry-reference.md §10 |
S |
| 1.3 | Inventaire des idées à récolter (§6) instruit : verdict adopter/adapter/écarter + licence par idée | — | veille-et-parite.md (source) |
S |
Critère de fait : verdict du critère d'arrêt écrit noir sur blanc (continuer / retravailler le cœur) avec les chiffres du banc à l'appui.
Phase 2 — Nettoyage et surcoût (issue #552)¶
Objectif : solder la dette connue, mesurer et plafonner le surcoût par tour avant d'ajouter des extras.
| Lot | Description | Métrique | Existe déjà (chemin) | Effort |
|---|---|---|---|---|
| 2.1 | Résoudre #519 (badge de version obsolète), #527 (profil mémoire full incomplet) ; #521 (Concevoir/Exécuter vides) est reclassé — son fond (deux systèmes de tâches parallèles) devient le préalable phase 4 lot 4.1, seule la messagerie d'état vide reste ici si elle n'est pas déjà couverte par ailleurs |
— (fiabilité) | src/grimoire/tools/project_health.py, src/grimoire/memory/ |
M |
| 2.2 | Résoudre #529 (test instable test_source_assist), #546 (route de compile absente du cockpit), #548 (fiche Piloter à 8 appels) |
3a | tests/unit/test_source_assist*.py, web/workspace/spaces/piloter.js |
M |
| 2.3 | Résoudre #550 (agents cités par le DNA absents du paquet minimal/agentic-standard) |
7 (densité) | archetypes/minimal/, archetypes/agentic-standard/ |
S |
| 2.4 | Alerte CodeQL py/command-line-injection sur cmd_cockpit.py, ouverte depuis 2026-06-30 : corriger ou documenter le waiver |
8 | src/grimoire/cli/cmd_cockpit.py |
M |
| 2.5 | Publier la mesure des tokens injectés par tour (métrique 3b) comme série suivie, pas un point isolé | 3b | grimoire-hook (ce document, mesure initiale) |
S |
| 2.6 | Profil léger : réduire la liste « à connaître » sans réduire les 49 commandes existantes — un chemin court documenté | 2 | docs/getting-started.md |
M |
Critère de fait : les 7 issues listées fermées, latence hook ≤ 60 ms toujours vraie, tokens/tour publiés en continu.
Phase 2bis — Cœur (issue #582)¶
Objectif : le verdict ARRÊT du banc à trois bras (§3, 2026-09-17) impose de
retravailler le cœur (dispatch, contexte injecté au démarrage, gates de
preuve) avant toute reprise des extras. Diagnostic complet et attribution du
surcoût : docs/bench/diagnostic-surcout-kit-2026-09-17.md. Signal principal
du diagnostic : le surcoût mesuré n'est pas un effet de contexte plus lourd
par tour (coût/tour kit 0,0675 $ ≤ coût/tour nu 0,0741 $), c'est un effet de
nombre de tours (×3,17 tours kit/nu) provoqué par un mandat de
gouvernance qui ne se dose jamais selon la taille de la tâche, combiné à des
gates déclaratives qui peuvent passer au vert sans qu'aucun test réel n'ait
tourné (garde qui échoue ouvert, §7).
| Lot | Description | Mécanisme et fichiers | Gain attendu | Effort | Mesure de preuve |
|---|---|---|---|---|---|
| A | Classer la tâche avant d'imposer le mandat de gouvernance : ne construire la directive complète (activation_context_text/_DIRECTIVE_TEMPLATE) que si _grimoire/standard/ existe ; classe V0 « exploration » reçoit une directive courte ou aucune |
src/grimoire/hosts/decisions/activation.py (decide_activation) |
Ramener le ratio tours kit/nu de ×3,17 à < 1,5× (diagnostic §3) | S | Rejeu three_arms.py --full (graine 551, mêmes 20 tâches), comparer aux médianes de ce rapport (19 tours/189 s/1,247 $) |
| B | Relier les gates à une exécution réelle : _verify_acceptance_record/check_evidence_gates s'appuient sur AcceptanceRun/AcceptanceEvidence(kind="test") déjà exécuté ailleurs (issue #428) — une ligne « passé » sans trace d'exécution est refusée ; WARN transitoire pour les packs existants |
src/grimoire/core/standard_checks/verifiers.py, controls.py, src/grimoire/flows/schemas.py, dispatch_executor.py |
pass^k kit (85 %) rejoint nu/ecc (90 %) sur go/palindrome-products et javascript/transpose (diagnostic §3) |
M | Test unitaire rouge-avant/vert-après (ligne « passé » sans exécution doit faire échouer verify) + pass^k kit ≥ nu/ecc sur rejeu |
| C | Persona d'entrée à la demande : pas de lecture intégrale mandatée de concierge.md (11 Ko) en session batch non interactive et déjà cadrée par TASK.md ; résumé d'une ligne à défaut |
src/grimoire/hosts/decisions/activation.py (entry_persona_context) |
Retire 1-2 tours et ~2 800 tokens forcés en tête de session (diagnostic §3) | S | Comptage des tours avant la première action liée à TASK.md, avant/après, sur un pilote |
| D | Harnais : garde-fou disque (< 5 Go libres) + cleanup_run_dir() (patch non poussé de la campagne, rapport §7) ; écrire RunOutcome.model_usage dans RunRecord ; extraire cache_read_input_tokens/cache_creation_input_tokens (jamais fait, diagnostic §0/§4) |
scripts/bench/three_arms.py |
Campagne suivante mesure directement tokens/tour et cache hits au lieu de les reconstituer | S/M | Rejeu pilote avec ces champs présents dans results.jsonl |
| E | Rejeu du banc (même graine 551, mêmes 20 tâches) après A-D — critère de fait de la phase | scripts/bench/three_arms.py |
Vérifie la cible de sortie | — | Rapport comparé terme à terme à celui du 2026-09-17 — fait le 2026-09-17, docs/bench/rejeu-lot-e-2026-09-17.md : tours kit/nu 3,17× → 1,0× (atteint), coût kit ≈ 104-112 % du nu (non atteint, mais 33 % de l'ancien coût kit), succès/pass^k kit inchangés à la lettre (90 %/85 %, IC très chevauchants avec nu/ecc). Constat qui rouvre la mesure : les 60 runs kit de ce rejeu n'ont jamais invoqué gate run-tests (0/60 test-run.json) — setup_arm_kit() ne provisionne jamais _grimoire/standard/, donc _is_governed() (lot A) classe le bras kit du banc comme non gouverné à chaque run et la directive du lot B ne part jamais ; go/palindrome-products et javascript/transpose (les deux tâches visées par le lot B) sont identiques bit à bit à l'ancien rapport. Lot F requis avant tout nouveau verdict sur le lot B. |
| F | Fermer la lacune de méthode révélée par le lot E : setup_arm_kit() doit provisionner un projet réellement enrôlé (grimoire standard init ou équivalent) pour que le bras kit puisse jamais passer par le chemin gouverné du lot B |
scripts/bench/three_arms.py (setup_arm_kit) |
Rend le lot B mesurable sur ce banc — condition préalable, pas encore une preuve d'effet | S | Fait le 2026-09-17, docs/bench/rejeu-lot-f-2026-09-17.md : nouveau bras kit-gov (PR #592), lot B désormais mesurable (68,3 % des runs avec test-run.json, contre 0 % pour kit) — mais résultat défavorable sur les quatre axes : tours ×4,75, coût ×4,60/tâche résolue, succès -6,7 points, pass^k -10 points par rapport à kit. Détail et lecture causale (un incident d'infrastructure explique l'essentiel de l'écart de réussite, pas l'écart de tours/coût) : voir rapport. |
| G1 (#597) | Gate auto-suffisant : artefacts scaffoldés, messages de gate avec chemin et remède, gate check --strict exécute lui-même gate run-tests — réponse directe à la spéléologie source mesurée par le lot F (médiane 8 tours/run, jusqu'à 20) |
src/grimoire/core/standard_checks/gate_remedy.py, standard_task_scaffold.py, gate_test_run.py |
Retirer la spéléologie source + l'orientation gouvernance qui lui est liée (≈16/31 tours médians du lot F) | M | Mergé 2026-09-17 ; effet non encore mesuré sur le banc (postérieur au rejeu du lot F) |
| G2 (#598/#599) | Les hooks alimentent le pack de preuve depuis les actions déjà observées (PostToolUse) plutôt que de les faire retaper par l'agent — réponse au coût de recopie mesuré par le lot F |
src/grimoire/core/standard_checks/evidence_journal.py, hosts/decisions/evidence_trace.py |
Retirer ≈3-4 tours/run (écriture evidence-pack.md, relecture des gabarits) |
M | Mergé 2026-09-17 (#599 = relecture de PR déplaçant le journal sous _grimoire-output/.runs/) ; effet non encore mesuré |
| G3 (en cours) | Conditionner le mandat gate run-tests à ce que resolve_need("test-runner") résolve effectivement une commande pour le projet — réponse à l'angle mort mesuré par le lot F sur go/palindrome-products/javascript/transpose (gate mandaté et exécuté alors qu'il ne peut structurellement rien vérifier) |
src/grimoire/core/execution_needs.py, standard_checks/acceptance_test_run.py |
Retirer ≈4 tours/run sur les tâches où le gate est inatteignable (15/21 runs Python du lot F) | S | Test unitaire rouge-avant/vert-après (mandat absent quand need.resolved est faux) |
| H (#603/#605) | Rejeu du bras kit-gov (même harnais, même graine 551, mêmes 20 tâches) après G1-G4 — critère de fait de la phase, cette fois sur le bras réellement gouverné |
scripts/bench/three_arms.py |
Vérifie si le ratio tours/coût kit-gov/nu descend sous les seuils du critère de sortie de phase | — | Fait le 2026-09-18, docs/bench/rejeu-lot-h-2026-09-18.md : tours médians 28,5 → 12,0 (÷2,4), coût médian/tâche résolue 1,915 $ → 0,769 $ (÷2,5), succès 83,3 % → 90,0 % (= kit, à égalité stricte). Amélioration nette mais critère de sortie de phase toujours non atteint (tours kit-gov/nu 2,0×, pas < 1,5× ; coût ≈193 % du nu, pas ≤ 70 %). Incident de méthode en cours de route : un PATH relatif a fait rejouer 27 runs (44 $) sur l'ancien gabarit de directive avant les lots G — garde-fou permanent ajouté (verify_grimoire_binary_matches_template, PR #605), campagne relancée proprement. |
| I (#608/#609) | Réponse directe à l'analyse Go/JS du lot H (_scratch/bench-h2/analyse-go-js-kit-gov.md) : partager la même toolchain entre la session de l'agent et la vérification finale du harnais (#608) ; distinguer « aucun test collecté » d'un rouge, ne plus ré-exécuter un test sur arbre inchangé quel que soit son verdict, taire deux avertissements non actionnables pour une tâche V0 en profil non gouverné (#609, I-1/I-2/I-3) |
scripts/bench/three_arms.py (run_environment), src/grimoire/core/standard_checks/{no_tests_collected.py,gate_test_run.py,claim_ledger_verify.py} |
Retirer la friction de toolchain (médiane 4 tours/run sur Go au lot H) et le seul check qui échouait jamais sur Go/JS (acceptance.test_run_failed sur suite non collectée) |
S/M | Mergé 2026-09-18 ; effet mesuré par le lot J ci-dessous |
| J | Rejeu du bras kit-gov (même harnais, même graine 551, mêmes 20 tâches) après le lot I — critère de fait de la phase, sur le bras gouverné avec toolchain partagée et gate dosé |
scripts/bench/three_arms.py |
Vérifie si le ratio tours/coût kit-gov/nu descend sous les seuils du critère de sortie de phase | — | Fait le 2026-09-18, docs/bench/rejeu-lot-j-2026-09-18.md : tours médians 12,0 → 6,0 (= nu, ratio 1,0×, pour la première fois sous 1,5×), coût médian/tâche résolue 0,769 $ → 0,445 $ (≈112 % du nu, contre ≈193 % au lot H), succès 90,0 % → 96,7 % (au-dessus de nu 91,7 % en valeur ponctuelle, non significatif), pass^k 85 % → 95 %. Deux critères sur trois de la sortie de phase désormais atteints (tours, succès en valeur ponctuelle) ; le coût reste au-dessus du seuil historique de 70 % du nu mais à portée d'une lecture de parité (≤ 110 % du nu, écart de 1,7 point, cf. rapport §7c). Incident de méthode traité en cours de route (30 runs à 0 $ perdus sur expiration OAuth, un défaut de garde non rejouable trouvé et contourné manuellement, corrigé pour l'avenir par la PR #610 — mode --auth api-key, mergée après cette campagne). |
| K (#642) | Reformuler le WARN acceptance.no_tests_collected (ne pas enjoindre d'écrire un test quand la suite est absente du dépôt de tâche) et corriger le repli --task-id bootstrap — réponse directe aux deux déclencheurs identifiés dans la veille modèles de décision (docs/veille/decision-models-2026-09.md) sur les 18 runs qui portent 103 % du surcoût du lot J |
src/grimoire/core/standard_checks/gate_test_run.py, src/grimoire/cli/cmd_standard.py |
18/60 excursions supprimées, 118 % → ≈ 99 % du nu sans retirer un seul mandat de gouvernance (mesuré rétroactivement sur les transcriptions du lot J) | S | Rejeu three_arms.py --full (graine 551, mêmes 20 tâches) — Fait le 2026-09-29, docs/bench/rejeu-lot-k-2026-09-29.md : aucun des quatre critères chiffrés de l'issue n'est atteint à la lettre. Excursions 30,0 % → 26,7 % (16/60, recul réel mais loin de la cible < 10 %), leur part dans le surcoût recule fortement (103 % → 37 %) mais le surcoût total augmente (+4,94 $ → +6,68 $) : les runs « mandat pur » eux-mêmes coûtent désormais plus cher (surcoût médian +0,039 $ → +0,098 $). Coût médian/tâche résolue ≈112 % → ≈122 % du nu, succès 96,7 % → 90,0 % (régression rust/scale-generator 3/3 → 0/3, cause non tranchée), gate check vert au dernier appel toujours 60/60 (seul critère acquis, inchangé depuis le lot J). Décision (rouvrir l'analyse causale ou classer le lot non concluant) soumise à Guilhem, pas de dégel proposé. |
| L (#642) | Rejouer nu ET kit-gov le même jour pour supprimer le biais de date du lot K |
scripts/bench/excursions.py (classifieur corrigé), aucune modification du code produit |
Critères de #642 : excursions < 10 % (en distinguant coûteuses et bénignes), coût ≤ 105 % du nu, succès ≥ 96,7 %, gate vert 60/60 | S | Rejeu three_arms.py --full --arms nu,kit-gov (graine 551, workspace neuf) — Fait le 2026-10-02, docs/bench/rejeu-lot-l-2026-10-02.md : trois critères sur quatre atteints, pas le coût. Coût médian/tâche résolue ≈124 % du nu (surcoût fixe ≈ +0,04 $ par run), excursions 16,7 % au sens binaire mais 8,3 % coûteuses (5/60), succès 100 % (nu 100 %, banc saturé, modèle passé de claude-opus-5[1m] à claude-opus-5-5 entre K et L), gate vert 60/60. Cause de la régression rust/scale-generator du lot K : contamination du lot J (30/60 dossiers kit-gov réutilisés avec les tests visibles), pas une régression du kit ; le 96,7 % du lot J est surévalué. Classifieur d'excursions corrigé (gate enchaîné après heredoc). Décision (coût fixe, définition des excursions, correctif du harnais, épinglage du modèle) soumise à Guilhem. |
Décision hors-lot — la cascade de dispatch dans claude -p : mesuré,
dispatch_stats.overall.total == 0 sur 60/60 runs kit — la cascade n'est
jamais sollicitée sur le chemin claude -p mesuré par ce banc. L'argument
« même résultat, un tiers du prix » ne s'applique qu'aux flows lancés par le
kit (grimoire flow run/grimoire dispatch), pas à une session d'hôte
gouvernée par hooks. Ne pas lancer de chantier de câblage avant d'avoir
mesuré l'effet des lots A/B/C. À prévoir en phase 2bis ou plus tard : un
bras « flow du kit » (tâche lancée par grimoire flow run avec dispatch
actif) pour mesurer la cascade réellement, en plus du chemin claude -p
déjà couvert.
Critère de fait de sortie de phase : sur le rejeu du banc (lot E), tours kit/nu < 1,5×, coût kit ≤ 70 % du nu, succès kit ≥ nu. Tant que ce critère n'est pas atteint, les phases 3 et 4 restent gelées (§3).
Résultat du rejeu (2026-09-17, docs/bench/rejeu-lot-e-2026-09-17.md) :
partiellement atteint. Tours kit/nu 1,0× — largement sous 1,5×, cible du lot
A confirmée sans réserve. Coût kit ≈ 104-112 % du nu — au-dessus, pas en
dessous, de 70 % du nu (mais réduit à 33 % de son propre niveau d'avant les
lots, ×1,25/tâche résolue → ×0,416). Succès kit 90,0 % contre nu 91,7 %
(pass^k 85 % contre 90 %/90 %), rigoureusement identiques run par run à la
campagne d'avant les lots — non significatif (IC95 % très chevauchants),
mais pas « ≥ nu » au sens strict. Décision : le critère n'étant pas
entièrement atteint, les extras (phases 3 et 4) restent gelés. Le lot B
n'a par ailleurs jamais été exercé par ce rejeu (0/60 runs avec
gate run-tests invoqué, cf. lot F ci-dessus) : son effet sur le pass^k
reste à mesurer, pas à supposer acquis ni à supposer nul.
Résultat du lot F (2026-09-17, docs/bench/rejeu-lot-f-2026-09-17.md) :
non atteint, plus nettement que sur le bras kit du lot E. Le nouveau
bras kit-gov (projet réellement enrôlé, profil starter, PR #592) ferme la
lacune de méthode du lot E — le lot B est désormais mesurable (68,3 % des
runs avec test-run.json, contre 0 % pour kit) — mais le résultat est
défavorable sur les quatre axes face à kit non gouverné : tours ×4,75
(6,0 → 28,5 médians), coût médian/tâche résolue ×4,60 (0,416 $ → 1,915 $),
temps médian ×4,58, succès -6,7 points (90,0 % → 83,3 %), pass^k -10 points
(85 % → 75 %). Face à nu : tours ≈4,75×, coût ≈480 % du nu, succès
83,3 % contre 91,7 %. Nuance établie par le rapport : une lecture
causale, appuyée sur les horodatages bruts, montre qu'un incident
d'infrastructure isolé (expiration de session OAuth dans les 16 dernières
secondes d'une campagne de 4h25) explique la quasi-totalité de l'écart de
réussite brut — sur les trois tâches directement comparables sans cet
incident, le taux de réussite kit-gov est identique, tâche par tâche, à
celui de kit. L'écart de tours et de coût, lui, n'a pas cette explication :
il est entier et mesuré sur des runs qui ont réellement tourné. Décision :
un mandat de gouvernance non dosé selon la taille de la tâche ne peut pas
produire de gain net sur des tâches courtes déjà bien réussies sans lui — les
extras (phases 3 et 4) restent gelés, le travail sur le cœur reste
prioritaire. Les lots G1 (#597) et G2 (#598/#599) sont mergés en réponse
directe à l'analyse tour par tour du lot F (spéléologie source et recopie
manuelle du pack de preuve, à eux deux ≈16-20 tours/run médians) ; G3 est en
cours (conditionner gate run-tests à resolve_need effectivement résolu).
Aucun des trois n'a encore été mesuré sur le banc — c'est l'objet du lot H.
Résultat du lot H (2026-09-18, docs/bench/rejeu-lot-h-2026-09-18.md) :
amélioration nette, critère de sortie de phase toujours non atteint.
Après G1-G4, le bras kit-gov passe de 28,5 à 12,0 tours médians
(÷2,4), de 1,915 $ à 0,769 $ de coût médian/tâche résolue (÷2,5), de
261 s à 120 s de temps médian (÷2,2) ; le succès remonte de 83,3 % à
90,0 %, désormais identique à kit tâche par tâche (au lieu de -6,7
points) — la nuance du lot F (incident OAuth expliquant l'essentiel de
l'écart de succès) est confirmée a posteriori : sans incident cette fois,
le succès rejoint exactement celui de kit. Mais le ratio tours kit-gov/nu
reste à 2,0× (cible < 1,5×) et le coût à ≈193 % du nu (cible
≤ 70 %) : le critère de sortie de phase n'est atteint sur aucun des trois
axes, malgré une réduction d'un facteur 2,4-2,5 du surcoût de
gouvernance. test-run.json (preuve du lot B) reste présent sur 75,0 % des
runs (68,3 % au lot F) malgré une directive divisée par plus de deux en
longueur (824 → 396 caractères, lot G3) — la couverture du lot B n'a pas
reculé. Décision : les phases 3 et 4 restent gelées. Piste la plus
probable pour la suite, nommée mais non exercée par aucun lot G/H : doser
le mandat de gouvernance selon la taille de la tâche plutôt que le mandat
fixe actuel (gate check --strict coûte le même tour quelle que soit la
tâche, ce qui pénalise disproportionnellement les tâches déjà résolues en
3-5 tours par nu). Incident de méthode traité en cours de route : un
PATH relatif a fait rejouer 27 runs (44 $, données invalidées et
exclues) sur l'ancien gabarit de directive (pré-lots-G) avant d'être
détecté et corrigé — garde-fou permanent ajouté au harnais
(verify_grimoire_binary_matches_template, PR #605) : toute campagne
future en bénéficie sans geste supplémentaire.
Résultat du lot I (2026-09-18, PR #608/#609) :
réponse directe à l'analyse Go/JS du lot H
(_scratch/bench-h2/analyse-go-js-kit-gov.md) — jamais un échec d'enveloppe,
de pack de preuve, d'acceptance-record ou de claim-ledger sur les 30 runs
Go/JS analysés, seul acceptance.test_run_failed échouait jamais. PR #608 :
la session de l'agent et la vérification finale du harnais partagent
désormais le même environnement de toolchain (run_environment() unique).
PR #609 (I-1/I-2/I-3) : « aucun test collecté » devient un avertissement
(acceptance.no_tests_collected) plutôt qu'un rouge bloquant ;
gate check --strict ne relance plus la commande de test sur une empreinte
d'arbre inchangée, quel que soit son verdict enregistré (--rerun pour
forcer) ; une tâche V0 en profil non gouverné tait deux avertissements non
actionnables. Effet mesuré par le lot J ci-dessous, pas par ce lot lui-même
(aucun rejeu n'accompagnait la PR).
Résultat du lot J (2026-09-18, docs/bench/rejeu-lot-j-2026-09-18.md) :
amélioration nette de plus, deux critères de sortie de phase sur trois
désormais atteints. Après le lot I, le bras kit-gov passe de 12,0 à
6,0 tours médians — identique à nu, ratio 1,0×, pour la première
fois sous le seuil de 1,5× de la phase. Coût médian/tâche résolue :
0,769 $ → 0,445 $, soit ≈112 % du nu (contre ≈193 % au lot H, ≈480 % au
lot F) — au-dessus du seuil historique de 70 % du nu, mais à 1,7 point
d'une lecture de parité (≤ 110 % du nu) que ce rapport documente sans
trancher (docs/bench/rejeu-lot-j-2026-09-18.md §7c). Succès : 90,0 % →
96,7 %, désormais au-dessus de nu (91,7 %) en valeur ponctuelle (IC95 %
chevauchants, non significatif) ; pass^k : 85 % → 95 %. Sur Go et Rust, la
friction de toolchain (médiane 4 tours/run au lot H) tombe à une médiane de
0 et les tours rejoignent exactement nu — effet direct et chiffré de
la PR #608. 100 % des runs (60/60) se terminent sur un gate check
vert, contre 68,3 % mesurés rétroactivement sur les mêmes transcriptions
du lot H — l'effet le plus direct de la PR #609. Décision proposée (pas
appliquée unilatéralement) : si Guilhem re-base le critère de coût sur la
lecture de parité (≤ 110 % du nu) plutôt que sur le seuil historique
(≤ 70 % du nu), et que ce seuil révisé est confirmé atteint (ou l'écart de
1,7 point jugé dans le bruit), alors dégel des phases 3 et 4 sous réserve
de cette re-base ; sinon, gel maintenu jusqu'à un nouveau rejeu ou un
dosage de gouvernance par taille de tâche (piste non encore exercée,
docs/bench/rejeu-lot-j-2026-09-18.md §8). Incident de méthode traité en
cours de route : expiration OAuth immédiate sur 30 runs (0 $ perdu, cause
nommée pour la première fois — copie des jetons OAuth de l'opérateur dans
chaque HOME isolé, invalidée par la rotation), puis un défaut de garde non
rejouable trouvé et contourné manuellement, corrigé pour l'avenir par la PR
#610 (mode
--auth api-key, mergée après cette campagne).
Phase 3 — Parité première heure (issue #553)¶
Gel levable sur décision de Guilhem, pas encore levé (phase 2bis, issue #582, lot J :
docs/bench/rejeu-lot-j-2026-09-18.md) : après le lot I, le braskit-govatteint tours kit-gov/nu = 1,0× (cible < 1,5×, atteinte pour la première fois) et succès 96,7 % contre nu 91,7 % (valeur ponctuelle au-dessus, IC95 % chevauchants, non significatif) — deux critères sur trois de la sortie de phase. Le coût reste à ≈112 % du nu, au-dessus du seuil historique (≤ 70 %) mais à 1,7 point d'une lecture de parité (≤ 110 % du nu) que le rapport du lot J documente sans trancher (une gouvernance ne peut structurellement pas coûter moins que la tâche nue tant qu'aucun routage vers des modèles moins chers n'est invoqué sousclaude -p— jamais mesuré actif sur ce banc). Ce document ne lève pas le gel : il propose à Guilhem de re-baser le critère de coût (§4 ci-dessus) ; la reprise de cette phase attend cette décision explicite, pas une nouvelle mesure automatique.
Objectif : combler les 5 premiers manques remarqués par la veille (émetteurs, hôtes, flow en tâche de fond, règles scopées, agents cassés).
| Lot | Description | Métrique | Existe déjà (chemin) | Effort |
|---|---|---|---|---|
| 3.1 | Émetteur riche Cursor (règles scopées .cursor/rules/*.mdc par dossier) |
7 | src/grimoire/hosts/emitters/generic.py (base à spécialiser), base.py |
L |
| 3.2 | Émetteur riche Codex | 7 | idem | L |
| 3.3 | Émetteur riche Gemini CLI | 7 | idem | L |
| 3.4 | Émetteurs opencode et Zed (mode dégradé → riche) | 7 | idem | M |
| 3.5 | flow run --background : retour immédiat + grimoire flow status sans bloquer le terminal |
1 (proxy) | src/grimoire/cli/cmd_flow.py, flow status déjà présent |
M |
| 3.6 | Format de plugin installable (grimoire plugin install <url>), première mouture |
7 (adoption) | builders internes (grimoire-skill-forge côté Forge), aucun équivalent kit |
L |
| 3.7 | Résoudre #550 si non fait en phase 2, vérifier absence de lien mort sur tous les archétypes | 7 | archetypes/*/agents/ |
S |
Critère de fait : host sync --host cursor (et Codex, Gemini) produit des
règles scopées par dossier, pas de la prose générique ; flow run
--background rend la main immédiatement.
Phase 4 — Extras (issue #554)¶
Gel levable sur décision de Guilhem, pas encore levé (phase 2bis, issue #582, lot J :
docs/bench/rejeu-lot-j-2026-09-18.md) : après le lot I, tours kit-gov/nu = 1,0× (cible < 1,5×, atteinte) et succès 96,7 % contre nu 91,7 % (valeur ponctuelle au-dessus, non significatif) — deux critères sur trois de la sortie de phase. Coût à ≈112 % du nu, au-dessus du seuil historique (≤ 70 %) mais à 1,7 point d'une lecture de parité (≤ 110 % du nu) que le rapport du lot J documente sans trancher. Ce document ne lève pas le gel : il propose à Guilhem de re-baser le critère de coût (§4 ci-dessus) ; la reprise de cette phase attend cette décision explicite. Si le critère révisé est confirmé atteint : dégel sous réserve de cette re-base. Sinon : gel maintenu jusqu'à un nouveau rejeu ou un dosage de gouvernance par taille de tâche (piste non encore exercée en profilgoverned,docs/bench/rejeu-lot-j-2026-09-18.md§8). Le lot 4.1 (préalable d'unification des tâches, issue #559) continue car hors du chemin d'exécution mesuré par le banc.
Objectif : deux axes déclarés (phase du projet, finition du livrable) propagés dans les tâches et le kanban après unification du système de tâches (préalable), un pilote qui choisit et change de stratégie de délégation en cours de route, une boucle de finition jugée contre les standards du projet, une politique de question groupée, puis le reçu portable vérifiable, le rejeu avec diff et une bibliothèque de skills gatée plus dense.
| Lot | Description | Métrique | Existe déjà (chemin) | Effort |
|---|---|---|---|---|
| 4.1 (issue #559) | Préalable bloquant : unifier les deux systèmes de tâches (Mission Ledger lu par Exécuter vs tâches du standard lues par hooks/gates, issue #521) — une tâche, une source, un board | — (préalable) | src/grimoire/missions/{board.py,ledger.py,task_flow_adapter.py} (import unidirectionnel déjà écrit, TaskFlowImportReport, jamais bidirectionnel) vs src/grimoire/core/standard_state.py (_grimoire/standard/task-board.yaml, STANDARD_DIR) |
L |
| 4.2 (issue #560) | Phase (exploration/construction/exploitation) et finition (maquette/peaufiné) déclarées : champ phase: dans project-context.yaml, question du wizard à l'init (proposition déduite du dépôt), grimoire phase set <x>, badge cockpit, hook de début de session, doctor qui signale une contradiction dépôt/phase par une proposition (jamais un changement automatique) |
6 (proxy) | project-context.tpl.yaml (schéma sans champ phase aujourd'hui), src/grimoire/cli/cmd_init.py (wizard sans question de phase), grimoire doctor (app.py, diagnostics lint/validate/structure existants, aucune contradiction phase/dépôt), src/grimoire/proposals.py (mécanisme de proposition sur seuil, réutilisable pour une proposition de changement de phase) |
M |
| 4.3 (issue #561) | Finition propagée aux tâches et au kanban : champ finition sur MissionTask (hérité de la phase, surchargeable), badge sur la carte ; une tâche peaufiné ne passe en « Terminé » que si passe de finition + juge sont verts, une tâche maquette sort par une colonne « Maquette livrée » ; changement de phase relit le board (propositions en lot) |
6 (proxy) | src/grimoire/missions/schemas.py (MissionTask.risk_profile, même patron à suivre pour finition), missions/board.py::build_board |
M |
| 4.4 (issue #562) | Pilote adaptatif : lit phase/finition/forme du travail, choisit palier de départ + forme d'équipe + gates + boucle de finition, change en cours de route sur les signaux tourne-en-rond / s'égare / besoin d'aide (voir « Délégation optimale » ci-dessous) | 4, 5 | src/grimoire/flows/pilot.py (PilotPolicy/decide(), palier de départ par classe V0/V1/V2, plafond de coût par nœud — le « combien » existe ; les signaux de changement en cours de route et le choix de forme d'équipe restent à écrire) |
L |
| 4.5 (issue #563) | Boucle de finition (peaufiné) : passe format / simplification / nommage / docs / tests manquants / conformité aux skills et standards, loop-until-dry sur un score de qualité, juge contre les standards du projet (pas son opinion) |
6 | loop-until-dry déjà générique (flows/genres.py, flows/dispatch_executor.py, flows/blueprint_loader.py, cli/cmd_blueprint.py) ; juge à câbler sur core/agentic_standard.py/grimoire_standard_score, pas un jugement de modèle non ancré |
M |
| 4.6 (issue #564) | Politique de question : par lot et au checkpoint, jamais ce qui se déduit du dépôt ou de la mémoire ; nombre et pertinence des questions dans le reçu | — | src/grimoire/missions/intake.py (classification déterministe sans LLM, base à étendre pour grouper les questions plutôt que les poser une à une) |
M |
| 4.7 | grimoire receipt verify : vérifie un pack de preuve exporté, hors du projet source, sans dépendance au registre local |
1, 10 | src/grimoire/evidence/, framework/agentic-standard/templates/evidence-pack.md, grimoire standard verify (base à exposer en export) |
L |
| 4.8 | Rejeu avec diff visible entre deux exécutions d'un même blueprint | — | flow extract (issue #210), blueprint evals --record |
M |
| 4.9 | Bibliothèque de skills gatée : packs par stack générés depuis le cadrage, format plugin, juge = taux de manques | 6, 7 | 20 skills / 10 archétypes existants (archetypes/*/skills/*.md), agent-miss (src/grimoire/proposals.py) réutilisable comme juge de manques |
L |
| 4.10 | Mettre en avant la cascade coût/pass^k/SLO dans le cockpit et la CLI (déjà mesurée, pas visible) | 4bis, 5 | dispatch.cost_slo, src/grimoire/cli/cmd_dispatch.py |
S |
Critère de fait : un tiers sans accès au projet source vérifie un reçu
avec grimoire receipt verify et obtient un verdict. Le lot 4.1 est un
préalable : les lots 4.2 à 4.6 s'appuient sur une seule source de tâches.
Phase et finition¶
Deux axes déclarés séparément (décision Guilhem, 2026-09-16), jamais confondus.
Phase du projet (cycle de vie) : exploration (on cherche, maquette
légitime), construction (c'est défini, on construit), exploitation (des
utilisateurs en dépendent — compatibilité, migrations, non-régression,
retour arrière). Chaque transition est une décision de l'utilisateur,
tracée ; le kit ne devine jamais.
Finition du livrable : maquette (jetable, rapide) ou peaufiné
(propre, optimisé, conforme aux concepts et standards du projet). Une tâche
peut surcharger la finition héritée par une question au début, jamais au
milieu.
| Phase | Finition par défaut | Note |
|---|---|---|
| exploration | maquette | peaufiné reste possible sur demande |
| construction | peaufiné | maquette non proposée par défaut |
| exploitation | peaufiné | maquette refusée sauf branche isolée ; passer en exploitation ne change pas la finition (déjà maximale), ça durcit les gates |
Cinq moments où l'utilisateur voit et choisit :
- Le wizard à l'init (
grimoire init) propose une phase déduite du dépôt (vide → exploration ; CI et releases présentes → exploitation) — confirmation, jamais un choix imposé. grimoire phase set <x>à tout moment.- Un badge du cockpit affichant phase et finition.
- Le dire au concierge, qui répercute la transition après confirmation.
- Le hook de début de session, première ligne : « Projet en
<phase>· livrable :<finition>» ; le reçu enregistre les deux.
Sans déclaration : une question à la première tâche, sinon défaut
construction. doctor signale une contradiction dépôt/phase par une
proposition (mécanique des propositions, proposals.py), jamais un
changement automatique. Lots porteurs : 4.2 (déclaration), 4.3 (propagation
tâches/kanban).
Délégation optimale¶
Le banc à trois bras compare qualité d'abord (gates, revue, finition), puis temps, puis coût — jamais le coût seul (§2, métriques 4, 5 et 4bis).
Signaux détectés par le pilote adaptatif (lot 4.4) et actions associées :
| Signal | Détection | Action |
|---|---|---|
| Tourne en rond | Même diff/commandes répétés, pas de progrès sur les gates — l'inverse de loop-until-dry, qui boucle jusqu'à la qualité ; ici on détecte l'absence de progrès |
Changer de stratégie ou d'agent avant d'escalader |
| S'égare | Fichiers hors périmètre, exclusive_files, sort de la frontière d'outils |
Rappel du périmètre puis checkpoint |
| Besoin d'aide | Gate rouge deux fois pour la même raison, échecs d'outils répétés, confiance basse | Escalade de palier, ou question à l'humain si jugement requis |
| Anormalement long | Écart à l'attendu pour ce type de tâche sur ce projet (historique du lot « palier par historique »), jamais un plafond en dollars | Signal seulement — un unique arrêt dur de dernier recours existe, loin derrière ces signaux (leçon : un plafond aveugle a déjà bloqué une session entière, voir mémoire projet) |
Formes d'équipe choisies selon la forme du travail :
- Liste homogène de tâches →
fanoutà palier bas + verify-panel. - Travail divers → routage concierge vers spécialistes.
- Tâche profonde → un agent fort + juge.
- Périmètre incertain → planifier puis exécuter, avec checkpoint.
Existe déjà : src/grimoire/flows/pilot.py (le « combien » — palier de
départ par classe, plafond de coût par nœud) ; src/grimoire/missions/dispatch.py::start_tier_for
(plancher par classe V0/V1/V2) ; flows/genres.py (genres de flow, dont
loop-until-dry). Manque : les signaux de changement en cours de route et
le choix de forme d'équipe — lot 4.4.
Phase 5 — Confiance (issue #555)¶
Objectif : chiffrer ce qui ne l'est pas encore — mémoire, sécurité, anti-empoisonnement — et combler les hooks manquants.
| Lot | Description | Métrique | Existe déjà (chemin) | Effort |
|---|---|---|---|---|
| 5.1 | memory bench --longmemeval : score publié, comparable à Mastra (~94,9 % cité par la veille) |
6 (proxy qualité mémoire) | aucun harnais trouvé (grep memory bench vide) ; backends existants src/grimoire/memory/ |
M |
| 5.2 | Suite d'injections mesurée (≥ 90 % bloqué) | 8 | aucune suite trouvée ; policies existantes src/grimoire/policies/security.py |
M |
| 5.3 | Validation externe des écritures mémoire (anti-empoisonnement) | 8 | aucun mécanisme trouvé | M |
| 5.4 | Hooks manquants : TaskCreated, TaskCompleted, InstructionsLoaded |
— | hooks existants dans src/grimoire/hosts/runtime.py (SessionStart, PreToolUse, Stop, PreCompact…) |
M |
| 5.5 | skills-ref validate + éval par skill — à créer dans le kit ; le gate grimoire-skill-analyzer cité par erreur en §6 comme mécanisme du kit n'existe que côté Forge (atelier de construction d'agents), il ne s'agit pas de le réutiliser |
7 | aucun outil trouvé sous ce nom dans src/grimoire/ (docs/veille/anthropic-direction-2026-09.md, synthèse point 4) |
M |
Critère de fait : un score LongMemEval et un taux de blocage d'injections publiés dans le même tableau de métriques que ce document, pas seulement annoncés.
Phase 6 — Cloud adaptatif (issue #556)¶
Objectif : fournisseurs cloud (Bedrock/Vertex/Azure/OVH), backends mémoire managés, puis exécution distante — conditionnée à une demande entreprise ou équipe (critère d'arrêt §3).
| Lot | Description | Métrique | Existe déjà (chemin) | Effort |
|---|---|---|---|---|
| 6.1 | Fournisseurs LLM via Bedrock/Vertex/Azure/OVH | 9 (adoption entreprise) | src/grimoire/providers/ (à confirmer lors du dispatch) |
L |
| 6.2 | Backends mémoire managés (au-delà des backends locaux/serveur déjà supportés) | 9 | src/grimoire/memory/backends/ |
L |
| 6.3 | Exécution distante (« où tourne le nœud ») — ne démarre que sur demande explicite | 9 | rien (confirmé, flow run --cloud absent) |
L |
Critère de fait : ne s'ouvre pas sans une demande entreprise/équipe nommée et datée.
Transversal¶
Objectif : README autour de la promesse, quickstart par hôte, dépôt de démo, distribution, retours d'expérience organisés, versionnement des formats.
| Lot | Description | Métrique | Existe déjà (chemin) | Effort |
|---|---|---|---|---|
| T.1 | README recentré sur la promesse (§1), pas une liste de fonctionnalités | 2 (première heure) | README.md, docs/index.md |
S |
| T.2 | Quickstart par hôte (Claude Code, Copilot, Cursor, Codex, Gemini) | 2, 7 | docs/getting-started.md, docs/hosts.md |
M |
| T.3 | Dépôt de démo, captures, distribution (plugin Claude Code, listes) | 9 | aucun dépôt de démo séparé trouvé | M |
| T.4 | Retours d'expérience organisés : 10 projets de Guilhem comme testeurs, télémétrie locale opt-in | 6, 9 | otel_conventions.py, exports OTel existants |
M |
| T.5 | Versionnement des formats (blueprints, propositions, reçus, mémoire portable) | — (dette évitée) | schémas JSON existants (grimoire schema) pour project-context uniquement, rien pour blueprints/propositions |
M |
Critère de fait : chaque affirmation de la feuille de route publique pointe vers le test ou le rapport qui la prouve (gouvernance, §8).
5. Matrice de parité¶
Reprise intégrale de la veille (31 points forts regroupés ; 7 atteints, 12 partielles, 12 absentes), colonne « phase du plan » ajoutée.
| Point fort | Meilleur chez | Parité = quoi dans le kit | Existe déjà | Manque | Effort | Test de parité | Statut | Phase |
|---|---|---|---|---|---|---|---|---|
| Bibliothèque skills/règles par stack | ECC (292) | densité comparable par stack/archétype | 20 skills / 10 archétypes | ~14× moins, pas de pack par langage | L | ≥ 100 skills gatés sur stacks majeures | ABSENTE | 4 |
| Densité d'agents spécialisés | ECC 68, SuperClaude 20, BMAD 19 | rôles fins par archétype sans lien mort | 3-4 agents/archétype (15 livrés) | minimal/agentic-standard citent project-navigator et memory-keeper absents (#550) |
M | ≥ 10 agents/archétype, 0 lien mort | PARTIELLE | 2 |
| Commandes prêtes à l'emploi | ECC 94, SuperClaude 30 | catalogue équivalent | standard (25+), flow, proposals, dispatch, host, upgrade-flow (49 commandes mesurées) | pas de slash commands IDE packagées hors host sync | S | ≥ 15 commandes / visibles après host sync |
PARTIELLE | 3 |
| Réplication multi-hôtes riche | ECC (12 hôtes) | hôtes avec expérience native | émetteurs riches claude_code, copilot ; generic (prose) pour les autres | 3+ hôtes en mode texte | L | host sync --host cursor produit des règles scopées |
PARTIELLE | 3 |
| Apprentissage continu / instincts | ECC | extraction auto avec confiance | proposals (agent-miss → agent/skill), fraîcheur | pas de score de confiance ni regroupement | M | skill auto-proposé après N occurrences | PARTIELLE | 4 |
| Cascades multi-agents par worktrees | ECC | parallélisation isolée | aucun | tout | M | task run --parallel crée N worktrees et fusionne |
ABSENTE | hors plan (voir §9) |
| Mémoire portable Markdown | ECC | export diffable par scope | 4 profils, backends riches | pas de couche Markdown portable | M | export .md par scope, diffable | PARTIELLE | 4 |
| Agent Teams (lead + équipiers) | Claude Code | coordination native indépendante de l'hôte | rien | mailbox, tâches partagées | L | 2 agents grimoire échangent sans l'hôte | ABSENTE | à instruire phase 1 (chevaucher/envelopper) |
| Plugins + marketplace | Claude Code | format installable par un tiers | builders internes, gate qualité | format plugin, marketplace | L | grimoire plugin install <url> |
ABSENTE | 3 |
| Sessions cloud + sandbox + reprise | OpenAI | exécution hébergée avec état | rien | tout | L | flow run --cloud |
ABSENTE (hors plan) | 6 (conditionnée) |
| Guardrails typés I/O | OpenAI | validation typée par appel | 336 gates (src/grimoire/missions/gates.py), EvidencePack |
guardrail déclaratif par appel LLM | M | output hors schéma rejeté | PARTIELLE | 5 |
| Tracing OTel | OpenAI, Microsoft | spans standard | otel_conventions.py (gen_ai.*), /api/otel |
— | — | export vers collector | ATTEINTE | — |
| Graphes d'agents explicites | ADK, LangGraph | orchestration typée | 8 genres + composition (src/grimoire/flows/genres.py) |
pas d'arête conditionnelle libre | M | blueprint avec arête custom | PARTIELLE | 4 |
| A2A natif | ADK | interop ouverte | MCP seul | tout | L | réponse à une requête A2A | ABSENTE | hors plan (voir §9) |
| SDK multi-langage | ADK, Microsoft | hors Python | Python seul | SDK TS/Go | L | — | ABSENTE (hors plan) | hors plan |
| Checkpoints/reprise à tout nœud, time travel | LangGraph | fork d'un run | flow resume, checkpoint, replay-diff, extract | pas de fork libre à un nœud | M | flow resume --at-node X |
PARTIELLE | 4 |
| Streaming d'événements | LangGraph | flux sans polling | /api/events |
SSE/WS non confirmé | S | événement reçu sans polling | PARTIELLE | 2 |
| Prototypage rapide par rôles | CrewAI | archétype opérationnel en minutes | wizard + 10 archétypes, grimoire init mesuré à 0,24 s |
— | — | init < 5 min | ATTEINTE | — |
| Compression mémoire mesurée | Mastra | score publié | rien | benchmark | M | memory bench --longmemeval |
ABSENTE | 5 |
| Évals intégrées reproductibles | Mastra, OpenAI | harnais fail-closed | blueprint evals --record |
pas d'éval mémoire | S | — | ATTEINTE (flows) / PARTIELLE (mémoire) | 5 |
| Edge / écosystème TS | Mastra/Vercel | hors Python | rien | tout | L | — | ABSENTE (hors plan) | hors plan |
| Human-in-the-loop | Microsoft | point d'arrêt dans un flow | genre checkpoint | — | — | — | ATTEINTE | — |
| Background agents | Cursor, opencode | flow non bloquant avec statut | indexation (codegraph) ; aucun mode async | flow run --background |
M | retour immédiat + flow status |
PARTIELLE | 3 |
| Règles scopées par dossier | Cursor | instructions par chemin | un fichier instructions par hôte | émission de règles applyTo multiples |
M | host sync génère plusieurs fichiers scopés | ABSENTE | 3 |
| Marketplace MCP + rollback fichier | Cline/Roo | catalogue + retour arrière | 20 tools MCP | marketplace, checkpoint fichier | M | — | ABSENTE (hors plan) | hors plan |
| Cycle produit PM→QA | BMAD | personas packagées | archétypes techniques | agents PM/QA/archi | M | archétype product-cycle | ABSENTE (hors plan) | hors plan, réviser si demande équipe/entreprise |
| Onboarding en un point d'entrée | SuperClaude, awesome | un appel configure tout | grimoire init wizard |
— | — | — | ATTEINTE | — |
| Sandbox microVM / computer use | industrie | isolation réelle | gate déclarative isolation_mode |
isolation effective | L | agent confiné | ABSENTE | 5 |
| Coût/tâche, pass^k, SLO | industrie (HAL) | mesure par tâche | pass_k_rate, dispatch.cost_slo, cascade |
— | — | — | ATTEINTE (en avance) | — |
6. Idées à récolter¶
Verdict provisoire, à confirmer en phase 1 (lot 1.3). Licences MIT pour la plupart des sources citées — attribution obligatoire dans tout code ou prompt repris.
| Idée | Source | Verdict provisoire | Licence | Note |
|---|---|---|---|---|
| Packs de règles par langage | ecc (MIT) | adapter | MIT, attribution | La densité (292 skills) ne se copie pas telle quelle. Correction 2026-09-17 : le kit ne gate pas encore par grimoire-skill-analyzer — cet outil n'existe que côté Forge (atelier), pas dans src/grimoire/ distribué avec le kit (docs/veille/anthropic-direction-2026-09.md, synthèse point 4). Le kit doit créer son propre gate (skills-ref validate + éval par skill, lot 5.5) avant toute densification ; pas de reprise brute de contenu tiers dans tous les cas. |
| Mémoire Markdown portable | ecc (MIT) | adopter | MIT, attribution | Couche d'export diffable manquante (matrice §5) ; format propre au kit, pas d'import direct du format ecc. |
| Scoring de confiance de l'apprentissage continu | ecc (MIT) | adapter | MIT, attribution | Le kit a déjà agent-miss → propositions ; ajouter un score, pas un mécanisme parallèle. |
| Règles scopées par dossier | Cursor | adopter | doc propriétaire, pas de code repris | Format .cursor/rules/*.mdc est documenté publiquement ; l'émetteur Cursor (phase 3) le génère depuis les instructions existantes. |
| Checkpoints de fichiers | Cline (Apache-2.0) | écarter | Apache-2.0 | Hors plan : le kit n'a pas de boucle d'édition de fichiers à checkpointer indépendante de l'hôte ; ce que fait chaque hôte nativement (Claude Code, Cursor) suffit. |
| Time travel (fork d'un run) | LangGraph (MIT) | adapter | MIT, attribution | Le kit a déjà flow resume/extract ; ajouter --at-node (phase 4), pas réécrire un moteur de graphe. |
| Éval mémoire (LongMemEval) | Mastra (Elastic-2.0) | adopter | Elastic-2.0 — vérifier compatibilité de redistribution avant d'embarquer du code, le protocole d'éval (benchmark public) est réutilisable sans ambiguïté | Phase 5, lot 5.1. |
| Personas de cycle produit (PM/QA/archi) | BMAD-method (MIT) | écarter pour l'instant | MIT, attribution | Hors plan explicite (§3, §9) ; à revoir uniquement si un utilisateur équipe ou entreprise le demande nommément. |
| Modèles de décision typés (Jev, clones /v1/systemone) | TypeSafe AI (propriétaire) ; Von, Laya, Kev, Nimble, Ollaya (Apache-2.0), SemIf, NanoJev (MIT) | écarter pour l'instant | mixte, voir note | Verdict mesuré : docs/veille/decision-models-2026-09.md. Récolte sans modèle : #642 (lot K, phase 2bis), #643, #644, #645 (phase 5). |
7. Registre des risques¶
| Risque | Parade |
|---|---|
| Absorption par Anthropic (teams, skills, mémoire, plugins) | Chevaucher/envelopper, jamais refaire à l'identique ; l'identité du kit reste preuve + coût + portabilité, pas la même surface qu'un hôte. |
| Mainteneur unique | Lots courts, releases fréquentes, tout poussé sur branches distantes (leçon du crash poste 2026-09-16). |
| Coût des bancs | Arrêt sur clarté statistique (IC disjoints ou n suffisant), jamais un plafond bloquant ; alerte simple au-delà de 3× le coût attendu ; tâches courtes, k = 3. |
| CVE des dépendances | chromadb : 3 waivers actifs, expires_at: "2027-02-28" (.github/security/dependency-waivers.yaml, DEPAUDIT-2026-002/003/004) — corrige la date 2026-11-30 précédemment retenue, déjà renouvelée depuis ; parade : audit planifié avant expiration, .github/workflows/dep-audit-cron.yml existant. |
| Dérive de surface | Profil léger, métrique « commandes à connaître » (§2, actuellement 49), suppression avant ajout. |
| La gouvernance coûte plus qu'elle ne rapporte tant qu'elle n'est pas conditionnelle | Mesuré par le banc à trois bras du 2026-09-17 : mandat de gouvernance identique quelle que soit la taille de la tâche, ×3,1 de coût pour une réussite égale ou inférieure. Parade : phase 2bis (classification de tâche avant mandat, lot A) — confirmée par le rejeu du lot E (docs/bench/rejeu-lot-e-2026-09-17.md) : ratio de tours kit/nu ×3,17 → ×1,0 sur le bras kit non gouverné. Mesurée directement sur un projet réellement enrôlé par le lot F (docs/bench/rejeu-lot-f-2026-09-17.md, bras kit-gov) : ×4,75 sur les tours, ×4,60 sur le coût médian par tâche résolue, pour -6,7 points de succès et -10 points de pass^k face à kit — le risque n'est pas théorique, il est mesuré sur le chemin gouverné réel, en amont des lots G. Parade : lots G1 (#597)/G2 (#598-#599)/G3 (#602)/G4 (#604) mergés, effet mesuré par le lot H (docs/bench/rejeu-lot-h-2026-09-18.md) : ×2,0 sur les tours (contre ×4,75 au lot F), ×1,93 sur le coût médian par tâche résolue (contre ×4,60), pour un succès désormais identique à kit (90,0 % contre 83,3 %) — surcoût réduit d'un facteur 2,4-2,5 mais toujours au-dessus des seuils de sortie de phase (< 1,5× tours, ≤ 70 % coût). Le ratio restant défavorable après G1-G4, la piste retenue pour la suite est le dosage de la gouvernance par classe de tâche (piste du lot A, jamais instruite faute de tâches longues/à risque dans le banc). Effet du lot I mesuré par le lot J (docs/bench/rejeu-lot-j-2026-09-18.md) : tours kit-gov/nu à ×1,0 (identique à nu, sous le seuil de 1,5× pour la première fois), coût médian/tâche résolue à ≈112 % du nu (contre ≈193 % au lot H, ≈480 % au lot F), succès 96,7 % au-dessus de nu (91,7 %) en valeur ponctuelle. Deux critères sur trois de la sortie de phase désormais atteints ; le coût reste au-dessus du seuil historique (≤ 70 %) mais à 1,7 point d'une lecture de parité (≤ 110 % du nu) proposée à Guilhem sans trancher — voir décision §4. Extras toujours gelés en l'absence de cette décision (§4). |
| Preuve déclarative = garde qui échoue ouvert | Diagnostic 2026-09-17 : grimoire standard gate check --strict et verify peuvent passer au vert sans qu'aucun test réel n'ait tourné (_verify_acceptance_record parse une cellule Markdown, jamais une exécution) — patron déjà documenté en mémoire projet (gardes fail-open). Parade : phase 2bis lot B (gates reliées à AcceptanceRun/AcceptanceEvidence(kind="test"), issue #428) — mergé ; mesuré par le lot F (docs/bench/rejeu-lot-f-2026-09-17.md) sur le bras kit-gov réellement enrôlé : 68,3 % des runs produisent désormais test-run.json (contre 0 % pour kit), mais aucun gain de pass^k sur les deux tâches visées (go/palindrome-products, javascript/transpose) — le gate s'exécute et échoue pour une raison d'environnement (binaire de test absent), pas parce qu'il détecte un défaut que l'absence de gate aurait laissé passer. Risque partiellement clos côté mesurabilité, ouvert côté bénéfice démontré ; angle mort traité par le lot G3 (ne pas mandater le gate quand resolve_need ne peut structurellement rien résoudre) — confirmé par le lot H : la couverture test-run.json tient à 75,0 % (contre 68,3 % au lot F) malgré une directive divisée par plus de deux (824 → 396 caractères), mais reste à 0 % sur les 15 tâches Python de l'échantillon (stubs Exercism sans aucun marqueur test-runner connu, historique ou de repli). Lot I (#609) : le seul check qui échouait jamais sur les runs Go/JS de H était acceptance.test_run_failed sur une suite non collectée (jamais un défaut d'enveloppe/pack/acceptance-record/claim-ledger) — désormais un avertissement (acceptance.no_tests_collected), pas un rouge bloquant. Mesuré par le lot J (docs/bench/rejeu-lot-j-2026-09-18.md §2) : la part de runs se terminant sur un gate check vert passe de 68,3 % (lot H, mesuré rétroactivement sur les mêmes transcriptions) à 100 % (60/60) — le risque de garde qui échoue ouvert par excès de rigueur environnementale est refermé sur ce banc ; la couverture test-run.json (lot B) reste stable à 75,0 %, toujours 0 % sur Python (inchangé, structurel au format de tâche). |
8. Gouvernance et cadence¶
- Un lot = une release (cadence actuelle : quotidienne à hebdomadaire).
- Banc hebdomadaire (
_grimoire-output/bench-reports) = arbitre ; revue hebdomadaire du plan sur ses chiffres. - Veille trimestrielle (référence agentique,
framework/agentic-industry-reference.md) reciblée sur le segment « couches agentiques pour développeurs sur un hôte ». - Feuille de route publique : pour chaque affirmation, lien vers le test ou le rapport qui la prouve — ce document applique déjà la règle à ses propres métriques (§2).
9. Hors plan¶
| Écarté | Raison |
|---|---|
| SDK multi-langage (TS/Go) | Hors cible (développeur seul / entreprise / équipe sur un hôte existant), coût de maintenance disproportionné pour un mainteneur unique. |
| Hébergement / edge | Le kit n'héberge rien ; portabilité entre hôtes existants, pas un nouveau runtime edge. |
| Marketplace MCP | Le kit consomme MCP (2026-07-28, src/grimoire/mcp/server.py), il n'a pas vocation à être un catalogue de serveurs tiers. |
| Cycle produit BMAD (PM/QA/archi) | Hors cible développeur/entreprise/équipe technique ; à revoir uniquement sur demande nommée d'un utilisateur équipe ou entreprise. |
| Cascades multi-agents par worktrees (ecc) | Parallélisation par worktree n'est pas un besoin exprimé par la cible ; à instruire si le banc montre un goulot de dispatch séquentiel. |
| A2A natif | Interop ouverte entre agents hétérogènes ; aucun signal de demande dans la cible actuelle, coût L. |
| Exécution distante (phase 6.3) | Ne démarre que sur demande explicite d'un utilisateur entreprise ou équipe (critère d'arrêt §3). |