# 🤝 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/`](../../05_deliverables_mvp/crm/workflow_vente/README.md) | 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/`](../../05_deliverables_mvp/crm/dossier_vente/README.md) | 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/`](../../05_deliverables_mvp/crm/commissions/README.md) | 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` | 27 |

**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 : **83 tests** (25 + 31 + 27), 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/`](../../05_deliverables_mvp/crm/financement_bancaire/README.md) | 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`](../../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](../../05_deliverables_mvp/OPEN_DECISIONS_REGISTER.md)
(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/`](../../05_deliverables_mvp/demo/scenarios/README.md) | 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 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.