oto-enterprise-os-dtp/03_agents/devops/AGENT.md

# ⚙️ 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 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`](../../.gitea/workflows/ci.yml) + [`ci/`](../../ci/README.md) | 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/`](../../05_deliverables_mvp/devops/deploy_runbook/README.md) | 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) |
| [`run_ci.sh`](../../run_ci.sh) | 8 (roadmap L73 · « regression exhaustifs ») | **Miroir LOCAL du gate** : rejoue en une commande, hors runner et hors réseau, l'ensemble exact des checks de `gate.needs` | `bash run_ci.sh` (outil, non un gate) | — (voir ci-dessous) |

### `run_ci.sh` — outillage local, PAS un gate (#5)
Confort développeur, pas un maillon de la chaîne de merge : le script **dérive**
sa liste de checks de `gate.needs` (`.gitea/workflows/ci.yml`, la source déjà
verrouillée par `ci/check_ci_integrity.sh`) — **zéro liste en dur**, donc aucune
dérive silencieuse possible (ajouter/retirer un job CI se répercute ici sans
édition). Il n'ajoute **aucun `ci/*.sh` ni aucune assertion** : ce n'est **pas**
un gate (CLAUDE.md #5), il ne s'inscrit pas dans `gate.needs` et, la racine
n'étant pas sous `ci/`, il échappe par construction à l'invariant qui interdit un
`ci/*.sh` non câblé au gate. Périmètre = uniquement les jobs de `gate.needs`
(exclut les jobs `workflow_dispatch` type `e2e-baseline`/`npm test` qui exigent
Node). Le décompte jobs/gates/suites est **imprimé à l'exécution** — jamais figé
dans le code, où il se périmerait (anti-invention · #6).

### 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 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 · 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/`
- Hand-off inter-agents = livrables déterministes commités in-repo (fixtures/specs `out/`, SPEC, README), consommés directement par l'agent destinataire
- Blockers escalés à Michel Roy via WhatsApp +18296296385

## Éthique
- Sensibilité culturelle FR/EN/ES + RD
- Voix Amélie QC (multilingual_v2) pour toute interaction OTOIA
- Respect brand luxury dark+doré partout

## Ressources OTOV7 déjà en place (À RÉUTILISER, ne pas dupliquer)
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>