Claude Code DTP Worker
caa3b90556
Défaut (1re vraie édition de prod après plusieurs sessions de sondes « 0 édition ») :
quality_spec.json:66 attribuait au générateur de faisabilité 4 volets la fenêtre roadmap
« S2 » avec un source falsifiable-faux (« roadmap Sprint 2 · Faisabilité… »), alors que la
roadmap n'a AUCUNE faisabilité au Sprint 2 (Console/CRM/RBAC) et place « génération 4 volets »
au Sprint 3 (L43, livrable L46 « P07 faisabilité complète auto-générée »). Cause racine :
confusion de 2 cadres de sprint — le label agent-interne « S2 » (AGENT.md §130-133 : phases
S1 template/S2 générateur/S3 versioning, toutes ancrées roadmap Sprint 3) recopié dans le
champ roadmap-global (seul quality_spec le porte, toutes ses entrées sourcent « roadmap
Sprint N »). Effet : le livrable-phare S3 était prouvé SANS son propre générateur, ce dernier
mal-classé comme preuve du S2 (dashboards/CRM/RBAC) sans rapport.
Correctif coordonné 2-spec + régénération byte-gatée :
- quality_spec.json:66 : sprint S2→S3 + source recitée « roadmap Sprint 3 » (style aligné sur
le jumeau bancable, déjà S3).
- acceptance_spec.json : generator retiré de evidence_modules S2, ajouté à S3
(sinon invariant 5 « partition exacte » casse : want lu dans quality_spec ≠ have déclaré).
- régénération audit_4big PUIS acceptance (lit la fenêtre depuis quality_spec).
Vérif : partition_ok=True · bijective=True · S2=6 (publiciste+5 rbac) · S3={bancable,generator}
· run_ci 33 PASS · score 4Big générateur inchangé 100/100 (le champ sprint ne sert qu'au tri+méta,
pas d'oracle de scoring). Portée honnête : 5 fichiers (2 specs + 3 artefacts régénérés) + log.
0 doc de module éditée (les ~10 « S2 » ailleurs = cadre agent-interne, corrects, #5) · daily_reports
= historique non réécrit · 0 gate ajouté (déjà gaté par inv5) · 0 chiffre inventé (#6) · 0 VPS (#8).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Matrice d'acceptation / traçabilité MVP — qa/acceptance
Sprint 8 · QA (buffer L75 · corrections finales / recette). Document de
RECETTE de méta-niveau : il mappe chaque promesse de la roadmap
(04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md) vers sa preuve livrée, et prouve
qu'aucune promesse n'est silencieusement oubliée.
- 8 livrables de sprint (L33..L76) → modules gated qui les réalisent en-repo.
- 7 métriques succès MVP (L81..L87) → preuve gated ou hors-périmètre sourcé.
Question de recette à laquelle il répond
« Le MVP promis est-il honoré, et ce qui reste est-il explicitement hors périmètre worker (VPS #8 · builds stores · services runtime) ? »
Pourquoi un module distinct (non redondant · #5)
| Harnais méta | Axe prouvé |
|---|---|
qa/audit_4big |
qualité statique de chaque module (95+/100) |
qa/regression |
chaque suite s'exécute au vert |
devops/deploy_runbook |
ordre de déploiement VPS des modules |
qa/acceptance (ici) |
couverture des promesses roadmap (la recette) |
Périmètre PROUVÉ, pas déclaré (anti-invention · #6)
- L'ensemble des modules-preuve est dérivé du CI (
q4lib.registry.parse_ci, réutilisé · zéro duplication) et confronté de façon BIJECTIVE à la réalité : un module gated non tracé OU une preuve non gated → génération refusée. - La fenêtre de sprint de chaque module est lue dans le registre de
l'auditeur 4Big (
qa/audit_4big/quality_spec.json) — jamais re-déclarée ici (anti-dérive). L'auditeur lui-même (absent de son propre registre · SoD) reçoit sa fenêtre viaextra_module_sprint, avec source. - Partition exacte par sprint : chaque livrable de sprint SX cite exactement les modules gated de fenêtre SX (ni trou ni chevauchement).
- Les nombres des énoncés (
<1h,95/100,7 dashboards,2 stores) sont des citations verbatim de la roadmap — la matrice ne prétend aucune mesure de performance. - Tout hors-périmètre porte une source (
CLAUDE.md #8VPS, builds stores, services runtime) : aucune omission silencieuse.
Usage
python3 acceptance_gen.py build # écrit out/acceptance_matrix.json + out/MANIFEST.json
python3 acceptance_gen.py validate # (re)génère en mémoire + valide (schéma + 11 invariants)
python3 -m unittest discover -s tests -p 'test_*.py' -v
Sorties (out/)
acceptance_matrix.json— une ligne par promesse : preuves modules résolues (avec job CI), artefacts, hors-périmètre sourcé, drapeaux + verdict global.MANIFEST.json— comptes, preuve de couverture bijective vs CI, partition par sprint.
Sortie déterministe (ordre du spec, listes triées, aucun horodatage).
Invariants (11 familles)
- ids uniques ; livrables S1..S8 + métriques M1..M7 ordonnés.
- toute preuve module est gated (drapeau recalculé depuis le CI).
- couverture bijective cités ⇔ gated (hors self) — cœur anti-invention.
- fenêtre de sprint connue pour tout module gated ; extra sans conflit registre.
- partition exacte par sprint.
- tout hors-périmètre porte une source non vide.
- cohérence statut/preuve ; tout artefact cité existe sur disque.
mvp_metric⇒ sprint nul ;sprint_deliverable⇒ sprint renseigné.- SoD : la matrice ne se cite jamais elle-même comme preuve.
roadmap_lineentier positif.- ancrage roadmap : chaque
roadmap_linepointe RÉELLEMENT son bullet dans04_roadmap/…(n° DELIVERABLE du sprint SX · k-ième bullet métrique), et le compte « 8 + 7 » est dérivé du fichier roadmap, pas figé — une promesse ajoutée/retirée ou des lignes décalées rougissent au lieu de dériver en silence.
Hors périmètre worker (#8)
Ce module ne déploie rien : il produit un document de recette en-repo. L'application réelle (démo publique, VPS) reste à l'agent DevOps / la direction.