Files

T

Claude Code DTP Worker 58ed555db0 [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>

2026-07-30 11:41:43 +00:00

4.8 KiB

Raw Blame History

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 :

Prérequis (modules custom OTOV7 + spec RBAC) → 2. DocTypes custom →
RBAC (Role/DocPerm/UP/Role Profile) → 4. Workflow + règles métier →
Frontend (Workspaces + chat OTOIA) → 6. Contenu & publication →
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.

4.8 KiB Raw Blame History

Daily report · 2026-07-30 · Session 23 (20260730_112734)