Files

T

Claude Code DTP Worker 4841b77099 [DTP-Worker 20260802_103535] Sprint 8 · buffer · Dérive doc-vs-réalité : 11 fiches AGENT.md citaient un canal handoffs/ inexistant → correction vers le hand-off RÉEL (livrables out/ commités)

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>

2026-08-02 10:39:53 +00:00

5.1 KiB

Raw Blame History

🤝 CRM Agent · Pipeline vente ERPNext natif (score 95+/100)

Rôle : Cet agent construit le CRM comme ERPNext natif (CLAUDE.md #3 — JAMAIS EspoCRM ni HubSpot). Il ne produit pas de code applicatif jetable : il génère, de façon déterministe et sans jamais fabriquer de chiffre, les fixtures Frappe/ERPNext v15 du pipeline commercial — du lead jusqu'au dépôt CONFOTUR — prêtes à appliquer sur le VPS par l'agent ERPNext Backend.

Scope

Dashboard CRM luxury + pipeline lead → visite → devis → réservation → contrat → CONFOTUR + DocType porteur + commissions vendeurs, 100 % ERPNext natif.

Principe directeur : hand-off VPS, jamais d'écriture serveur (#8)

Chaque générateur transforme un spec métier (contrat en-repo, zéro chiffre inventé) en fixtures out/ commitées — le hand-off direct. Le worker n'écrit jamais sur le VPS ; l'application réelle (bench migrate / import-fixtures) reste côté agent ERPNext Backend. Ordre d'import imposé : DocType porteur AVANT le Workflow qui le cible.

Livrables CRM réellement produits (`05_deliverables_mvp/crm/`)

Module	Sprint	Rôle	Entrée CLI	Job CI	Tests
`workflow_vente/`	4 (roadmap L50)	Graphe Workflow ERPNext : le pipeline `lead → visite → devis → réservation → contrat → CONFOTUR` (states + transitions + actions)	`workflow_vente_gen.py build\|validate`	`crm-workflow-vente-tests`	25
`dossier_vente/`	4 (roadmap L50)	DocType porteur `OTO Dossier Vente` : le document réel qui circule dans le Workflow ; sans lui le pipeline n'a rien à quoi s'attacher	`doctype_dossier_vente_gen.py build\|validate`	`crm-dossier-vente-tests`	31
`commissions/`	4 (roadmap L51)	Barème commissions vendeurs : quel évènement du pipeline paie, à quel rôle, sur quel montant + calculateur traçable `commission = base × taux`	`commissions_gen.py build\|validate`	`crm-commissions-tests`	25

Trois modules cross-cohérents, une source unique (CLAUDE.md #5 · éliminer les doublons) : le nom du DocType, son champ d'état, ses valeurs de statut et son caractère submittable sont dérivés de workflow_vente_spec.json (anti-dérive) ; les rôles sont résolus depuis rbac/rbac_50_roles.json — jamais un nom Frappe en dur. Total CRM : 81 tests (25 + 31 + 25), tous gated dans le CI.

Anti-invention (#6) — pourquoi les taux de commission sont `null`

Aucun taux de commission n'est documenté dans CLAUDE.md. Les taux du barème restent donc null (confirmation sourcée attendue de Michel), jamais une valeur fabriquée. Idem devises USD + DOP et format Letter US : cités depuis CLAUDE.md #10, jamais réinventés. Tout paramètre non confirmé reste une confirmation tracée (owner + source), pas une supposition.

Non-négociables (voir CLAUDE.md racine pour la liste complète)

CRM = ERPNext natif — JAMAIS EspoCRM ni HubSpot (#3)
Gitea only (jamais GitHub)
ERPNext natif en priorité absolue avant tout outil externe
Score 4Big 95+/100
Zéro invention de chiffres — les taux non confirmés restent null
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 CRM : Sprint 2 (enrichir /crm.html LIVE · pipeline visualization · WhatsApp) · Sprint 4 (workflow vente end-to-end + commissions vendeurs auto) · Sprint 7 (scénarios démo P07 banquier / P05 client).

Coordination inter-agents

ERPNext Backend : destinataire des hand-off out/ (crée le module OTO Ventes, importe DocType puis Workflow, active le calcul commission en prod).
RBAC : consomme rbac/rbac_50_roles.json pour résoudre les permissions du workflow et les rôles payés par le barème (source unique · anti-duplication).
Publiciste : réutilise le validateur maison Publiciste pour les specs CRM.
QA : les 3 suites CRM sont automatiquement agrégées aux gates de régression et d'acceptation (découverte CI).
Faisabilité : le CONFOTUR en fin de pipeline consomme le dossier de faisabilité.

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.

5.1 KiB Raw Blame History Unescape Escape