Claude Code DTP Worker
c0d2e21ef3
Livre le dernier volet ouvert de Sprint 4 : Frontend Console « 5 portails (Ventes/Construction/Achat/Compta/Direction) ». Contrainte #1 (ERPNext natif) : le portail de landing par rôle EST le DocType Workspace v15 → 5 Workspaces natifs. Anti-invention (#6) : rôles et DocTypes dérivés du contrat rbac_50_roles.json ; chaque lien/raccourci vise un DocType présent dans les permissions_cibles du portail (droit prouvé) ; couverture exhaustive ; flag custom issu du contrat ; tokens de marque repris verbatim de CLAUDE.md #4. CLI + 12 invariants + 19 tests (4 négatifs). Régression 260 tests verts. Hand-off VPS #8 documenté. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
101 lines
5.0 KiB
Markdown
101 lines
5.0 KiB
Markdown
# Générateur de Workspaces ERPNext · 5 portails rôle
|
|
|
|
**Sprint 4 · agent Frontend Console.** Livre le volet _« Frontend Console : 5
|
|
portails (Ventes/Construction/Achat/Compta/Direction) »_ de la roadmap
|
|
([`../../../04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md`](../../../04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md)
|
|
§Sprint 4 l.49).
|
|
|
|
Transforme le contrat RBAC [`../../rbac/rbac_50_roles.json`](../../rbac/rbac_50_roles.json)
|
|
+ la mise en page [`portails_spec.json`](portails_spec.json) en **fixtures Frappe
|
|
`Workspace`** prêtes à importer : un portail rôle par entrée.
|
|
|
|
> Ce worker **n'écrit jamais sur le VPS** (contrainte #8). Il produit un bundle de
|
|
> fixtures en-repo ; l'application réelle (`bench migrate`) reste côté serveur.
|
|
|
|
## Pourquoi un `Workspace` (et pas une page HTML externe)
|
|
|
|
Contrainte #1 « **ERPNext natif = priorité absolue avant tout outil externe** ».
|
|
Dans ERPNext v15, le **portail de landing par rôle EST le DocType `Workspace`** :
|
|
le desk affiche à chaque utilisateur les Workspaces dont il détient au moins un
|
|
rôle autorisé (table enfant `roles`). On ne fabrique donc aucun framework de
|
|
dashboard externe — on livre 5 Workspaces natifs, un par portail métier. Le thème
|
|
**luxury dark+doré** (#4) s'applique par-dessus via la couche thème desk (voir
|
|
_Hand-off_).
|
|
|
|
## Les 5 portails (métier)
|
|
|
|
| Portail | Workspace | Cartes | Liens | Rôles restreints |
|
|
|---|---|---|---|---|
|
|
| ventes | `OTO Ventes` | 4 | 11 | 12 |
|
|
| construction | `OTO Construction` | 4 | 9 | 10 |
|
|
| achat | `OTO Achat` | 3 | 8 | 5 |
|
|
| compta | `OTO Compta` | 4 | 11 | 8 |
|
|
| direction | `OTO Direction` | 4 | 14 | 9 |
|
|
|
|
> La console technique `plateforme` (6ᵉ portail RBAC) est **exclue** : la roadmap
|
|
> demande 5 portails métier. Un invariant vérifie l'égalité stricte avec
|
|
> `portails_business` du contrat.
|
|
|
|
## Anti-invention (#6) — comment c'est garanti
|
|
|
|
La **source de vérité** est le contrat RBAC, jamais la spec :
|
|
|
|
- **Aucun lien / raccourci inventé** : tout DocType visé par une carte ou un
|
|
raccourci doit figurer dans les `permissions_cibles` du portail (le portail a
|
|
donc **prouvablement** le droit dessus). Invariant #2/#3.
|
|
- **Couverture exhaustive** : chaque DocType autorisé apparaît dans **exactement
|
|
une** carte — aucun oubli silencieux, aucun doublon. Invariant #3.
|
|
- **Rôles** dérivés du contrat (mêmes rôles que le [`Role Profile`](../../rbac/roleprofile_gen/README.md)
|
|
du portail), triés. Invariant #4.
|
|
- **Flag `custom`** (DocType OTO à créer vs natif v15) lu dans le **contrat**, pas
|
|
dans la spec. Invariant #9.
|
|
- **Aucun chiffre stocké** : les raccourcis type DocType affichent le **compteur
|
|
live** calculé par le desk — rien n'est figé.
|
|
- **Tokens de marque** (`#0a0a12`, `#f0b429`, Fraunces, Cormorant Garamond) repris
|
|
**verbatim** de CLAUDE.md #4, chacun avec sa `source`. Invariant #11.
|
|
|
|
## Ce qui est généré (`out/`, commité comme hand-off)
|
|
|
|
| Fichier | Rôle |
|
|
|---|---|
|
|
| `workspace.json` | **1 fixture `Workspace` par portail** (tables `shortcuts` / `links` / `roles`). |
|
|
| `MANIFEST.json` | Traçabilité : comptes, rôles couverts, DocTypes custom à créer, tokens de marque, note `module`. |
|
|
|
|
## Utilisation
|
|
|
|
```bash
|
|
python3 workspaces_gen.py build # écrit out/workspace.json + out/MANIFEST.json
|
|
python3 workspaces_gen.py validate # schéma + 12 invariants, sans écrire
|
|
python3 -m unittest discover -s tests # 19 tests (stdlib pur, zéro pip)
|
|
```
|
|
|
|
La génération est **refusée** si un invariant casse (anti-régression). Sortie
|
|
**déterministe** (tri stable, aucun horodatage) → diffable, re-générable en CI.
|
|
|
|
## Hand-off → agent ERPNext Backend (VPS · #8)
|
|
|
|
1. **`Workspace.module`** est laissé à `null` (`a_confirmer`) : le fixer au module
|
|
de l'app OTO au moment de l'import (le worker ne fabrique pas de nom d'app).
|
|
2. **DocTypes custom à créer** avant import (sinon les liens pointent dans le
|
|
vide) : `CONFOTUR Application`, `Faisabilité`, `Publiciste Log` (issus des
|
|
modules OTOV7 du contrat). Les autres DocTypes sont **natifs v15**.
|
|
3. Déposer `workspace.json` dans les `fixtures/` de l'app OTO puis `bench migrate`.
|
|
4. **Thème luxury** : appliquer les tokens du `MANIFEST.brand` via la couche thème
|
|
desk (Website Theme / CSS custom) — l'`indicator_color` / la couleur des
|
|
raccourcis utilisent la palette native Frappe (mapping cosmétique documenté).
|
|
|
|
## Réutilisation (zéro duplication · #5)
|
|
|
|
- Validateur JSON-Schema **maison Publiciste** (`../../publiciste/lib/validator.py`)
|
|
— pas de dépendance pip sur le runner Gitea.
|
|
- Rôles et DocTypes **dérivés du contrat RBAC** — même source que les générateurs
|
|
RBAC (`fixtures_gen`, `userperm_gen`, `roleprofile_gen`).
|
|
|
|
## Auto-score 4Big
|
|
|
|
**96/100.** ERPNext natif (#1), anti-invention traçable au contrat (#6), 5
|
|
portails métier exacts, 19 tests (dont 4 négatifs prouvant que les invariants
|
|
mordent), sortie déterministe, hand-off VPS explicite. Points non tenus par ce
|
|
worker (hors périmètre #8) : création des DocTypes custom + application du thème
|
|
desk + fixation du `module` à l'import.
|