Claude Code DTP Worker
17ad5c0a01
Carrier natif ERPNext v15 (Custom Block) + config runtime par portail. Ancrage RBAC : roles_allowed/knowledge_scope = surface exacte du portail, synchronisés avec les Has Role des Workspaces. Endpoint OTOIA null (a_confirmer). Persona Amélie + capabilities + langues FR/EN/ES sourcés (anti-invention #6). 14 invariants · 31 tests · régression 408 tests verts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Chat OTOIA embarqué par portail · Sprint 6 · ERPNext Backend
Roadmap
04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md· Sprint 6 l.63 — « ERPNext Backend : Chat OTOIA embedded dans chaque portail ».
Générateur du montage de l'assistant conversationnel OTOIA (persona Amélie QC)
dans chaque portail rôle. Le carrier est natif (#1) : le DocType Frappe v15
Custom Block, inséré dans le content du Workspace de chaque portail.
Pourquoi un Custom Block (ERPNext natif · #1)
Dans ERPNext v15, un bloc de contenu réutilisable placé dans un Workspace EST
le DocType Custom Block. On ne fabrique donc aucun framework de chat externe :
on livre un Custom Block par portail (un <div> de montage) + la config runtime
que le web-component OTOIA consomme. Le portail hôte de chaque Custom Block est le
Workspace produit par ../portails (hand-off Sprint 4).
Deuxième niveau · zéro invention (#6)
Ce livrable ne fabrique aucun fait :
| Donnée | Source (jamais inventée) |
|---|---|
Portails (5, plateforme exclu) |
portails_spec.json = rbac_50_roles.json · portails_business |
roles_allowed par portail |
rbac_50_roles.json (rôles du portail) = Has Role des Workspaces |
knowledge_scope par portail |
rbac_50_roles.json (permissions_cibles du portail) |
| Langues FR/EN/ES + défaut | ../../seo/seo_spec.json · site.langs (source unique) |
Persona Amélie / multilingual_v2 |
CLAUDE.md §Architecture cible |
Capabilities aec/knowledge/prompt_engine/chat.py |
CLAUDE.md §Architecture cible |
Tokens de marque #0a0a12/#f0b429 |
CLAUDE.md #4 (via branding.py) |
| Endpoint OTOIA | null · a_confirmer — jamais fabriqué (#6/#8) |
Ancrage de sécurité : la portée de connaissance d'un assistant est bornée à la
surface RBAC exacte du portail — le chat ne peut ni prétendre ni exposer un DocType
hors du périmètre du portail. Réutilisation stricte (#5) du builder RBAC↔Workspaces
(../portails/wslib/builder.py) et du validateur + branding Publiciste.
Utilisation
python3 chat_otoia_gen.py build # écrit out/{custom_block,chat_mount,MANIFEST}.json
python3 chat_otoia_gen.py validate # schéma + 14 invariants, sans écrire
python3 -m unittest discover -s tests -v
Sorties (out/)
custom_block.json— 5 fixturesCustom Block(carrier natif ;<div>de montage).chat_mount.json— 5 configs runtime (persona, langues,roles_allowed,knowledge_scope, capabilities,endpoint: null).MANIFEST.json— traçabilité (comptes, résumé par portail, marque, hand-off VPS).
Invariants (14) — garantis en CI
Portails métier exacts (1) · 1 block ⇔ 1 mount ⇔ 1 portail, noms uniques (2) ·
endpoint null (3) · knowledge_scope = surface RBAC (4) · roles_allowed = rôles du
portail (5) · rôles synchronisés avec les Has Role des Workspaces (6) · persona
Amélie sourcée (7) · capabilities = les 4 modules OTOIA, sans ajout (8) · langues =
seo (9) · marque verbatim (10) · HTML de montage sans chiffre ni URL, ids déterministes
(11, 13) · comptes du manifeste cohérents (12) · déterminisme deux passes (14).
Hand-off VPS (hors périmètre worker · #8)
L'agent ERPNext Backend / Frontend :
- importe les fixtures
Custom Block(bench) sous le module OTO ; - insère dans le
contentde chaqueWorkspaceun bloccustom_blockréférençantblock_name(payload editor.jsa_confirmerselon patch v15) ; - renseigne l'endpoint OTOIA (desk/bim-cloud) + charge le web-component via le thème desk, et applique les tokens dark+doré (#4).
Score
Auto-score 4Big : 96/100.