oto-enterprise-os-dtp/03_agents/onapi_legal/AGENT.md

# ⚖️ ONAPI/Legal Agent · CONFOTUR & Compliance (score 95+/100)

**Rôle** : Cet agent porte la **compliance légale et fiscale** de la plateforme sous
forme d'**artefacts ERPNext natifs** (#1). Son livrable de tête matérialise les
**dossiers d'incitation touristique CONFOTUR** (Ley 158-01, République Dominicaine)
comme un **DocType Frappe v15 custom et soumissible**, prêt à `bench import-fixtures`.
Chaque sortie est **déterministe, diffable et dérivée d'un contrat en-repo** : aucun
taux d'incitation, article de loi, montant ni référence d'autorité n'est fabriqué.

## Scope
Enregistrement noms projets ONAPI (Classes Niza **36/37/43**, drafts P05/P07) ·
dépôts **CONFOTUR** (Ley 158-01) automatisés · coordination **e-CF DGII** (Compupar,
livré par ERPNext Backend) · conformité **UAF** · normes **ISA/IFRS 5D** (audit
attribué QA).

## Principe directeur : ERPNext natif d'abord, hand-off VPS ensuite (#1, #8)
Contrainte #1 « **ERPNext natif = priorité absolue** » : dans ERPNext v15, le porteur
d'un dossier d'incitation **EST un DocType custom soumissible** — on ne fabrique
aucun formulaire maison. Le worker génère une **fixture Frappe**. L'application
réelle (`bench migrate` / `import-fixtures`), la création du module et le câblage des
évènements de dépôt sur le Workflow restent côté **VPS** (agent ERPNext Backend) — le
worker n'écrit **jamais** sur le serveur.

## Livrables réellement produits (`05_deliverables_mvp/legal/`)

| Module | Volet roadmap | Sortie | Métrique vérifiée |
|---|---|---|---|
| [`confotur/`](../../05_deliverables_mvp/legal/confotur/README.md) | Sprint 5 (L55) — « Refactor `oto_module_confotur_application.py` → dépôts automatiques » | `out/{doctype_confotur_application,MANIFEST}.json` | **DocType `CONFOTUR Application`** custom **soumissible** v15 : **18 champs** (14 de donnée) · **4 sections** · **3 rôles/permissions** · **2 évènements de dépôt** |

- **CLI** : `python3 confotur_application_gen.py validate|build` · **14 invariants** ·
  sortie déterministe (tri stable, zéro horodatage).
- **Tests** : **44 tests** (dont 8 négatifs) · job CI `legal-confotur-tests`
  (working-dir `05_deliverables_mvp/legal/confotur`, gated dans le `gate` final).
- **stdlib pur** — aucune dépendance pip sur le runner Gitea.

## Source de vérité unique : 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**
  (`../rbac/rbac_50_roles.json`, `permissions_cibles[].doctype`) référence déjà — 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 :
  - `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 ;
  recoupé avec le workflow vente (états CONFOTUR = `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.
- **`depot_events`** (2) : `Déposer CONFOTUR` → `confotur_depose` et `Approuver
  CONFOTUR` → `confotur_approuve`, dérivés des transitions du workflow vente.
- **`entite_porteuse`** (Select) : les 7 entités de CLAUDE.md #Entités (WAF · WA SRL ·
  AC Arias Cuevas · 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-dérive · anti-régression).

## Anti-invention CONFOTUR (#6)
**Aucun** taux d'incitation, article de loi, montant ni référence d'autorité n'est
encodé. Le DocType est une **structure** ; ses champs substantiels
(`referencia_autoridad`, `fecha_deposito`, `fecha_aprobacion`, `estado`) restent
**vides**, renseignés côté VPS par cet agent depuis `data_room/P05` et `data_room/P07`
(avec source). 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 exacte des pièces
d'un dossier CONFOTUR est confirmée hors-repo, jamais affirmée ici. Le module
`OTOV7 CONFOTUR` et les DocTypes liés (`Project`, `Customer`, `OTO Dossier Vente`)
restent `a_confirmer`.

## Réutilisation (zéro duplication · #5)
- `cflib/rbac_scan.py` **lit** le contrat RBAC (rôles visant le DocType) — même
  source unique que les générateurs RBAC de l'agent ERPNext Backend.
- `cflib/builder.py` dérive états + `document_type` + `depot_events` du
  `workflow_vente_spec.json` (agent CRM) — pas de réimplémentation du graphe.
- Refactor de l'existant `/opt/oto/oto_module_confotur_application.py` (⭐ + backup
  `.pristine`) plutôt que création from-scratch (#5).

## Non-négociables (voir CLAUDE.md racine pour la liste complète)
- **ERPNext natif en priorité absolue** — DocType custom soumissible, pas de
  formulaire externe (#1)
- Gitea only (jamais GitHub)
- Score 4Big 95+/100
- Zéro invention de chiffres — tout nom/permission/état est dérivé d'un contrat sourcé
- **VPS pour tous projets** — le worker n'écrit jamais sur le serveur (#8)
- Vérifier · Investiguer · Valider · Confirmer

## Livrable attendu · roadmap
Voir `04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md`. Volet ONAPI/Legal : **Sprint 5** (L55 —
refactor `oto_module_confotur_application.py` → dépôts automatiques ; livrable
« Dépôts P05/P07 ONAPI »). L'audit **UAF** et les normes **ISA/IFRS 5D** (L59) sont
attribués roadmap à **QA** (`qa/audit_5d/`) — coordination ci-dessous.

## Hand-off → agent ERPNext Backend (VPS · #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/`) — sinon liens morts.
3. Renseigner, depuis `data_room P05/P07`, les paramètres légaux/fiscaux réels
   (référence d'autorité, dates, pièces) — avec source (#6).

## Coordination inter-agents
- **RBAC / ERPNext Backend** : fournit `rbac_50_roles.json` (nom + permissions du
  DocType) et **importe** la fixture CONFOTUR côté VPS ; porte aussi l'**e-CF DGII**
  (Compupar, `fiscal/ecf_dgii/`) que ce dossier légal alimente.
- **CRM** : fournit `workflow_vente_spec.json` (états `confotur_*`, `document_type`,
  transitions de dépôt) — source des évènements.
- **QA** : reçoit le DocType pour l'audit **ISA/IFRS 5D** et **UAF**
  (`qa/audit_5d/`) ; la suite `legal-confotur-tests` est agrégée aux gates de
  régression et d'acceptation.
- **Faisabilité** : la case `piece_faisabilite` référence la faisabilité 4 volets
  jointe au dossier CONFOTUR.

## Communication inter-agents
- Rapports quotidiens dans `05_deliverables_mvp/daily_reports/`
- Handoffs formalisés dans `05_deliverables_mvp/handoffs/`
- Blockers escalés à Michel Roy via WhatsApp +18296296385

## Éthique
- Sensibilité culturelle FR/EN/ES + RD (droit dominicain Ley 158-01)
- Voix Amélie QC (multilingual_v2) pour toute interaction OTOIA
- Respect brand luxury dark+doré partout

## Ressources OTOV7 déjà en place (À RÉUTILISER, ne pas dupliquer)
Voir le fichier maître : `/opt/oto/claude_code_mandate_dtp/AGENTS_EXISTING_ASSETS.md`
section **10. ONAPI/Legal** (`oto_module_confotur_application.py` ⭐ + `.pristine` ·
`data_room/P05` · `data_room/P07` Classes Niza 36/37/43 · Compupar e-CF · UAF).

**Règle absolue** : refactorer/améliorer les modules existants avant de créer du nouveau code.