[DTP-Worker] Sprint 8 · buffer · DevOps/deploy_runbook (2e surface) : la TABLE « Plan de phases généré » — le GRAPHE de portage VPS ordonné (# · Responsable · Modules · Dépend de) — était un WILDCARD et avait DÉRIVÉ : elle omettait mobile/app_config (phase 5) ET qa/acceptance (phase 7), 20/22 modules listés pendant que la couverture prouvée était bijective 22/22. README corrigé sur l'artefact byte-gaté + gate d'identité par phase (8 morsures).

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

05_activity_log/2026-07-31.md

@@ -2606,3 +2606,61 @@ verrouillés) · `guard_constraints` · `validate_json`.
   `validate_json`).
 - **Hors périmètre worker (VPS · #8)** : néant (gate bash/python3 stdlib en-repo).
 - **Auto-score 4Big** : 96/100.
+
+## Sprint 8 · buffer · DevOps/deploy_runbook (2e surface) · la TABLE « Plan de phases généré » · le GRAPHE de portage VPS ordonné (# · Responsable · Modules · Dépend de)
+- **Constat + DÉFAUT RÉEL capté** : le README `devops/deploy_runbook` porte la table
+  « ## Plan de phases généré » (README:45-53) — les **7 phases ordonnées** que
+  l'agent DevOps suit phase par phase au portage VPS. Ses colonnes d'identité sont
+  data-derived de `out/deploy_runbook.json` : `#`=`order`, `Responsable`=`responsable`
+  (`worker`/`vps`/`worker+vps`), **Modules**=l'ensemble des modules gated déployés,
+  `Dépend de`=les n°s d'ordre des `depends_on`. Le bloc DevOps existant de
+  `check_readme_claims.sh` ne gate QUE **deux comptes agrégés** (phases ×2 dans la
+  fiche `devops` · confirmations dans le README) — ces quatre colonnes étaient un
+  **WILDCARD**. Contrairement aux surfaces buffer précédentes (« aucune valeur
+  périmée »), ici la table AVAIT **DÉRIVÉ** : elle **omettait** `mobile/app_config`
+  (phase 5) **ET** `qa/acceptance` (phase 7) — **20 modules listés sur 22** — pendant
+  que le `MANIFEST` prouvait la couverture **bijective 22/22 vs CI** (`counts.modules
+  == modules_mapped == 22`). Vert trompeur caractéristique : l'agent DevOps suivant la
+  table aurait **sauté 2 modules** au déploiement.
+- **Data-derived** : `out/deploy_runbook.json` (7 phases · `order`/`id`/`responsable`/
+  `depends_on`/`modules[]`) et sa source `deploy_spec.json.module_phase` (22 modules,
+  autorité byte-gatée par `check_artifacts` · couverture bijective prouvée vs jobs CI).
+  `check_artifacts` ne prouve QUE `deploy_runbook==build` — l'identité des LIGNES de la
+  table (qui déploie quoi · dans quel ordre · après quoi) restait non gatée.
+- **Preuve reproduite** : retirer `mobile/app_config` de la phase 5 du README →
+  `check_readme_claims` **exit 0** avant le gate (le bloc ne voyait que phases=7 &
+  confirmations=7). Un responsable périmé (phase VPS attribuée au worker) ou une
+  dépendance périmée (Frontend avant RBAC) est un hazard réel qu'aucune suite `tests/`
+  (qui teste des fonctions, pas la table commitée) n'attrape.
+- **Correction d'abord (artefact = autorité · #6)** : la table étant STALE, README
+  corrigé pour matcher l'artefact byte-gaté — phase 5 `+mobile/app_config` (& libellé
+  « + config mobile »), phase 7 `+qa/acceptance`. Consommateur régénéré : le
+  `qa/audit_4big/out/quality_report.json` enregistre la taille en octets de chaque
+  README en `evidence` (5414→5468 pour deploy_runbook) — rebuild `audit_4big` (score/
+  verdict/totaux INCHANGÉS, seule l'évidence-taille bouge · reproducibility gate).
+- **Gate ajouté** (`ci/check_readme_claims.sh`, sous-bloc « 2bis) deploy_runbook —
+  TABLE Plan de phases ») : (1) **IDENTITÉ par phase** — chaque ligne porte EXACTEMENT
+  `#`=`order` + `Responsable`=`responsable` + **Modules** (ensemble de code-spans) ==
+  modules de la phase + `Dépend de`=n°s d'ordre des `depends_on` (deps extraits par
+  digits ⇒ robuste au séparateur) ; colonne « Phase » libre (paraphrase). (2)
+  **IDENTITÉ d'ensemble** — {ordres des lignes} == {ordres de l'artefact} (aucune
+  phase FANTÔME/MANQUANTE) ET l'**UNION** des cellules Modules == les **22** modules de
+  l'artefact (aucun module OUBLIÉ/en trop — le défaut même capté). Cohérences croisées
+  (mordent un plan INTERNEMENT incohérent) : ordres contigus `1..N` sans doublon ·
+  `responsable` ∈ {worker, vps, worker+vps} · toute dépendance pointe en **arrière**
+  (n° < n° de la phase ⇒ pas de cycle). Un claim absent échoue AUSSI.
+- **8 morsures vérifiées** : README phase5 omet `mobile/app_config` (défaut original,
+  `manquants=[mobile/app_config]`) · README phase7 omet `qa/acceptance` (défaut
+  original) · README phase5 responsable `worker+vps`→`vps` (câblage) · README phase6
+  `Dépend de 4,5`→`4` (dépendance manquante) · module FANTÔME `ghost/mod` en phase5
+  (`en_trop`) · ligne FANTÔME `#8` (8≠7) · phase 6 SUPPRIMÉE (INTROUVABLE + 6≠7) ·
+  artefact phase2 responsable `vps`→`worker` (README stale). Restauré = green :
+  7 lignes == 7 phases · union Modules 22==22 · responsables/deps/modules == artefact ·
+  ordres 1..7 contigus · exit 0.
+- **État courant** : le défaut STALE est **corrigé** (README byte-aligné sur
+  l'artefact) ET la surface est désormais **gatée**. `ci/README.md` (ligne synthèse +
+  détail « 2ᵉ surface `devops/deploy_runbook` ») mis à jour · **7 gates verts**
+  (`check_readme_claims` · `check_artifacts` · `check_docs` · `check_ci_integrity` ·
+  `check_regression` · `guard_constraints` · `validate_json`).
+- **Hors périmètre worker (VPS · #8)** : néant (gate bash/python3 stdlib en-repo).
+- **Auto-score 4Big** : 96/100.