# 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 + 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.