Claude Code DTP Worker
4841b77099
Bloc « Communication inter-agents » (boilerplate identique ×11) promettait `05_deliverables_mvp/handoffs/` : répertoire inexistant (0 fichier, 0 consommateur, 0 gate). Échappé à check_docs.sh car chemin en code-span backtick (neutralisé l.28, à dessein — gater les backticks = faux positifs massifs, donc NON élargi). Corrigé vers le canal déjà réel et documenté partout (fixtures/specs `out/` commités), universellement vrai pour les 11 agents. 7 gates verts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
6.4 KiB
⚙️ 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 + 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*.jsonsuivis (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 deqa/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.