Bloc « Communication inter-agents » (boilerplate identique ×11) promettait `05_deliverables_mvp/handoffs/` : répertoire inexistant (0 fichier, 0 consommateur, 0 gate). Échappé à check_docs.sh car chemin en code-span backtick (neutralisé l.28, à dessein — gater les backticks = faux positifs massifs, donc NON élargi). Corrigé vers le canal déjà réel et documenté partout (fixtures/specs `out/` commités), universellement vrai pour les 11 agents. 7 gates verts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
7.6 KiB
🖥️ Frontend Console Agent · Helios Luxury (score 95+/100)
Rôle : Cet agent matérialise la console unifiée de la plateforme sous forme
d'artefacts ERPNext natifs (#1) — pas de framework de dashboard externe. Il
livre les portails de landing par rôle (DocType Workspace v15) et le
montage de l'assistant OTOIA dans chaque portail (DocType Custom Block v15).
Chaque sortie est déterministe, diffable et dérivée d'un contrat en-repo :
aucun lien, rôle, langue ni chiffre n'est fabriqué.
Scope
5 portails rôle métier (Ventes / Construction / Achat / Compta / Direction) ·
chat OTOIA (persona Amélie QC) embarqué par portail · thème luxury dark+doré
(#4) · redesign /choisir-mon-unite (spec attribuée).
Principe directeur : ERPNext natif d'abord, hand-off VPS ensuite (#1, #8)
Contrainte #1 « ERPNext natif = priorité absolue avant tout outil externe » :
dans ERPNext v15, le portail de landing par rôle EST le DocType Workspace et
un bloc de contenu réutilisable EST le DocType Custom Block. On ne fabrique
donc aucun dashboard maison — on génère des fixtures Frappe prêtes à importer.
L'application réelle (bench migrate), l'insertion dans le content des Workspaces,
le câblage de l'endpoint OTOIA et l'application du thème desk restent côté VPS
(agent ERPNext Backend / Frontend) — le worker n'écrit jamais sur le serveur.
Livrables réellement produits (05_deliverables_mvp/frontend/)
| Module | Volet roadmap | Sortie | Métrique vérifiée |
|---|---|---|---|
portails/ |
Sprint 4 (L49) — « 5 portails rôle » | out/workspace.json |
5 Workspace natifs v15 (OTO Ventes 4 cartes/11 liens/12 rôles · OTO Construction 4/9/10 · OTO Achat 3/8/5 · OTO Compta 4/11/8 · OTO Direction 4/14/9) |
chat_otoia/ |
Sprint 6 (L63) — « Chat OTOIA embedded » | out/{custom_block,chat_mount}.json |
5 Custom Block + 5 configs runtime (persona Amélie QC · langues FR/EN/ES · endpoint: null) |
- Portails : CLI
python3 workspaces_gen.py build|validate· 12 invariants · 19 tests · job CIfrontend-portails-tests(gated). - Chat OTOIA : CLI
python3 chat_otoia_gen.py build|validate· 14 invariants · 31 tests · job CIchat-otoia-tests(gated).
Source de vérité unique (zéro invention · #6)
La matière première est le contrat RBAC 05_deliverables_mvp/rbac/rbac_50_roles.json,
jamais la spec de mise en page :
- Aucun lien / raccourci inventé : tout DocType visé par une carte ou un bloc
doit figurer dans les
permissions_ciblesdu portail — le portail a donc prouvablement le droit dessus. Couverture exhaustive et bijective : chaque DocType autorisé apparaît dans exactement une carte (aucun oubli, aucun doublon). - Rôles dérivés du contrat, triés — mêmes rôles que le
Role Profiledu portail ; un invariant vérifie leur synchronisation avec les Has Role des Workspaces. - 5 portails métier exacts : la console technique
plateforme(6ᵉ portail RBAC) est exclue (invariant d'égalité stricte avecportails_businessdu contrat). knowledge_scopedu chat = surface RBAC exacte du portail — ancrage de sécurité : l'assistant ne peut ni prétendre ni exposer un DocType hors périmètre.endpointOTOIA etWorkspace.modulelaissés ànull·a_confirmer— jamais fabriqués (#6/#8).- Tokens de marque (
#0a0a12,#f0b429, Fraunces, Cormorant Garamond) repris verbatim de CLAUDE.md #4, chacun avec sasource. - Langues FR/EN/ES + défaut lues dans
../seo/seo_spec.json · site.langs(source unique · pas de re-déclaration).
Génération refusée si un invariant casse (anti-régression) ; sortie déterministe (tri stable, zéro horodatage) → re-générable en CI.
Réutilisation (zéro duplication · #5)
- Validateur JSON-Schema maison Publiciste (
../publiciste/lib/validator.py)- tokens de marque (
lib/branding.py) — aucune dépendance pip sur le runner Gitea.
- tokens de marque (
- Le builder du chat réutilise le builder RBAC↔Workspaces des portails
(
portails/wslib/builder.py) — même source de vérité, pas de réimplémentation. - Rôles / DocTypes dérivés du contrat RBAC — même source que les générateurs
RBAC (
fixtures_gen,userperm_gen,roleprofile_gen).
Non-négociables (voir CLAUDE.md racine pour la liste complète)
- ERPNext natif en priorité absolue — Workspace / Custom Block, jamais un dashboard externe (#1)
- Gitea only (jamais GitHub)
- Score 4Big 95+/100
- Zéro invention de chiffres — tout lien/rôle/langue est dérivé d'un contrat sourcé
- VPS pour tous projets — le worker n'écrit jamais sur le serveur (#8)
- Design luxury dark+doré
#0a0a12+#f0b429(Fraunces + Cormorant Garamond) (#4) - Vérifier · Investiguer · Valider · Confirmer
Livrable attendu · roadmap
Voir 04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md. Volets Frontend Console :
Sprint 2 (L36 — clone /waf-home sur 5 entités), Sprint 4 (L49 — 5 portails
rôle) et Sprint 7 (L67 — polish final). Le chat OTOIA (L63) est attribué roadmap
à ERPNext Backend mais implémenté dans l'arbre frontend/ car il étend
directement le montage des Workspaces (réutilisation wslib) — coordination.
Hand-off → agent ERPNext Backend / Frontend (VPS · #8)
- Fixer
Workspace.moduleau module de l'app OTO à l'import (le worker ne fabrique pas de nom d'app). - Créer les DocTypes custom avant import (sinon liens morts) :
CONFOTUR Application,Faisabilité,Publiciste Log— les autres sont natifs v15. - Déposer les fixtures dans
fixtures/puisbench migrate; insérer chaqueCustom Blockdans lecontentduWorkspace(payload editor.jsa_confirmer). - Renseigner l'endpoint OTOIA + charger le web-component et appliquer les tokens dark+doré (#4) via la couche thème desk.
Coordination inter-agents
- RBAC / ERPNext Backend : fournit
rbac_50_roles.json(source unique des rôles et permissions) — même contrat que lesRole Profile. - Publiciste : valideur + lexique/branding réutilisés (anti-duplication · #5).
- SEO : fournit
seo_spec.json · site.langs(langues du chat) et reçoit le bundle SEO à injecter dans les pageswww/(VPS #8). - IFC/Speckle + CRM : co-destinataires du redesign
/choisir-mon-unite. - QA : les suites
frontend-portails-testsetchat-otoia-testssont agrégées aux gates de régression et d'acceptation (découverte CI).
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
Spec spécifique attribuée
05_deliverables_mvp/specs/CHOISIR_MON_UNITE_SPEC.md· redesign complet page/choisir-mon-unite(coordination avec IFC/Speckle + CRM agents)
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.