[DTP-Worker] Sprint 8 · buffer L75 · Doc agent DevOps (stub→doc réelle · 2 volets sourcés : gate CI Gitea Actions L29 + run-book VPS L73)

Session 27. Remédiation stub→doc réelle sur l'agent DevOps (poursuite sessions
25 QA / 26 CRM). AGENT.md 29 lignes → doc réelle ~90 lignes.

- Table 2 livrables sourcés depuis le CI réel + README run-book
- Détail des 3 guards blocants (constraints/json/docs)
- Périmètre bijectif prouvé vs CI (anti-omission), gate-en-repo (#8)
- Anti-invention (#6) : 22 suites gated grep'ées, 29 tests, compte total
  délégué à qa/regression, confirmations VPS sourcées (owner+source)

Vérifs : guard_constraints + check_docs verts (aucun lien mort).

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

03_agents/devops/AGENT.md

@@ -1,17 +1,91 @@
-# DevOps Agent · Gitea + Systemd + Docker
+# ⚙️ DevOps Agent · Gitea CI/CD + Run-book VPS (score 95+/100)
+
+**Rôle** : Cet agent tient la **chaîne qualité et de déploiement** du mandat. Il ne
+touche **jamais** au VPS de production (CLAUDE.md #8) : il produit, en-repo et de
+façon **déterministe**, (1) le **gate CI Gitea Actions** qui conditionne tous les
+sprints et (2) le **run-book de déploiement VPS unifié** — le plan ordonné que
+l'agent DevOps/ERPNext applique ensuite côté serveur.
 
 ## Scope
-CI/CD Gitea, systemd services, docker Frappe, monitoring VPS
+CI/CD **Gitea Actions UNIQUEMENT** (CLAUDE.md #2 — **JAMAIS** GitHub) + guards des
+contraintes non-négociables + orchestration du déploiement VPS de tous les
+livrables gated en un seul graphe de phases.
+
+## Principe directeur : gate en-repo, application côté serveur (#8)
+Le worker **n'exécute rien sur le VPS**. Il livre un **gate reproductible**
+(`bash` + `git` + `python3`, zéro dépendance marketplace hors `actions/checkout`)
+et un **plan** commité ; `bench migrate`, imports de fixtures, câblage nginx/systemd
+et vérifications HTTP restent côté **agent DevOps/ERPNext Backend**.
+
+## Livrables DevOps réellement produits
+
+| Module | Sprint | Rôle | Entrée | Tests |
+|---|---|---|---|---|
+| `.gitea/workflows/ci.yml` + `ci/` | 1 (roadmap L29) | **CI/CD Gitea Actions** : 3 guards blocants (contraintes / JSON / docs) + un job de tests par livrable gated + `gate` agrégateur + `e2e-baseline` | déclenché sur `push`/`pull_request` → `main` + `workflow_dispatch` | 22 suites gated |
+| `05_deliverables_mvp/devops/deploy_runbook/` | 8 (roadmap L73) | **Run-book VPS unifié** : graphe de **7 phases ordonnées** couvrant TOUS les modules gated, dépendances inter-phases + confirmations préalables sourcées | `deploy_runbook_gen.py build\|validate` | 29 (dont 14 injections négatives) |
+
+### Le gate CI — trois guards blocants (`ci/`)
+- **`guard_constraints.sh`** : détecte l'**usage** (pas la simple mention) des
+  interdits — GitHub/GitLab/Bitbucket (#2), EspoCRM/HubSpot (#3), Stripe (#10 ·
+  Cardnet only), écriture directe dans `/var/www/html/static/`, `git clean`, remote
+  git non-Gitea. Zéro faux positif : une ligne portant un marqueur de prohibition
+  (`jamais`, `❌`, `only`, `interdit`…) est un rappel de règle → ignorée. Escape
+  hatch documenté : `ci-allow`.
+- **`validate_json.sh`** : parse strict de tous les `*.json` suivis (dont les
+  contrats de données Faisabilité → Publiciste) — un JSON cassé casse le pipeline
+  aval, attrapé ici.
+- **`check_docs.sh`** : `[HARD]` liens Markdown internes doivent exister ; `[SOFT]`
+  mention de l'auto-score 4Big attendue sur les livrables (#5).
+
+Le job **`gate`** ne passe au vert que si tous les guards **et** toutes les suites
+de tests de modules passent — c'est la matérialisation du seuil **4Big 95+/100**.
+Le compte exact des tests unitaires est **détenu et prouvé** par la matrice de
+régression (`qa/regression`), source unique — jamais recopié à la main ici.
+
+### Le run-book — 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. Un livrable ajouté au CI sans phase → `missing_in_map` →
+génération **refusée** ; une phase sans job CI → `extra_in_map` → refus. Le
+run-book **s'exclut lui-même** (séparation des pouvoirs · ISA 315). Ordre imposé
+par des contraintes ERPNext v15 dures : DocType porteur **avant** son Workflow ;
+`Role` **avant** `Role Profile`.
+
+## Anti-invention (#6)
+Le spec run-book **ne contient aucun chiffre métier** (taux, montant, seuil). Les
+paramètres réglementaires non confirmés restent des **confirmations sourcées**
+(`owner` + `source`) : `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), `custom_modules`,
+`custom_doctypes` — jamais une valeur fabriquée « pour faire PASS ». Un invariant
+**refuse** tout champ chiffré dans le catalogue de confirmations.
 
 ## Non-négociables (voir CLAUDE.md racine pour la liste complète)
-- Gitea only (jamais GitHub)
-- ERPNext natif en priorité
-- Score 4Big 95+/100
-- Zéro invention chiffres
+- **Gitea SEULE plateforme** git — **JAMAIS** GitHub/GitLab/Bitbucket (#2)
+- ERPNext natif en priorité absolue avant tout outil externe
+- Score 4Big 95+/100 (matérialisé par le `gate`)
+- Zéro invention de chiffres — confirmations sourcées, jamais de valeur fabriquée
+- **VPS pour tous projets** — le worker n'écrit jamais sur le serveur (#8)
 - Vérifier · Investiguer · Valider · Confirmer
 
-## Livrable attendu semaines 1-8
-Voir `04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md` pour deliverables par sprint.
+## Livrable attendu · roadmap
+Voir `04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md`. Volets DevOps : Sprint 1 (repo Gitea
++ CI/CD Gitea Actions · L29) · Sprint 8 (deployment production complet + monitoring
+· L73).
+
+## Coordination inter-agents
+- **Tous agents** : chaque nouveau générateur ajoute son job de tests au CI et
+  s'inscrit au `gate` — le run-book le détecte alors automatiquement (découverte
+  bijective vs CI).
+- **RBAC** : le run-book **délègue** le détail du volet RBAC au sous-run-book
+  `rbac/apply_plan` (phase 3).
+- **QA** : le gate final post-déploiement délègue aux audits `qa/audit_5d`,
+  `qa/audit_4big`, `qa/regression` (phase 7) ; le compte de tests vient de
+  `qa/regression`.
+- **Publiciste / auditeur 4Big** : réutilise le validateur JSON-Schema maison
+  (`lib/validator.py`) et le parseur CI (`q4lib.registry.parse_ci`).
+- **ERPNext Backend** : destinataire du run-book — exécute les 7 phases sur le VPS.
 
 ## Communication inter-agents
 - Rapports quotidiens dans `05_deliverables_mvp/daily_reports/`
@@ -27,3 +101,5 @@ Voir `04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md` pour deliverables par sprint.
 Voir le fichier maître : `/opt/oto/claude_code_mandate_dtp/AGENTS_EXISTING_ASSETS.md` section correspondante à cet agent.
 
 **Règle absolue** : refactorer/améliorer les modules existants avant de créer du nouveau code.
+</content>
+</invoke>