Claude Code DTP Worker
088faa9ed9
Les 4 dernières fiches du chantier (annoncées 'reste' par les sessions précédentes) listaient leurs livrables en code-spans nus : aucun chemin cliquable de la fiche vers l'artefact gated qui la réalise. Passage aux liens markdown relatifs, pattern déjà appliqué à faisabilite/publiciste/qa/erpnext/crm : - seo : colonne Sortie -> out/*.json + module -> README.md (5 liens) - devops : ci.yml + ci/README.md + deploy_runbook/README.md (3 liens) - frontend_console : portails/ + chat_otoia/ -> README.md (2 liens) - onapi_legal : confotur/ -> README.md (1 lien) Anti-invention #6 : 11 cibles verifiees existantes (test -f) avant edition ; 0 texte descriptif/chiffre modifie, 0 code touche (doc-only). Guards verts : check_docs exit 0 (0 lien interne casse) · guard_constraints exit 0. Regression inchangee (534 verts). Chantier cross-linking desormais complet sur les 13 agents. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
106 lines
6.3 KiB
Markdown
106 lines
6.3 KiB
Markdown
# ⚙️ 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) |
|
|
|
|
### 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/`
|
|
- Handoffs formalisés dans `05_deliverables_mvp/handoffs/`
|
|
- 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>
|