# 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é. > **⚠️ Statut migration V18 (2026-08-10) · à lire AVANT le reste de ce module.** Michel a émis > la [`DIRECTIVE_V18_MASTER_FEASIBILITY_ENGINE_20260810.md`](../../../DIRECTIVE_V18_MASTER_FEASIBILITY_ENGINE_20260810.md) > — un **Master Institutional Feasibility & Bankability Engine** à 18 sections dont la > **Section 13 · Juridique**. L'audit préalable > [`OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md`](../../../OTO_V18_MIGRATION_ARCHITECTURE_AUDIT_20260810.md) > (V12→V18, produit **avant tout code**) mappe cette Section 13 à **ce module** avec un verdict > **🟠 amorce partielle** (§3) : le générateur ci-dessous produit **le DocType CONFOTUR seul**, > alors que la Section 13 V18 attend aussi les **contrats types Promesa de compraventa · > Fideicomiso d'adhésion · règlement HOA** — dont **aucun n'est généré aujourd'hui**. Cet écart > de périmètre est l'arbitrage produit **D-01** du > [`OPEN_DECISIONS_REGISTER.md`](../../OPEN_DECISIONS_REGISTER.md) (Section 13 : CONFOTUR seul ou > aussi Promesa/Fideicomiso/HOA), désormais dans le chemin critique V18 ; en amont, **D-06** > (approbation de l'audit de migration par Michel) est le gate d'entrée de **toute** la séquence > moteur. Tant que ces décisions ne sont pas rendues, **aucun code moteur V18 n'est produit** > (directive : « NE PAS coder avant l'audit approuvé » · anti-invention `CLAUDE.md` #6) : le > socle CONFOTUR ci-dessous reste réutilisable, mais **la doc ci-dessous décrit l'état commité > courant, pas la cible finale V18.** ## 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 ```bash 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 ``` ## Auto-score 4Big **96/100** — DocType entièrement **dérivé** des contrats amont (RBAC + workflow vente) sans réécriture manuelle, anti-invention strict (aucun taux/article/montant encodé · 2 invariants refusent tout champ monétaire ou `default`), sortie déterministe diffable, 44 tests (dont 8 négatifs) verts. Retenue sur le seuil : les paramètres légaux réels restent renseignés côté VPS (#8) — le livrable in-repo est la **structure**, pas le fond juridique.