Claude Code DTP Worker
37c1e9767e
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
114 lines
6.3 KiB
Markdown
114 lines
6.3 KiB
Markdown
# 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.
|