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