[DTP-Worker] Sprint 8 · buffer L75 · Chiffre vivant périmé dans la doc du CI : ci/README.md illustrait check_regression par "551 tests" (→558) + décrivait 2 docs gatés au lieu de 3 (fiche Backend omise)

- ci/README.md:80 : compte vivant figé "22 suites · 551 tests" (périmé, matrice=558)
  remplacé par un renvoi au recompute check_readme_claims → zéro surface de dérive (#6)
- ci/README.md:130 : "le run réel 22/551" (présent, faux) → reformulé point-in-time ;
  534 conservé comme anecdote historique du défaut corrigé
- ci/README.md:121-134 : "les deux docs d'entrée" → "les trois" + ajout du bloc
  fiche ERPNext Backend (couverture ajoutée session 043004, omise du doc) → doc == code
- 7 gates verts ; check_artifacts inchangé (édition hors 05_deliverables_mvp)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

ci/README.md

@@ -76,8 +76,9 @@ Rejoue la **matrice de régression** complète (`qa/regression/regression_gen.py
 **byte-identique** au commité, puis que son verdict soit `PASS`. Complément direct
 de `check_artifacts` : celui-ci ne rejoue que `build` (→ `regression_plan.json`) et
 laisse hors périmètre l'artefact d'**exécution** `regression_run.json` — pourtant
-c'est *lui* qui porte les compteurs cités partout dans la doc et les logs
-(« 22 suites · 551 tests · PASS »). Sans ce gate, ce chiffre pouvait se périmer en
+c'est *lui* qui porte le compte agrégé (suites · tests · passés · verdict) cité dans
+la doc et les logs — recompté par `check_readme_claims` dans les fiches d'entrée,
+jamais figé en dur ici. Sans ce gate, ce compte pouvait se périmer en
 silence (module + job CI ajoutés sans régénérer la matrice → compte de suites faux ;
 c'est la dérive « demo 18→21 » corrigée à la main), ou une matrice rouge être
 commitée verte. `regression_run.json` ne contient aucun horodatage/hôte → le run est
@@ -118,7 +119,7 @@ README se **périment en silence** tout en restant « sourcés » vers un artefa
 autre chose — un README qui se **contredit avec sa propre source** est un « vert
 trompeur » (même classe que la matrice périmée « demo 18→21 » ou INV4, appliqué à la
 doc d'entrée). Ce gate **recompute** chaque chiffre depuis l'artefact cité (jamais une
-liste à la main · #6) et exige l'égalité avec ce qui est **écrit** dans les deux
+liste à la main · #6) et exige l'égalité avec ce qui est **écrit** dans les trois
 docs d'entrée — `README.md` :
 - modules gated `N/M` à `K/100` + verdict `PASS` → `qa/audit_4big/out/quality_report.json` (`totals`) ;
 - `N` suites gated → `qa/regression/out/regression_plan.json` (`totals.suites`) ;
@@ -127,9 +128,13 @@ docs d'entrée — `README.md` :
 
 Et la fiche QA `03_agents/qa/AGENT.md` (section « Verdict agrégé courant », qui se
 disait « jamais compté à la main » tout en portant un compte figé qui s'est périmé
-« 21 suites · 534 tests » vs le run réel `22 / 551 ») :
+— « 21 suites · 534 tests » alors que le run agrégé faisant autorité en disait davantage) :
 - `N` suites · `M` tests · `M` passés · `E` échec · `E` erreur · verdict → `qa/regression/out/regression_run.json` (compte agrégé faisant autorité, commité).
 
+Et la fiche ERPNext Backend `03_agents/erpnext_backend/AGENT.md` (ligne « source unique »,
+même compte agrégé jadis saisi à la main qui s'était périmé — « 560 tests ») :
+- `N` tests · `M` suites · verdict → `qa/regression/out/regression_run.json` (matrice de régression du repo, même source faisant autorité que la fiche QA).
+
 Un claim **absent** échoue aussi (la dérive de formulation qui ferait
 disparaître un chiffre est elle-même une régression de traçabilité). stdlib pur
 (bash/git/python3), zéro réseau.