oto-enterprise-os-dtp/05_deliverables_mvp/frontend/chat_otoia/README.md

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 fixtures Custom 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 :

1. importe les fixtures Custom Block (bench) sous le module OTO ;
2. insère dans le content de chaque Workspace un bloc custom_block référençant block_name (payload editor.js a_confirmer selon patch v15) ;
3. 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.