[DTP-Worker] Sprint 8 · buffer L75 · Doc agent ONAPI/Legal (stub→doc réelle · module CONFOTUR sourcé : DocType v15 custom soumissible CONFOTUR Application Sprint 5 L55 [18 champs · 3 rôles · 2 dépôts · 44 tests] · dérivé rbac_50_roles.json + workflow_vente_spec.json · anti-invention #6 taux/article/montant null · 0 lien mort · guards verts)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -1,17 +1,116 @@
|
||||
# ONAPI/Legal Agent
|
||||
# ⚖️ 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 Niza (36/37/43), e-CF DGII, UAF, ISA/IFRS 5D
|
||||
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)
|
||||
- ERPNext natif en priorité
|
||||
- Score 4Big 95+/100
|
||||
- Zéro invention chiffres
|
||||
- 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 semaines 1-8
|
||||
Voir `04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md` pour deliverables par sprint.
|
||||
## 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/`
|
||||
@@ -19,11 +118,13 @@ Voir `04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md` pour deliverables par sprint.
|
||||
- Blockers escalés à Michel Roy via WhatsApp +18296296385
|
||||
|
||||
## Éthique
|
||||
- Sensibilité culturelle FR/EN/ES + RD
|
||||
- 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 correspondante à cet agent.
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user