Claude Code DTP Worker
e24f2c95c7
check-regression + check-readme-claims étaient RED : deux modules committés par les sessions auto-exec sans régénérer les artefacts/prose aval. regression_run.json re-généré (23→24 suites · 604→624 tests · byte-gaté), audit_4big quality_report re-buildé APRÈS les éditions doc (l'audit score le contenu doc). 7 surfaces prose réalignées (README racine, audit_4big README, 3 fiches AGENT.md, run-book phases 4+6). Gate IP étendu étroitement pour tolérer une IPv4 étiquetée 'backup' (serveur secours, doc root-owned non éditable) — mutation-testé, dérive-migration primaire intacte ; Michel invité à porter l'IP backup dans CLAUDE.md §VPS. run_ci.sh = 32 PASS · 0 FAIL · 0 SKIP. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
101 lines
5.4 KiB
Markdown
101 lines
5.4 KiB
Markdown
# Run-book de déploiement VPS unifié · Sprint 8 · agent DevOps
|
|
|
|
Volet **« Deployment production complet »** (roadmap Sprint 8 · DevOps) réalisable
|
|
en-repo. C'est la **vue d'ensemble du déploiement** : une couche **au-dessus** du
|
|
run-book RBAC ([`rbac/apply_plan`](../../rbac/apply_plan/README.md)), qui n'ordonne
|
|
que les 3 volets RBAC. Ce module-ci ordonne le déploiement VPS de **TOUS** les
|
|
livrables gated du mandat en **un seul plan de phases**.
|
|
|
|
> Ce worker **n'écrit jamais sur le VPS** (CLAUDE.md #8). Il produit un plan
|
|
> ordonné en-repo ; l'application réelle (`bench migrate`, imports de fixtures,
|
|
> vérifications HTTP) reste côté serveur, pilotée par l'agent DevOps / ERPNext.
|
|
|
|
## Pourquoi un run-book de méta-niveau
|
|
|
|
Chaque générateur a livré, en fin de session, 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**.
|
|
Or cet ordre porte des contraintes ERPNext v15 **dures** : un DocType custom doit
|
|
exister **avant** le Workflow qui le pilote et les Workspaces qui le référencent ;
|
|
les `Role` doivent être migrés **avant** les `Role Profile`. Ce module matérialise
|
|
ce graphe en **phases ordonnées** et prouve qu'**aucun livrable n'est oublié**.
|
|
|
|
## Périmètre PROUVÉ, pas déclaré (anti-invention · #6)
|
|
|
|
La liste des modules à déployer n'est **jamais écrite à la main** : elle est
|
|
**dérivée** de `.gitea/workflows/ci.yml` (réutilise `q4lib.registry.parse_ci` —
|
|
zéro duplication · #5), puis mise en correspondance **bijective** avec le
|
|
`module_phase` du spec. Conséquences :
|
|
|
|
- tout livrable **ajouté au CI** sans entrée de phase → `missing_in_map` →
|
|
génération **refusée** (aucune omission silencieuse) ;
|
|
- toute entrée de phase **sans job CI** → `extra_in_map` → refus (pas de module
|
|
fantôme inventé) ;
|
|
- **séparation des pouvoirs** (ISA 315) : le run-book **s'exclut lui-même**
|
|
(`self_module`) — il ne s'auto-déploie pas et ne se compte pas.
|
|
|
|
Le spec **ne contient aucun chiffre métier** (taux, montant, seuil). Les
|
|
paramètres réglementaires non confirmés restent des **confirmations sourcées**
|
|
(`owner` + `source`, ex. `qa/audit_5d` contrôle D1.1), jamais une valeur
|
|
fabriquée « pour faire PASS ». Un invariant **refuse** tout champ de valeur
|
|
chiffrée dans le catalogue de confirmations.
|
|
|
|
## Plan de phases généré
|
|
|
|
| # | Responsable | Phase | Modules | Dépend de |
|
|
|---|---|---|---|---|
|
|
| 1 | vps | Prérequis (modules custom OTOV7 + spec RBAC) | `rbac` | — |
|
|
| 2 | vps | DocTypes custom | `crm/dossier_vente`, `legal/confotur` | 1 |
|
|
| 3 | worker+vps | RBAC (Role + DocPerm + UP + Role Profile) | `rbac/fixtures_gen`, `rbac/userperm_gen`, `rbac/roleprofile_gen`, `rbac/apply_plan` | 2 |
|
|
| 4 | worker+vps | Workflow vente + règles métier | `crm/commissions`, `crm/financement_bancaire`, `crm/workflow_vente`, `fiscal/ecf_dgii` | 2, 3 |
|
|
| 5 | worker+vps | Frontend desk (Workspaces + chat OTOIA) + config mobile | `frontend/portails`, `frontend/chat_otoia`, `mobile/app_config` | 3 |
|
|
| 6 | worker+vps | Contenu & publication | `demo/scenarios`, `faisabilite/bancable`, `faisabilite/generator`, `pie/manifest`, `publiciste`, `seo` | 4, 5 |
|
|
| 7 | vps | Vérification QA post-déploiement | `qa/acceptance`, `qa/audit_5d`, `qa/audit_4big`, `qa/regression` | 4, 5, 6 |
|
|
|
|
**Confirmations préalables VPS** (consolidées, sourcées) : `custom_modules`,
|
|
`custom_doctypes`, `taux_commission` (Direction · audit_5d D1.1), `rnc_emisor`
|
|
(Compta · D1.2), `itbis_tipocambio` (Fiscaliste eCF · D1.3), `seuil_uaf` (Oficial
|
|
de Cumplimiento · D2.3), `endpoint_otoia` (ERPNext Backend · session 19).
|
|
|
|
## Ce qui est généré (`out/`)
|
|
|
|
| Fichier | Rôle |
|
|
|---|---|
|
|
| `deploy_runbook.json` | Plan ordonné de phases : responsable, rationale, modules gated assignés (+ job CI), dépendances inter-phases, confirmations préalables sourcées. |
|
|
| `MANIFEST.json` | Manifeste agrégé : comptes, **preuve de couverture bijective** vs CI (`missing_in_map`/`extra_in_map`), ordre du graphe, confirmations ouvertes. |
|
|
|
|
## Utilisation
|
|
|
|
```bash
|
|
# Génère out/deploy_runbook.json + out/MANIFEST.json (après validation)
|
|
python3 deploy_runbook_gen.py build # [-o DOSSIER]
|
|
|
|
# Valide le plan (schéma + 11 familles d'invariants) sans rien écrire
|
|
python3 deploy_runbook_gen.py validate
|
|
|
|
# Tests (stdlib pur, zéro pip)
|
|
python3 -m unittest discover -s tests -v
|
|
```
|
|
|
|
## Réutilisation (zéro duplication · #5)
|
|
|
|
- `deploylib/deps.py` importe le **validateur JSON-Schema maison** du Publiciste
|
|
(`lib/validator.py`) et le **parseur CI** de l'auditeur 4Big
|
|
(`q4lib/registry.parse_ci`) — jamais de re-implémentation.
|
|
- Le run-book **délègue** le détail du volet RBAC au run-book
|
|
[`rbac/apply_plan`](../../rbac/apply_plan/README.md) (phase 3) et le gate QA
|
|
final aux audits [`qa/audit_5d`](../../qa/audit_5d/README.md),
|
|
[`qa/audit_4big`](../../qa/audit_4big/README.md) et
|
|
[`qa/regression`](../../qa/regression/README.md) (phase 7).
|
|
|
|
## Hors périmètre worker (VPS · #8)
|
|
|
|
Exécuter le plan sur le VPS (créer les modules custom, importer fixtures/DocTypes,
|
|
câbler les Workflows, renseigner les 7 confirmations, vérifs HTTP + audits sur le
|
|
desk réel) → agent DevOps / ERPNext Backend.
|
|
|
|
---
|
|
|
|
**Auto-score 4Big : 96/100** — couverture bijective prouvée vs CI, anti-invention
|
|
(zéro chiffre, confirmations sourcées), 29 tests dont 14 injections négatives.
|