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é.

⚠️ Statut migration V18 (2026-08-10) · à lire AVANT le reste de ce module. Michel a émis la 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 (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 (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

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.