4c741a7118
Un Explore adversarial a re-flagué (2e fois) la cellule « Sortie » du chat_otoia comme « manque MANIFEST.json » — faux positif connu (fiche-sortie-cell-omits-manifest- by-design) : les DEUX rangs (portails+chat) listent le payload seul, MANIFEST omis par convention, docstrings/READMEs énumèrent les 3 (byte-gatés). La récurrence prouve un footgun non documenté (brûle des cycles d'audit, risque un fix #5/#6 cassant le gate regex-parsé). Mitigation : blockquote « Note de lecture » après la table, rédigé pour éviter les regex ancrées du gate (aucun compteur cartes/liens/rôles ni **N tests**). check_readme_claims PASS · check_docs PASS · run_ci 33 PASS 0 FAIL 0 SKIP · 0 artefact reconstruit · 0 gate ajouté (#5) · 0 chiffre inventé (#6) · 0 commande VPS (#8) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
131 lines
8.1 KiB
Markdown
131 lines
8.1 KiB
Markdown
# 🖥️ 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/`](../../05_deliverables_mvp/frontend/portails/README.md) | 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/`](../../05_deliverables_mvp/frontend/chat_otoia/README.md) | 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 CI `frontend-portails-tests` (gated).
|
|
- **Chat OTOIA** : CLI `python3 chat_otoia_gen.py build|validate` · **14 invariants** ·
|
|
**31 tests** · job CI `chat-otoia-tests` (gated).
|
|
|
|
> **Note de lecture — colonne « Sortie ».** Les cellules listent le **payload
|
|
> métier** ; chaque générateur écrit **en plus** un `out/MANIFEST.json` (compteurs
|
|
> auto-vérifiés) **volontairement omis** de la table par convention éditoriale.
|
|
> L'énumération exhaustive des trois fichiers vit dans les docstrings et READMEs
|
|
> de module (byte-gatés). Ne PAS ajouter le MANIFEST à cette cellule : elle est
|
|
> lue par regex par `ci/check_readme_claims.sh` (compteurs `cartes/liens/rôles`,
|
|
> comptes de tests) et l'omission est intentionnelle, pas une dérive.
|
|
|
|
## 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_cibles` du 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 Profile` du
|
|
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 avec `portails_business` du contrat).
|
|
- **`knowledge_scope`** du 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.
|
|
- **`endpoint` OTOIA** et **`Workspace.module`** laissé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 sa `source`.
|
|
- **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.
|
|
- 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)
|
|
1. Fixer `Workspace.module` au module de l'app OTO à l'import (le worker ne fabrique
|
|
pas de nom d'app).
|
|
2. Créer les **DocTypes custom** avant import (sinon liens morts) : `CONFOTUR
|
|
Application`, `Faisabilité`, `Publiciste Log` — les autres sont natifs v15.
|
|
3. Déposer les fixtures dans `fixtures/` puis `bench migrate` ; insérer chaque
|
|
`Custom Block` dans le `content` du `Workspace` (payload editor.js `a_confirmer`).
|
|
4. 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 les `Role 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 pages `www/` (VPS #8).
|
|
- **IFC/Speckle + CRM** : co-destinataires du redesign `/choisir-mon-unite`.
|
|
- **QA** : les suites `frontend-portails-tests` et `chat-otoia-tests` sont 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.
|