oto-enterprise-os-dtp/05_deliverables_mvp/daily_reports/2026-07-30-session11.md

Daily Report · 2026-07-30 · Claude Code DTP Worker (session 11)

Session : 20260730_052701

Tâche exécutée

Sprint 4 · CRM — Générateur de workflow vente ERPNext (roadmap 04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md §Sprint 4 : « workflow complet lead → visite → devis → réservation → contrat → CONFOTUR »). Prochaine tâche prioritaire in-scope worker après la clôture de la Faisabilité S3 (bancable, session 10) : premier livrable Sprint 4 100 % autorable sans VPS.

Contexte / analyse

• Relu CLAUDE.md, ROADMAP_8_WEEKS_OR_LESS.md, daily report session 10, l'AGENT.md CRM, le contrat rbac_50_roles.json (rôles portails ventes/direction/compta) et l'idiome des générateurs RBAC (fixtures_gen : frappe.py/builder.py/schema/CLI build|validate/tests + job CI + gate).
• État : RBAC clos (4 générateurs + run-book), Faisabilité close (4 volets + bancable trilingue). Sprint 4 non entamé en-repo. Le deliverable CRM « workflow lead→CONFOTUR » est structurel (états + rôles), donc sans aucun chiffre à inventer (#6) et sans dépendance VPS → cible idéale.
• Contrainte #3 (CRM = ERPNext natif) : on produit les DocTypes natifs du moteur Workflow de Frappe, jamais un moteur externe.

Réalisé — module 05_deliverables_mvp/crm/workflow_vente/

• workflow_vente_spec.json — contrat pipeline canonique : 9 états (Lead → Visite planifiée → Devis émis → Réservation confirmée → Contrat signé → CONFOTUR déposé → CONFOTUR approuvé + Abandonné/Perdu terminaux) · 11 transitions. Chaque état/transition référence un id de rôle RBAC (jamais un nom Frappe en dur).
• wflib/rbac.py — réutilisation (workflow #5, zéro duplication) de rbac_50_roles.json : résout role_id → erpnext_role_name. id absent ⇒ erreur (aucun rôle inventé · #6) ; renommage RBAC propagé automatiquement.
• wflib/erpnext.py — connaissance Frappe v15 native : DocTypes Workflow, Workflow Document State, Workflow Transition, Workflow State, Workflow Action Master ; doc_status (0/1/2) + styles de badge natifs.
• wflib/builder.py — assemblage déterministe (tri stable, aucun horodatage) : table states[], table transitions[] (triées état→action), maîtres États/Actions uniques, manifeste de traçabilité (rôles RBAC utilisés + DocType porteur custom à confirmer VPS).
• workflow.schema.json — contrat de sortie draft-07 (sous-ensemble validateur maison Publiciste).
• workflow_vente_gen.py — CLI build / validate. Refuse d'écrire si un des 9 invariants de graphe casse.
• out/ (commité, hand-off direct) : workflow.json, workflow_state.json, workflow_action_master.json, MANIFEST.json.
• tests/test_workflow_vente.py — 25 tests unittest (stdlib pur).
• CI : job crm-workflow-vente-tests ajouté au gate (.gitea/workflows/ci.yml, Gitea Actions uniquement · #2).

9 invariants de graphe (le CLI refuse d'écrire si l'un casse)

1. Conformité au schéma de sortie. 2. Unicité des noms d'état. 3. Transitions vers/depuis états déclarés. 4. Monotonie doc_status (pas de saut 0→2 ni retour arrière — natif Frappe). 5. Unicité (état, action). 6. Atteignabilité de tous les états depuis Lead. 7. ≥1 état terminal de succès (soumis, sans sortie) + terminaux sans transition sortante. 8. Séparation des pouvoirs : confirmer réservation / signer contrat / approuver CONFOTUR / annuler = pas d'auto-approbation. 9. Maîtres États/Actions == graphe + comptes manifeste cohérents.

Anti-invention (#6) + séparation des pouvoirs appliqués

• Aucun nom de rôle en dur : tous résolus depuis le contrat RBAC (source unique).
• Aucun chiffre inventé (workflow purement structurel) ; condition de transition laissée null (le métier ne documente pas de seuil chiffré).
• Étapes engageant de l'argent / clôturant ⇒ allow_self_approval = 0 (quatre-yeux), vérifié par test + CLI.

Vérifications effectuées (en-repo, sans toucher au VPS)

• 25/25 tests verts (schéma maison + oracle jsonschema) ; génération réelle : 9 états / 11 transitions / 9 maîtres États / 9 maîtres Actions ; out/ commité == régénération bit-à-bit.
• Gate CI local vert (exit 0) : guard_constraints.sh, validate_json.sh (nouveaux JSON valides), check_docs.sh (README score présent, 0 lien cassé), YAML ci.yml valide.
• Régression : 23 Publiciste + 10 RBAC + 16 Faisabilité + 11 fixtures + 12 userperm + 11 roleprofile + 16 apply_plan + 22 bancable + 25 workflow vente = 146 tests verts au total.

Non fait (hors périmètre worker · VPS)

• Création du DocType porteur OTO Dossier Vente + import des fixtures (bench migrate) → agent ERPNext Backend (contrainte #8).

Prochaine tâche suggérée

• Sprint 4 CRM : générateur des Notification/Email Alert par transition, ou du DocType porteur OTO Dossier Vente (fixture DocType) pour compléter le hand-off workflow.
• Sprint 4 ERPNext Backend : plan e-CF DGII (Compupar) + barème commissions vendeurs (calcul traçable façon module finance.py du bancable · #6).

---

Auto-score 4Big du livrable Générateur workflow vente : 96/100. Réserve −4 : création du DocType porteur + import des fixtures = côté VPS (agent ERPNext Backend, hors périmètre worker · #8) ; condition de transition non peuplée (anti-invention #6). Validé statiquement en-repo (25 tests verts + schéma conforme + 9 invariants de graphe + gate CI · 146 tests de régression au total).