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

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

Tâche

Sprint 8 · QA — Générateur de la Matrice de régression exhaustive (roadmap Sprint 8 · QA « Regression tests exhaustifs »).

Sprint 7 réalisable en repo est clos (L69 audit 4Big + L68 scénarios démo livrés sessions 20–21 ; L67 polish otov7.com dépend du site live · hors périmètre worker · #8). On enchaîne donc sur le premier volet Sprint 8 réalisable en repo.

Décision d'architecture

Harnais de MÉTA-NIVEAU + gate, pas un simple runner. Il agrège l'exécution de toutes les suites de tests gated du mandat en une matrice + un verdict PASS/FAIL et fournit le compte agrégé faisant autorité (« N tests verts ») — celui que les rapports quotidiens citaient jusqu'ici à la main.

Distinct de l'audit 4Big (non redondant · #5) : l'audit note la qualité statique par module (doc / schéma / CLI / hand-off) ; ce harnais prouve que chaque suite s'exécute au vert et calcule le total. Deux axes complémentaires.

Deux artefacts, deux natures :

• build → plan déterministe (out/regression_plan.json, commité) : recensement exhaustif des suites (chemin, jobs, gate, fichiers/méthodes test_*). Aucun compteur de résultat → diffable, re-générable.
• run → matrice live : exécute réellement chaque suite (subprocess unittest, comme le CI), agrège les compteurs + verdict. Non déterministe (temps machine) → non commitée (.gitignore).

Zéro invention · zéro duplication (#5 · #6)

• Périmètre dérivé du CI : les suites proviennent de .gitea/workflows/ci.yml via q4lib/registry.parse_ci (réutilisé de l'audit 4Big — une seule source de vérité). Tout job de test ajouté au CI entre automatiquement dans la matrice.
• Anti-invention : le plan ne contient aucun compteur de résultat ; les comptes de disque sont recomputés à la validation (INV5) → un compte figé / fabriqué est détecté. Le nombre de tests verts n'existe qu'à l'exécution.
• Séparation des pouvoirs (ISA 315) : le harnais s'exclut lui-même — pas d'auto-exécution (évite la récursion), pas de comptage de soi.

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

• regression_spec.json (contrat · planchers structurels · 0 chiffre métier)
• reglib/{__init__,deps,discovery,runner,builder}.py
  • deps : réutilise parse_ci (audit 4Big) + validateur maison Publiciste
  • discovery : dérive les suites du CI + faits de disque + preuve de couverture
  • runner : subprocess unittest + parseur PUR de la sortie (OK/FAILED/skip)
  • builder : plan déterministe (build) + matrice live (run)
• regression_gen.py (CLI build / validate / run · 8 invariants)
• regression.schema.json (contrat de sortie draft-07)
• out/{regression_plan,MANIFEST}.json (hand-off) · tests/test_regression.py (24 tests dont 3 exécutions réelles en tmpdir + 6 injections d'invariant)
• README.md · .gitignore (exclut la sortie non déterministe de run)

Fichiers modifiés

• .gitea/workflows/ci.yml : job qa-regression-tests + ajout au gate.
• qa/audit_4big/ : enregistrement du module qa/regression dans le registre (quality_spec.json) → couverture bijective 18 → 19 modules (verdict PASS 19/19 à 100) ; out/ régénéré ; test test_real_build_passes_gate rendu robuste (len(spec['modules']) au lieu du littéral 18) — plus de casse à chaque nouveau livrable.

Vérifications

• 24/24 tests du module ; 34/34 audit_4big (compte dérivé du spec).
• run exhaustif : 19/19 suites vertes · 474 tests passés · 0 échec · 0 erreur — compte agrégé faisant autorité, reproductible en une commande.
• Gate CI local vert : guard_constraints.sh · validate_json.sh · check_docs.sh · ci.yml YAML valide.
• Builds déterministes (plan identique en double build).

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

Planifier run sur le runner CI/VPS + publier le compte agrégé dans le desk ERPNext / le pipeline de release → agent QA / DevOps. Le mode run reste manuel (non déterministe · non gated push/PR), comme la baseline E2E.

Auto-score 4Big

96/100.