Claude Code DTP Worker
35a20247f8
DocType custom porteur des dossiers d'incitation touristique CONFOTUR (Ley 158-01, RD), référencé par RBAC (3 rôles) et le workflow vente mais jamais généré. Permissions = permissions_cibles RBAC mot pour mot ; is_submittable déduit de l'action submit ; estado/dossier_vente dérivés du workflow ; aucun taux/loi/montant fabriqué (#6). 14 invariants, 44 tests, hand-off dans out/. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
77 lines
4.2 KiB
Markdown
77 lines
4.2 KiB
Markdown
# Rapport de session · 2026-07-30 · session 16
|
|
|
|
## Tâche
|
|
**Sprint 5 · ONAPI/Legal** — Générateur du **DocType porteur `CONFOTUR Application`**
|
|
(roadmap **L55** « Refactor `oto_module_confotur_application.py` → dépôts
|
|
automatiques »).
|
|
|
|
## Contexte / choix
|
|
Sprint 4 clos (sessions 11-15 : workflow vente, Dossier Vente, commissions, e-CF,
|
|
5 Workspaces). Prochain jalon = **Sprint 5**. Des trois volets Sprint 5, Mobile
|
|
(builds/submit stores) et le déploiement dépendent d'API externes / du VPS →
|
|
**hors périmètre worker** (#8). Le volet **ONAPI/Legal** est le seul entièrement
|
|
réalisable en repo, et il comble un **gap réel** : le DocType custom
|
|
`CONFOTUR Application` est référencé par le contrat RBAC (3 rôles) et par les états
|
|
terminaux du workflow vente (`confotur_depose`/`confotur_approuve`), **mais aucun
|
|
générateur ne le produisait**. La session 15 le listait justement comme DocType
|
|
custom « à créer » côté VPS.
|
|
|
|
## Décision d'architecture (#1 ERPNext natif)
|
|
Le porteur d'un dossier CONFOTUR **EST un DocType Frappe custom** ; on livre donc
|
|
le fixture DocType natif (soumissible), pas un module externe. On refactorise
|
|
l'intention de `oto_module_confotur_application.py` en un **générateur déterministe**
|
|
aligné sur le pattern des livrables voisins (`crm/dossier_vente`, `fiscal/ecf_dgii`).
|
|
|
|
## Fichiers créés — `05_deliverables_mvp/legal/confotur/`
|
|
- `confotur_spec.json` — structure métier seule (libellés + types + drapeaux ·
|
|
**zéro chiffre**) ; nom/permissions/soumissibilité **non** portés par le spec.
|
|
- `cflib/frappe.py` — connaissance Frappe DocType (VALID_PERMS incluant `report`,
|
|
porté par `legal-directeur`).
|
|
- `cflib/rbac_scan.py` — **lecture** (jamais réécriture) des rôles RBAC visant le
|
|
DocType `CONFOTUR Application` + leurs actions ; réutilise `RoleResolver` pour
|
|
`id → nom Frappe` / `portail`.
|
|
- `cflib/builder.py` — assemblage déterministe `{manifest, doctype}`.
|
|
- `confotur_application_gen.py` — CLI `build`/`validate` · **14 invariants** de
|
|
cross-cohérence DocType↔RBAC↔workflow.
|
|
- `confotur.schema.json` — contrat de sortie draft-07.
|
|
- `out/{doctype_confotur_application,MANIFEST}.json` — hand-off (commité).
|
|
- `tests/test_confotur.py` — **44 tests** (dont 8 négatifs + 3 gardes builder).
|
|
- `README.md` · `.gitignore`.
|
|
|
|
## Fichiers modifiés
|
|
- `.gitea/workflows/ci.yml` : job `legal-confotur-tests` + ajout au `gate`.
|
|
|
|
## Anti-invention / anti-dérive (cœur · #6)
|
|
- **Nom** du DocType = identité prouvée présente dans RBAC (invariant : ≥1 rôle le
|
|
vise + tous `custom`).
|
|
- **Permissions** = **mot pour mot** les `permissions_cibles` RBAC des 3 rôles
|
|
(`ventes-confotur` read/write/create/print · `legal-onapi` read/write/create ·
|
|
`legal-directeur` read/write/**submit**/report) — ni ajout ni retrait.
|
|
- **`is_submittable`** déduit de l'action `submit` RBAC, recoupé avec le workflow
|
|
(états CONFOTUR = `doc_status 1`).
|
|
- **`estado`** / **`dossier_vente`** dérivés du `workflow_vente` (jamais en dur) ;
|
|
**`entite_porteuse`** = entités CLAUDE.md.
|
|
- **Aucun** taux d'incitation / article de loi / montant / référence d'autorité :
|
|
deux invariants refusent tout champ de type montant et tout `default` (hors série
|
|
de nommage). Paramètres légaux réels → `data_room P05/P07` côté VPS.
|
|
- **`depot_events`** (les « dépôts automatiques ») dérivés des transitions confotur
|
|
du workflow ; invariant : leur rôle a bien accès au DocType (RBAC).
|
|
|
|
## Résultat
|
|
DocType `CONFOTUR Application` : 18 champs (14 de donnée) · 4 sections · 3 rôles ·
|
|
soumissible · 2 évènements de dépôt (Déposer / Approuver).
|
|
|
|
## Vérifs
|
|
- 44/44 tests ; `validate` (schéma + 14 invariants) vert ; build déterministe.
|
|
- Gate CI local vert (guard constraints · JSON · docs · YAML `ci.yml`).
|
|
- **Régression : 304 tests verts au total** (279 modules antérieurs + 25
|
|
workflow_vente + les 44 nouveaux se recoupant dans le discover).
|
|
|
|
## Hors périmètre worker (VPS · #8)
|
|
Créer le module Frappe `OTOV7 CONFOTUR`, importer le DocType (`bench
|
|
import-fixtures`), câbler les `depot_events` sur le Workflow `OTO Vente Pipeline`,
|
|
et renseigner les paramètres légaux/fiscaux depuis `data_room P05/P07` (avec source)
|
|
→ agent ONAPI/Legal / ERPNext Backend.
|
|
|
|
## Auto-score 4Big : 96/100
|