michel/oto-enterprise-os-dtp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ac595d0749e176d84a3cf173aad42b02f9890b51
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

7.1 KiB
Raw Blame History

🗄️ 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/ (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/ 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/ 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/ 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/ 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/ 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.

Reference in New Issue View Git Blame Copy Permalink