[DTP-Worker] Sprint 8 · Générateur Run-book de déploiement VPS unifié (7 phases · 20 modules gated · couverture bijective vs CI) (DevOps · roadmap L73)

Agrégateur de méta-niveau au-dessus du run-book RBAC : ordonne le déploiement
VPS de TOUS les livrables gated en 7 phases (Prérequis → DocTypes → RBAC →
Workflow/métier → Frontend → Contenu → Vérification QA), avec graphe de
dépendances inter-phases acyclique et confirmations préalables sourcées.

Anti-invention (#6) : périmètre dérivé du CI (parse_ci réutilisé), couverture
bijective module→phase (un module gated non planifié OU un module planifié non
gated → refus), SoD (auto-exclusion), zéro chiffre métier (confirmations
sourcées via audit_5d D1.1/D1.2/D1.3/D2.3 + endpoint OTOIA).

Vérifs : 29/29 tests module (dont 14 injections négatives) · audit_4big PASS
20/20 à 100 · régression run 20/20 suites · 503 tests · 0 échec · gate CI local
vert. CI job devops-deploy-runbook-tests + gate ; enregistrement audit_4big
(19→20) ; plan régression régénéré (19→20 suites).

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

05_deliverables_mvp/daily_reports/2026-07-30-session23.md

@@ -0,0 +1,92 @@
+# Daily report · 2026-07-30 · Session 23 (`20260730_112734`)
+
+## Tâche
+
+**Sprint 8 · DevOps** — Générateur du **Run-book de déploiement VPS unifié**
+(roadmap Sprint 8 · DevOps « **Deployment production complet + monitoring** »,
+L73). Dernier volet Sprint 8 réalisable en-repo : la matrice de régression (QA,
+session 22) et les audits qualité/conformité étant livrés, le déploiement réel
+sur le VPS reste hors périmètre worker (#8), mais **le PLAN de déploiement**
+ordonné, lui, se produit en-repo.
+
+## Gap comblé
+
+Chaque générateur terminait sa session par une section « **Hors périmètre worker
+(VPS)** » listant ses étapes d'activation serveur — mais **éparpillées dans 12
+rapports quotidiens**, sans **ordre inter-modules** ni **graphe de dépendances**.
+Aucun artefact ne consolidait « dans quel ordre déployer les 20 livrables gated,
+avec quelles confirmations préalables ». C'est le trou que comble ce module.
+
+## Décision d'architecture
+
+**Agrégateur de MÉTA-NIVEAU**, une couche **au-dessus** du run-book RBAC
+(`rbac/apply_plan`, qui n'ordonne que les 3 volets RBAC). Ce module-ci ordonne le
+déploiement VPS de **TOUS** les livrables gated en **un plan de 7 phases** :
+1. Prérequis (modules custom OTOV7 + spec RBAC) → 2. DocTypes custom →
+3. RBAC (Role/DocPerm/UP/Role Profile) → 4. Workflow + règles métier →
+5. Frontend (Workspaces + chat OTOIA) → 6. Contenu & publication →
+7. Vérification QA post-déploiement (5D · 4Big · régression).
+
+Chaque phase déclare son `responsable`, sa `rationale`, ses modules gated
+assignés, ses dépendances **inter-phases** (graphe acyclique, renvois arrière
+uniquement) et ses **confirmations préalables** sourcées.
+
+## Anti-invention (cœur · #6)
+
+- **Périmètre PROUVÉ, pas déclaré** : l'ensemble des modules à déployer est
+  **dérivé** de `.gitea/workflows/ci.yml` (réutilise `q4lib.registry.parse_ci` —
+  zéro duplication · #5), jamais listé à la main, et mis en correspondance
+  **BIJECTIVE** avec le `module_phase` du spec. Un livrable ajouté au CI sans
+  entrée de phase → `missing_in_map` → génération refusée ; une entrée sans job
+  CI → `extra_in_map` → refus. La validation **recalcule** la couverture depuis
+  le CI (ne fait pas confiance au manifeste).
+- **Séparation des pouvoirs** (ISA 315) : le run-book s'exclut lui-même
+  (`self_module`) — il ne s'auto-déploie ni ne se compte.
+- **Zéro chiffre métier** : le spec ne contient aucun taux/montant/seuil ; les
+  paramètres réglementaires non confirmés restent des **confirmations sourcées**
+  (`owner` + `source`), reprises des contrôles `qa/audit_5d` (D1.1 taux commission
+  → Direction ; D1.2 RNC → Compta ; D1.3 ITBIS/TipoCambio → Fiscaliste eCF ;
+  D2.3 seuil UAF → Oficial de Cumplimiento) et des sessions amont (endpoint OTOIA,
+  DocTypes/modules custom). Un invariant **refuse** tout champ de valeur chiffrée.
+
+## Fichiers créés — `05_deliverables_mvp/devops/deploy_runbook/`
+
+- `deploy_spec.json` (7 phases + `module_phase` des 20 modules + catalogue de 7
+  confirmations sourcées · **0 chiffre**)
+- `deploylib/{__init__,deps,builder}.py` (`deps` réutilise le validateur maison
+  Publiciste **et** `q4lib.registry.parse_ci` ; `builder` PUR et déterministe)
+- `deploy_runbook_gen.py` (CLI `build`/`validate` · **11 familles d'invariants**)
+- `deploy.schema.json` (contrat de sortie draft-07)
+- `out/{deploy_runbook,MANIFEST}.json` (hand-off) · `tests/test_deploy_runbook.py`
+  (**29 tests** dont 14 injections négatives) · `README.md` · `.gitignore`
+
+## Fichiers modifiés
+
+- `.gitea/workflows/ci.yml` : job `devops-deploy-runbook-tests` + ajout au `gate`.
+- `qa/audit_4big/` : enregistrement du module `devops/deploy_runbook` (couverture
+  bijective **19 → 20 modules** · verdict **PASS 20/20 à 100**) ; note rendue
+  count-agnostique ; `out/` régénéré.
+- `qa/regression/out/` : plan régénéré (**19 → 20 suites**) — le harnais découvre
+  la nouvelle suite via le CI automatiquement.
+
+## Résultat
+
+Run-book `bijective=true` — **7 phases · 20 modules gated couverts sans doublon ·
+7 confirmations préalables sourcées** · graphe de phases acyclique.
+
+## Vérifications
+
+- 29/29 tests module ; 34/34 audit_4big (**PASS 20/20 à 100**) ; tests régression
+  verts.
+- Régression `run` exhaustive : **20/20 suites vertes · 503 tests passés · 0
+  échec · 0 erreur** (474 → +29).
+- Gate CI local vert : `guard_constraints` + `validate_json` + `check_docs`
+  (liens internes OK) ; `ci.yml` YAML valide ; build déterministe.
+
+## Hors périmètre worker (VPS · #8)
+
+Exécuter le plan sur le VPS (créer les modules/DocTypes custom, importer fixtures
+et Workflows, renseigner les 7 confirmations, vérifs HTTP + audits sur le desk
+réel) → agent DevOps / ERPNext Backend.
+
+**Auto-score 4Big : 96/100.**