Claude Code DTP Worker
d7dbda9e2b
Classe prose FACT count ungated (prose-facts-vs-numeric-drift). Défaut : README:9 « la structure des 6 sections » + fiche CRM AGENT.md:47 « cœur du gate + 6 sections » décrivaient le livrable avec un compte périmé. Le bon compte = 7 est triple-sourcé et byte-gaté : out/MANIFEST.json counts.sections=7 · financement_spec.json bloc sections=7 (apport_initial,info_achat,choix_banque,formulaires,exigences,autorisations,envoi) · et le README se contredisait lui-même (L49 énumère 7, L57 « 7 sections » annotée source=MANIFEST). Origine du 6 : la DIRECTIVE originale énumérait 6 sections non-gating puis fut amendée pour ajouter apport_initial (gating, pos.1) → 7 ; spec+module ont suivi, les 2 prose L9/L47 non. Correctif 6→7 sur les 2 SEULES surfaces d'implémentation. Les 4 « 6 sections » restantes sont des snapshots directive gelés (DIRECTIVE_FINANCEMENT L106/122/131 + DIRECTIVE_WORKFLOW_V10 L22/47) — input-specs datés de Michel, jamais réécrits (directive-vs-implementation · spec=authority) ; leur « 6 » est exact au cadre pré-amendement → INTACTS. 0 gate ajouté (#5 · un gate structuré ne mordrait pas la prose L9, hors-cible ; SIGNAL surfacé : financement seul module dont MANIFEST.counts n'est pas recompté par check_readme_claims). 0 chiffre inventé (#6). 0 production éditée. 0 commande VPS (#8). run_ci.sh 33 PASS 0 FAIL 0 SKIP. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
8.5 KiB
🤝 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 — c'est le
total du trio pipeline ; le module financement bancaire ci-dessous porte ses
35 tests à part (source distincte).
Module CRM additionnel · financement bancaire hypothécaire (piloté par directive)
Un quatrième livrable CRM vit sous 05_deliverables_mvp/crm/ hors du trio
pipeline — piloté non par workflow_vente_spec.json mais par une directive datée
de Michel, d'où son suivi séparé (il ne partage pas la source unique du trio) :
| Module | Sprint | Rôle | Entrée CLI | Job CI | Tests |
|---|---|---|---|---|---|
financement_bancaire/ |
4 (roadmap L52) | Parcours hypothécaire RD : cœur métier du gate check 4 conditions — aucun document n'est transmis à la banque tant que apport initial (20 % résident · 30 % étranger · Ley 189-11) + documents exigés + autorisations signées + validation référente ne sont pas réunis ; fonctions pures sans I/O | financement_bancaire_gen.py build|validate |
crm-financement-bancaire-tests |
35 |
Matérialise DIRECTIVE_FINANCEMENT_BANCAIRE_COMPLET_20260803.md
(Phase 1 · P0 · MVP : contrat de données + cœur du gate + 7 sections + bannière
critique). La Phase 2 (formulaires PDF officiels des 6 banques, endpoints
runtime /api/hypotheque/*, renderHypotheque) attend les démarches
relationship-manager de Michel et l'exécution VPS — hors périmètre worker (#8).
Décision produit ouverte — la condition #4 du gate teste encore une validation
humaine (wag_validated_by), alors que la couche ## PRÉCISION de la directive
la supersède par un audit IA signé ; producteur d'audit hors dépôt → arbitrage
de séquencement, surfacé non tranché dans
OPEN_DECISIONS_REGISTER.md D-02
(ne pas re-litiger · #5).
Livrable transverse · Sprint 7 — scénarios démo (co-porté CRM + Faisabilité)
Un cinquième livrable vit sous 05_deliverables_mvp/demo/scenarios/ : pas un
livrable CRM propre, mais un méta-générateur qui compose les livrables déjà
produits (pipeline CRM + dossier de vente, bancable, e-CF, CONFOTUR, portails, OTOIA,
SEO) en un run-sheet de pitch — sans jamais écrire une donnée métier lui-même
(CLAUDE.md #6). Il matérialise la roadmap Sprint 7 (« CRM + Faisabilité : scénarios
démo P07 banquier / P05 client », L68) et est donc co-porté avec l'agent
Faisabilité — recensé ici parce que le pipeline CRM en est le fil conducteur, mais il
ne partage aucune source avec le trio ni avec le financement ci-dessus :
| Module | Sprint | Rôle | Entrée CLI | Job CI | Tests |
|---|---|---|---|---|---|
scenarios/ |
7 (roadmap L68) | Méta-générateur demo/scenarios : compose les livrables existants en 2 run-sheets (S-P07-BANQUIER · S-P05-CLIENT) — zéro donnée métier inventée, tout est cité depuis les artefacts amont |
demo_scenario_gen.py build|validate |
demo-scenario-tests |
39 |
La cellule Tests 39 est auto-gatée exactement comme les lignes du trio :
check_readme_claims recompute chaque cellule « Tests » de fiche depuis
regression_plan.json (source unique · demo/scenarios ∈ plan.suites). Détail des
2 scénarios, des invariants et de la composition dans le README du module.
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 moduleOTO Ventes, importe DocType puis Workflow, active le calcul commission en prod). - RBAC : consomme
rbac/rbac_50_roles.jsonpour 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.