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>
80 lines
4.0 KiB
Markdown
80 lines
4.0 KiB
Markdown
# 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 via `extra_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 #8` VPS, builds stores,
|
|
services runtime) : aucune omission silencieuse.
|
|
|
|
## Usage
|
|
|
|
```bash
|
|
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)
|
|
|
|
1. ids uniques ; livrables S1..S8 + métriques M1..M7 ordonnés.
|
|
2. toute preuve module est **gated** (drapeau recalculé depuis le CI).
|
|
3. **couverture bijective** cités ⇔ gated (hors self) — cœur anti-invention.
|
|
4. fenêtre de sprint connue pour tout module gated ; extra sans conflit registre.
|
|
5. **partition exacte** par sprint.
|
|
6. tout hors-périmètre porte une source non vide.
|
|
7. cohérence statut/preuve ; tout artefact cité **existe** sur disque.
|
|
8. `mvp_metric` ⇒ sprint nul ; `sprint_deliverable` ⇒ sprint renseigné.
|
|
9. **SoD** : la matrice ne se cite jamais elle-même comme preuve.
|
|
10. `roadmap_line` entier positif.
|
|
11. **ancrage roadmap** : chaque `roadmap_line` pointe RÉELLEMENT son bullet dans
|
|
`04_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.
|