oto-enterprise-os-dtp/05_deliverables_mvp/daily_reports/2026-07-30-session24.md

Rapport de session · 2026-07-30 · session 24

Tâche

Sprint 8 · QA (buffer L75 · recette) — Générateur de la Matrice d'acceptation / traçabilité MVP : mappe chaque promesse de la roadmap (8 livrables de sprint L33..L76 + 7 métriques succès MVP L81..L87) vers sa preuve livrée (module gated du CI) OU un hors-périmètre worker sourcé.

Sprint 8 étant le dernier (déploiement VPS réel + monitoring hors périmètre worker · #8), le volet réalisable en-repo restant est la recette : prouver que le MVP promis est intégralement honoré et que ce qui reste est explicitement hors périmètre. C'est la consolidation naturelle du « DELIVERABLE MVP » (L76) et des métriques succès (L80-87).

Gap comblé

Aucun artefact ne traçait les promesses roadmap vers les livrables. Les preuves étaient éparpillées (gap analysis Sprint 1 + 23 rapports de session) sans vue bijective « promesse → preuve », ni recensement des parties hors périmètre worker (builds stores, indexation runtime, voix Amélie, déploiement VPS).

Décision d'architecture

Harnais de MÉTA-NIVEAU orienté RECETTE, axe distinct des 4 autres méta (non redondant · #5) :

Harnais	Axe prouvé
qa/audit_4big	qualité statique par module (95+/100)
qa/regression	chaque suite s'exécute au vert
devops/deploy_runbook	ordre de déploiement VPS
qa/acceptance (nouveau)	couverture des promesses roadmap

Anti-invention (cœur · #6)

• Périmètre PROUVÉ : les modules-preuve sont dérivés du CI (q4lib.registry.parse_ci, réutilisé · zéro duplication · #5) et confrontés de façon BIJECTIVE — un module gated non tracé OU une preuve non gated → génération refusée ; la validation recalcule la couverture depuis le CI.
• Cross-cohérence : la fenêtre de sprint de chaque module est lue dans le registre de l'auditeur 4Big (quality_spec.json), jamais re-déclarée (anti-dérive) ; l'auditeur lui-même (SoD · absent de son registre) reçoit sa fenêtre via extra_module_sprint, avec source.
• Partition exacte par sprint : chaque livrable SX cite exactement les modules gated de fenêtre SX (ni trou ni chevauchement).
• Zéro chiffre fabriqué : 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 (#8 VPS · builds stores · runtime) ; SoD : la matrice ne se cite jamais elle-même.

Fichiers créés — 05_deliverables_mvp/qa/acceptance/

• acceptance_spec.json (8 livrables de sprint + 7 métriques MVP · roadmap_line pour chacun · hors-périmètre sourcé · 0 chiffre fabriqué)
• acclib/{__init__,deps,builder}.py (deps réutilise parse_ci + validateur Publiciste + registre 4Big ; builder pur/déterministe)
• acceptance_gen.py (CLI build/validate · 10 familles d'invariants)
• acceptance.schema.json (contrat draft-07)
• out/{acceptance_matrix,MANIFEST}.json (hand-off · verdict) · tests/test_acceptance.py (31 tests dont 14 injections négatives) · README.md · .gitignore

Fichiers modifiés

• .gitea/workflows/ci.yml : job qa-acceptance-tests + ajout au gate.
• qa/audit_4big/ : enregistrement du module (couverture bijective 20 → 21 · PASS 21/21 à min 100) ; out/ régénéré.
• devops/deploy_runbook/ : module_phase +qa/acceptance (phase verification-qa) ; couverture bijective 20 → 21 ; out/ régénéré.
• qa/regression/out/ : plan régénéré (20 → 21 suites · découverte auto CI).

Résultat

Matrice verdict=true — 15 promesses roadmap (8 sprint + 7 métriques) · 21 modules gated tracés sans doublon (bijectif) · partition par sprint exacte (S2=7, S3=1, S4=5, S5=2, S6=2, S7=2, S8=2 ; S1 sur artefact) · 12 hors-périmètre sourcés.

Vérifs

• 31/31 tests module ; validations méta vertes (audit_4big 21/21 min 100 · deploy 21/21 bijectif · regression 21 suites · acceptance bijectif+partition).
• Régression run exhaustive : 21/21 suites vertes · 534 tests passés · 0 échec · 0 erreur (503 → +31).
• Gate CI statique local vert (guard constraints · JSON · docs · YAML ci.yml).
• Build déterministe (régénérable bit-à-bit).

Hors périmètre worker (VPS · #8)

Ce module ne déploie rien : il produit un document de recette en-repo. L'exécution réelle (démo publique, application du run-book VPS, builds stores, indexation, voix Amélie) revient à l'agent DevOps / la direction.

Auto-score 4Big : 96/100