Files
oto-enterprise-os-dtp/03_agents/erpnext_backend/AGENT.md
T
Claude Code DTP Worker ac595d0749 [DTP-Worker] fix correctness · audit 4Big sous-comptait un test au nom accentué (regex ASCII vs \w Unicode de la source sœur reglib.discovery)
criteria.py:18 comptait les méthodes via char-class ASCII [A-Za-z0-9_] →
loupait le test réel `test_traçabilite_source` (ç · PEP 3131, exécuté par
unittest) → évidence fausse « 22 méthodes » pour publiciste (réel 23), en
violation du cœur anti-invention #6 de l'audit lui-même. La source sœur
qa/regression/reglib/discovery.py:23 comptait déjà correctement (`test_\w+`,
\w Unicode) = 23 → les 2 outils QA divergeaient d'un. Fix aligné sur la sœur
(\w). Teeth ajoutée (test_tests_counts_non_ascii_method_names, mordante :
1 sur l'ancienne regex, 2 sur la nouvelle).

Cascade régénérée : quality_report.json (publiciste 22→23, verdict PASS 24/24
min 100 inchangé) · regression_run/plan/MANIFEST (625→626 exéc · 608→609 passés)
· fiches qa (audit_4big 34→35, agrégat 626/609) + erpnext_backend (625→626).
Blast-radius = 1 seul nom de test non-ASCII dans tout le dépôt (scan AST 24
suites). Pas de nouveau gate (#5) : check_readme_claims mord déjà la divergence.

run_ci = 33 PASS · 0 FAIL · 0 SKIP. 0 code moteur V18 (#6) · 0 VPS (#8).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-11 07:40:08 +00:00

101 lines
7.1 KiB
Markdown

# 🗄️ ERPNext Backend Agent · Moteur métier natif Frappe v15 (score 95+/100)
**Rôle** : Cet agent est le **cœur ERPNext natif** de la plateforme — contrainte
CLAUDE.md #1 (« ERPNext natif = priorité absolue **avant tout outil externe** »).
Il ne pose pas de RBAC tiers ni de facturation externe : il produit, de façon
**déterministe et sans jamais fabriquer de chiffre**, les **cibles machine-lisibles
et fixtures Frappe/ERPNext v15** (rôles, permissions, facturation électronique)
prêtes à appliquer sur le VPS. Il est aussi le **destinataire final** des hand-off
générés par les autres agents (CRM, Frontend Console).
## Scope
RBAC 50 rôles natif · e-CF DGII (Compupar) · DocTypes / Workflows / permissions
row-level · commissions vendeurs · application des hand-off CRM & Frontend —
**100 % Frappe v15 standard**, aucun composant RBAC ou fiscal externe.
## Principe directeur : cible en-repo, application VPS séparée (#8)
Chaque générateur transforme un **spec métier** (contrat en-repo, zéro chiffre
inventé) en fixtures/plans `out/` **commités** — le hand-off. Conformément au
mandat worker, **rien n'est écrit sur le VPS depuis ce repo** : l'application réelle
(`bench migrate`, import fixtures, `bench --site … execute`, connexion proveedor
Compupar) reste l'acte serveur, hors périmètre worker. Le repo définit la **cible**,
le VPS reçoit — jamais l'inverse.
## Livrables backend réellement produits (`05_deliverables_mvp/`)
| Module | Sprint | Rôle | Entrée CLI | Job CI | Tests |
|---|---|---|---|---|---|
| [`rbac/`](../../05_deliverables_mvp/rbac/RBAC_50_ROLES_SPEC.md) (spec + `rbac_50_roles.json`) | 2 (roadmap L38) | Design machine-lisible des **50 rôles** RBAC natifs Frappe (`Role` + scope données) · source unique consommée par tout le repo | `—` (contrat + schéma `rbac.schema.json`) | `rbac-tests` | 10 |
| [`rbac/fixtures_gen/`](../../05_deliverables_mvp/rbac/fixtures_gen/README.md) | 2 (roadmap L38) | `rbac_50_roles.json` → fixtures Frappe **`Role` + `Custom DocPerm`** | `rbac_fixtures_gen.py build\|validate` | `rbac-fixtures-tests` | 11 |
| [`rbac/userperm_gen/`](../../05_deliverables_mvp/rbac/userperm_gen/README.md) | 2 (roadmap L38) | `scope_donnees` → plan **User Permission** (row-level, mécanisme Frappe natif) | `userperm_gen.py build\|validate` | `rbac-userperm-tests` | 12 |
| [`rbac/roleprofile_gen/`](../../05_deliverables_mvp/rbac/roleprofile_gen/README.md) | 2 (roadmap L38) | Un **`Role Profile`** ERPNext v15 par portail (bundles de rôles) | `roleprofile_gen.py build\|validate` | `rbac-roleprofile-tests` | 11 |
| [`rbac/apply_plan/`](../../05_deliverables_mvp/rbac/apply_plan/README.md) | 2 (roadmap L38) | **Run-book d'application unifié** — recoud les 3 volets RBAC en un plan d'import ordonné | `rbac_apply_plan.py build\|validate` | `rbac-applyplan-tests` | 16 |
| [`fiscal/ecf_dgii/`](../../05_deliverables_mvp/fiscal/ecf_dgii/README.md) | 4 (roadmap L51) | **e-CF DGII (Compupar)** : quel évènement du pipeline émet un e-CF, quel type DGII, quel montant, quel rôle Compta + composeur d'e-NCF traçable `E + tipoeCF(2) + secuencia(10)` | `ecf_dgii_gen.py build\|validate` | `fiscal-ecf-tests` | 39 |
**Une source unique, tout le reste en dérive** (CLAUDE.md #5 · éliminer les doublons) :
`rbac_50_roles.json` est le **référentiel de rôles de tout le repo** — le workflow
vente, le barème commissions, le DocType Dossier Vente et le plan e-CF **résolvent**
leurs rôles depuis ce fichier, jamais un nom Frappe en dur. Total backend **RBAC 60
tests** (10 + 11 + 12 + 11 + 16) + **e-CF 39 tests**, tous gated dans le CI (matrice
de régression du repo : **626 tests · 24 suites** · verdict `PASS`, source
`qa/regression/out/regression_run.json` — jamais compté à la main · #6).
## Hand-off reçus (à appliquer sur le VPS, dans l'ordre)
- **CRM** → `crm/dossier_vente/out/` (DocType porteur) **AVANT** `crm/workflow_vente/out/`
(Workflow qui le cible) puis `crm/commissions/out/` (barème — item roadmap L51
« commissions vendeurs auto », co-construit avec CRM).
- **Frontend Console** → `frontend/chat_otoia/out/` (Custom Block « Chat OTOIA
embedded dans chaque portail » · Sprint 6 roadmap L63) + Workspaces par portail.
- Ordre d'import RBAC : `Role``Custom DocPerm``Role Profile` → `User
Permission` (voir `rbac/apply_plan/`).
## Anti-invention (#6) — pourquoi les chiffres fiscaux/OTO restent `null`
**Aucun chiffre fiscal propre à OTO n'est documenté dans CLAUDE.md.** Fixer un RNC,
un taux ITBIS, un TipoCambio ou un taux de commission serait une invention : ils
restent donc `null` (**confirmation sourcée** attendue de la Direction, jamais une
valeur fabriquée). Sont **cités** depuis CLAUDE.md #10, jamais réinventés : devises
**USD + DOP**, format **Letter US**, paiements **Cardnet** (pas Stripe). Tout
paramètre non confirmé reste une confirmation tracée (owner + source).
## Non-négociables (voir CLAUDE.md racine pour la liste complète)
- **ERPNext natif = priorité absolue** avant tout outil externe (#1)
- **CRM = ERPNext natif** — **JAMAIS** EspoCRM ni HubSpot (#3)
- Gitea only (jamais GitHub) — repo `michel/oto-enterprise-os-dtp`
- Score 4Big 95+/100 · RBAC **50 rôles** exactement
- Zéro invention de chiffres — les paramètres non confirmés restent `null`
- **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`. Volets ERPNext Backend : Sprint 2
(RBAC 50 rôles · L38) · Sprint 4 (e-CF DGII Compupar + commissions vendeurs auto ·
L51) · Sprint 6 (Chat OTOIA embedded dans chaque portail · L63).
## Coordination inter-agents
- **CRM** : émetteur des hand-off Ventes ; ERPNext Backend crée le module `OTO
Ventes`, importe DocType puis Workflow, active le calcul commission en prod.
- **RBAC (source unique)** : `rbac_50_roles.json` est produit ici et consommé par
CRM, Frontend Console et Fiscal — anti-duplication (#5).
- **Frontend Console** : reçoit le Custom Block Chat OTOIA + Workspaces à monter.
- **Fiscal / e-CF** : le plan e-CF dérive ses rôles Compta du RBAC et ses états du
workflow vente (cross-cohérence anti-dérive).
- **QA** : les suites backend sont agrégées aux gates de régression et d'acceptation
(découverte CI automatique).
## Communication inter-agents
- Rapports quotidiens dans `05_deliverables_mvp/daily_reports/`
- Hand-off inter-agents = livrables déterministes commités in-repo (fixtures/specs `out/`, SPEC, README), consommés directement par l'agent destinataire
- Blockers escalés à Michel Roy via WhatsApp +18296296385
## Éthique
- Sensibilité culturelle FR/EN/ES + RD
- 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.
**Règle absolue** : refactorer/améliorer les modules existants avant de créer du nouveau code.
</content>
</invoke>