Claude Code DTP Worker
58ed555db0
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>
93 lines
4.8 KiB
Markdown
93 lines
4.8 KiB
Markdown
# 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.**
|