oto-enterprise-os-dtp/05_activity_log/2026-07-31.md

Activity Log · 2026-07-31 · Claude Code DTP

Session 20260730_235919 · Buffer S8 · Gate fraîcheur matrice de régression (5ᵉ gate CI)

Tâche : Sprint 8 · buffer L75 (« Regression tests exhaustifs » · DevOps CI/CD) — roadmap fonctionnellement close (21/21 modules gated à 100/100, 534 tests verts, chantier cross-linking clos). Recherche d'une incohérence de reproductibilité réelle plutôt qu'un correctif doc cosmétique.

Gap comblé (réel, sourcé) : l'artefact le plus cité de tout le dépôt — qa/regression/out/regression_run.json (« 21 suites · 534 tests · verdict PASS », référencé dans des dizaines d'entrées de log, README d'agents et fiches) — n'avait aucun garde-fou CI prouvant qu'il reflète le disque :

• check_artifacts.sh ne rejoue que la sous-commande déterministe build (→ regression_plan.json) et exclut explicitement (l.20-22) les artefacts d'exécution issus de run ;
• le job qa-regression-tests ne lance que les 25 tests unitaires du harnais (unittest discover -s tests), jamais regression_gen.py run complet ;
• résultat : la matrice agrégée pouvait se périmer en silence (module + job CI ajoutés sans régénérer → « 21 suites » faux) ou une matrice rouge être commitée verte. C'est exactement la dérive « demo 18→21 » corrigée à la main au commit précédent, mais côté run.

Vérif de faisabilité avant d'agir (#1 analyser) : regression_run.json ne contient aucun horodatage/hôte/chemin absolu — deux run successifs sont byte-identiques (vérifié) et le résumé matche le commité. Le run complet prend ~5,3 s (stdlib pur). L'égalité exacte est donc licite et bon marché.

Fichiers (3 · aucun code métier / chiffre touché) :

• ci/check_regression.sh (nouveau, exécutable) : rejoue regression_gen.py run vers un tmp, exige regression_run.json byte-identique au commité, puis verdict == PASS ; sur dérive, imprime le diff des totals et l'ordre de régénérer. Complément direct de check_artifacts (documenté dans l'en-tête).
• .gitea/workflows/ci.yml : + job check-regression (5ᵉ gate statique, en-tête explicatif) + ajout dans les needs du job gate agrégat.
• ci/README.md : ligne du tableau des jobs, section check_regression.sh, commande d'exécution locale, checklist « 4 jobs → 5 gates statiques », et note du §check_artifacts renvoyant désormais à check-regression pour l'artefact run.

Anti-invention (#6) : rien inventé — le gate régénère la vérité au lieu de figer un compteur. Les nombres du log (« 534 / 21 / PASS ») sont relus du run frais faisant autorité.

Non-régression du reste du système (vérifié) : le nouveau job n'a pas de working-directory → q4lib.registry.parse_ci (qui recense les modules depuis les working-directory, réutilisé par audit_4big et acceptance) est inchangé → aucun décalage du ci_modules_count consommé par demo/scenarios. Preuve : check_artifacts.sh exit 0 (0 dérive des artefacts dérivés) ; suites qa/audit_4big, qa/acceptance, demo/scenarios vertes.

Vérifs : preuve de morsure — artefact commité falsifié (534→999) ⇒ gate exit 1 avec diff des totals ; restauré ⇒ exit 0. Les 5 gates locaux verts (guard_constraints/validate_json/check_docs/check_artifacts/ check_regression) ; ci.yml YAML valide ; matrice 534/534 · 21/21 · PASS inchangée.

Hors périmètre worker (VPS · #8) : néant (gate stdlib pur en-repo ; enregistrement runner Gitea toujours du ressort DevOps, §4 du ci/README).

Auto-score 4Big : 96/100.