oto-enterprise-os-dtp/05_deliverables_mvp/legal/confotur

Générateur du DocType CONFOTUR Application · Sprint 5 · ONAPI/Legal

Roadmap L55 — « Refactor oto_module_confotur_application.py → dépôts automatiques ». Produit le fixture DocType custom qui porte les dossiers d'incitation touristique CONFOTUR (Ley 158-01, République Dominicaine), jusqu'ici référencé partout (RBAC, workflow vente) mais jamais généré.

Ce que ça produit

build écrit deux fichiers de hand-off dans out/ :

Fichier	Contenu
doctype_confotur_application.json	Le DocType Frappe v15 complet (custom, soumissible), prêt pour bench import-fixtures.
MANIFEST.json	Traçabilité : sources, comptes, rôles RBAC utilisés, évènements de dépôt dérivés du workflow, note anti-invention.

18 champs (14 de donnée) · 4 sections · 3 rôles · soumissible · 2 évènements de dépôt.

Cœur du livrable : cross-cohérence (zéro invention · #6)

Le DocType n'invente rien — chaque facette est dérivée d'un contrat déjà livré :

• Nom (CONFOTUR Application) = l'identité que le contrat RBAC référence (rbac_50_roles.json, permissions_cibles[].doctype). Un invariant prouve qu'au moins un rôle le vise et que tous le marquent custom.
• Permissions = mot pour mot les permissions_cibles RBAC des 3 rôles qui y ont accès — ni ajout ni retrait :
  • ventes-confotur (portail Ventes) → read/write/create/print
  • legal-onapi (portail Direction) → read/write/create
  • legal-directeur (portail Direction) → read/write/submit/report
• is_submittable = déduit de la présence de l'action submit côté RBAC (donc 1) ; recoupé avec le workflow (les états CONFOTUR sont doc_status = 1).
• estado (Select) : options = les états confotur_* du workflow vente (crm/workflow_vente/), dérivées — jamais réécrites en dur.
• dossier_vente (Link) : cible = workflow.document_type (= OTO Dossier Vente), dérivée du workflow.
• entite_porteuse (Select) : entités CLAUDE.md (WAF · WA SRL · AC · Consortium ECR DR · Helios RD · Ploutos · 9060 QC).

Renommer un rôle, retirer une action ou renommer un état côté contrat se propage ici sans édition manuelle ; l'invariant casse sinon.

Anti-invention CONFOTUR (#6)

Aucun taux d'incitation, article de loi, montant ou référence d'autorité n'est encodé. Le DocType est une structure ; ses champs substantiels (referencia_autoridad, dates, estado) restent vides, renseignés côté VPS par l'agent ONAPI/Legal depuis data_room/P05 et data_room/P07. Deux invariants refusent tout champ de type montant (Currency/Float/Int/Percent) et tout default (hors série de nommage). Les cases piece_* sont un suivi interne non normatif — la liste légale des pièces est confirmée hors-repo.

Utilisation

python3 confotur_application_gen.py validate   # schéma + 14 invariants, sans écrire
python3 confotur_application_gen.py build       # écrit out/*.json
python3 -m unittest discover -s tests -v        # 44 tests (dont 8 négatifs)

Sortie déterministe (tri stable, aucun horodatage) → diffable et re-générable bit-à-bit à contrat constant.

Hand-off VPS (hors périmètre worker · #8)

1. Créer le module Frappe OTOV7 CONFOTUR (cité par les 3 rôles RBAC).
2. Importer doctype_confotur_application.json (bench import-fixtures) avant de câbler les depot_events sur le Workflow OTO Vente Pipeline (crm/workflow_vente/out/).
3. Renseigner, depuis data_room P05/P07, les paramètres légaux/fiscaux réels (avec source · #6).

Arborescence

legal/confotur/
├── confotur_spec.json            # structure métier (libellés + types · zéro chiffre)
├── cflib/
│   ├── frappe.py                 # connaissance Frappe DocType (VALID_PERMS incl. report)
│   ├── rbac_scan.py              # lecture des rôles RBAC visant le DocType
│   └── builder.py                # assemblage déterministe {manifest, doctype}
├── confotur_application_gen.py   # CLI build/validate · 14 invariants
├── confotur.schema.json          # contrat de sortie draft-07
├── out/                          # hand-off (commité)
└── tests/test_confotur.py        # 44 tests