Claude Code DTP Worker
25541c365d
INV10 ne garantissait que « roadmap_line est un entier positif ». Ajout de parse_roadmap_anchors (deps) qui DÉRIVE la structure réelle de la roadmap, et d'INV11 qui exige que chaque roadmap_line pointe RÉELLEMENT son bullet (DELIVERABLE du sprint SX · k-ième bullet métrique) et que le « 8 + 7 » soit dérivé du fichier, pas figé. Morsure prouvée sur le spec réel (S1=999, M3=200). Régénéré consommateurs : regression 558→564 (run/plan/MANIFEST), quality_report (acceptance 31→37 méthodes, 100/100 inchangé), fiches QA + Backend, README acceptance (10→11 invariants). 7 gates verts. 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.