oto-enterprise-os-dtp/05_deliverables_mvp/qa/acceptance

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

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 + 10 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 (10 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.

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.