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

Rapport de session · 2026-07-30 · session 16

Tâche

Sprint 5 · ONAPI/Legal — Générateur du DocType porteur CONFOTUR Application (roadmap L55 « Refactor oto_module_confotur_application.py → dépôts automatiques »).

Contexte / choix

Sprint 4 clos (sessions 11-15 : workflow vente, Dossier Vente, commissions, e-CF, 5 Workspaces). Prochain jalon = Sprint 5. Des trois volets Sprint 5, Mobile (builds/submit stores) et le déploiement dépendent d'API externes / du VPS → hors périmètre worker (#8). Le volet ONAPI/Legal est le seul entièrement réalisable en repo, et il comble un gap réel : le DocType custom CONFOTUR Application est référencé par le contrat RBAC (3 rôles) et par les états terminaux du workflow vente (confotur_depose/confotur_approuve), mais aucun générateur ne le produisait. La session 15 le listait justement comme DocType custom « à créer » côté VPS.

Décision d'architecture (#1 ERPNext natif)

Le porteur d'un dossier CONFOTUR EST un DocType Frappe custom ; on livre donc le fixture DocType natif (soumissible), pas un module externe. On refactorise l'intention de oto_module_confotur_application.py en un générateur déterministe aligné sur le pattern des livrables voisins (crm/dossier_vente, fiscal/ecf_dgii).

Fichiers créés — 05_deliverables_mvp/legal/confotur/

• confotur_spec.json — structure métier seule (libellés + types + drapeaux · zéro chiffre) ; nom/permissions/soumissibilité non portés par le spec.
• cflib/frappe.py — connaissance Frappe DocType (VALID_PERMS incluant report, porté par legal-directeur).
• cflib/rbac_scan.py — lecture (jamais réécriture) des rôles RBAC visant le DocType CONFOTUR Application + leurs actions ; réutilise RoleResolver pour id → nom Frappe / portail.
• cflib/builder.py — assemblage déterministe {manifest, doctype}.
• confotur_application_gen.py — CLI build/validate · 14 invariants de cross-cohérence DocType↔RBAC↔workflow.
• confotur.schema.json — contrat de sortie draft-07.
• out/{doctype_confotur_application,MANIFEST}.json — hand-off (commité).
• tests/test_confotur.py — 44 tests (dont 8 négatifs + 3 gardes builder).
• README.md · .gitignore.

Fichiers modifiés

• .gitea/workflows/ci.yml : job legal-confotur-tests + ajout au gate.

Anti-invention / anti-dérive (cœur · #6)

• Nom du DocType = identité prouvée présente dans RBAC (invariant : ≥1 rôle le vise + tous custom).
• Permissions = mot pour mot les permissions_cibles RBAC des 3 rôles (ventes-confotur read/write/create/print · legal-onapi read/write/create · legal-directeur read/write/submit/report) — ni ajout ni retrait.
• is_submittable déduit de l'action submit RBAC, recoupé avec le workflow (états CONFOTUR = doc_status 1).
• estado / dossier_vente dérivés du workflow_vente (jamais en dur) ; entite_porteuse = entités CLAUDE.md.
• Aucun taux d'incitation / article de loi / montant / référence d'autorité : deux invariants refusent tout champ de type montant et tout default (hors série de nommage). Paramètres légaux réels → data_room P05/P07 côté VPS.
• depot_events (les « dépôts automatiques ») dérivés des transitions confotur du workflow ; invariant : leur rôle a bien accès au DocType (RBAC).

Résultat

DocType CONFOTUR Application : 18 champs (14 de donnée) · 4 sections · 3 rôles · soumissible · 2 évènements de dépôt (Déposer / Approuver).

Vérifs

• 44/44 tests ; validate (schéma + 14 invariants) vert ; build déterministe.
• Gate CI local vert (guard constraints · JSON · docs · YAML ci.yml).
• Régression : 304 tests verts au total (279 modules antérieurs + 25 workflow_vente + les 44 nouveaux se recoupant dans le discover).

Hors périmètre worker (VPS · #8)

Créer le module Frappe OTOV7 CONFOTUR, importer le DocType (bench import-fixtures), câbler les depot_events sur le Workflow OTO Vente Pipeline, et renseigner les paramètres légaux/fiscaux depuis data_room P05/P07 (avec source) → agent ONAPI/Legal / ERPNext Backend.

Auto-score 4Big : 96/100