[DTP-Worker] Sprint 2 · Agrégateur RBAC : run-book d'application VPS unifié (3 volets → 1 plan ordonné SPEC §7)

Clôt le volet RBAC en-repo : recoud fixtures Role+DocPerm, plan User Permission
et Role Profile en un run-book ordonné + manifeste agrégé. Zéro chiffre
recalculé (tout vient d'un manifeste source, #6), graphe de dépendances validé
(Role avant Role Profile), cohérence inter-volets + couverture bijective 50/50.
16 tests + job CI rbac-applyplan-tests · 99 tests de régression au total.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

05_deliverables_mvp/daily_reports/2026-07-30-session9.md

@@ -0,0 +1,93 @@
+# Daily Report · 2026-07-30 · Claude Code DTP Worker (session 9)
+
+**Session** : `20260730_042654`
+
+## Tâche exécutée
+**Sprint 2 · Livrable ERPNext Backend « Agrégateur RBAC : run-book d'application
+VPS unifié (3 volets → 1 plan ordonné) »**
+(roadmap `04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md` §Sprint 2 « RBAC 50 rôles » ·
+`RBAC_50_ROLES_SPEC.md` §7 · **prochaine tâche suggérée** par le daily report
+session 8 : « agrégateur MANIFEST unifié Role + DocPerm + User Permission +
+Role Profile pour clore le volet RBAC »).
+
+## Contexte / analyse
+- Relu `CLAUDE.md`, `ROADMAP_8_WEEKS_OR_LESS.md`, daily reports sessions 7 et 8,
+  `rbac_50_roles.json`, les **trois générateurs RBAC** livrés (`fixtures_gen`,
+  `userperm_gen`, `roleprofile_gen`) + leurs manifestes, le validateur maison
+  Publiciste, le patron CI, la SPEC §7.
+- État Sprint 2 : contrat RBAC (s4), Publiciste (s3), Faisabilité (s5), fixtures
+  `Role`+`Custom DocPerm` (s6), plan `User Permission` (s7), `Role Profile` (s8)
+  livrés. Frontend/CRM dépendent de layouts LIVE (VPS) → hors périmètre worker.
+- **Priorité évidente** (report s8 + SPEC §7) : les 3 volets existent mais l'ordre
+  d'application restait **implicite**. Or il porte des contraintes ERPNext dures
+  (Role importé AVANT Role Profile) et des confirmations préalables dispersées
+  dans 3 manifestes. Le maillon manquant = la **vue d'ensemble** : un run-book
+  ordonné + un manifeste agrégé. 100 % autorable sans VPS/pip/API, même patron
+  que les 3 générateurs, clôt le volet RBAC en-repo.
+
+## Réalisé — module `05_deliverables_mvp/rbac/apply_plan/`
+- `applylib/aggregator.py` — **agrège sans rien recalculer** : appelle les 3
+  builders (`fixtures_builder.build_bundle`, `userperm_builder.build_plan`,
+  `roleprofile_builder.build_bundle`), recoupe la cohérence (même contrat / même
+  version / même cible 50 → `_require_same` lève sur mélange), fusionne les
+  confirmations VPS, et produit le **run-book des 6 étapes SPEC §7** (responsable
+  worker/vps, statut, commande worker, artefacts, `depends_on`, confirmations,
+  lien doc). Ordre + dépendances = savoir procédural documenté, pas des chiffres.
+- `rbac_apply_plan.py` — CLI `build` / `validate`. **Refuse d'écrire** si un
+  invariant casse : couverture SPEC §7 exacte + `order` séquentiel, graphe de
+  dépendances (aucune arête en avant, aucun renvoi fantôme), Role Profile **après**
+  fixtures Role, confirmations ni orphelines ni fantômes, cohérence inter-volets,
+  **couverture bijective** (Role == 50 == entrées UP == rôles couverts profils),
+  listes triées.
+- `apply_plan.schema.json` — contrat de sortie draft-07 (sous-ensemble supporté
+  par le **validateur maison Publiciste**, zéro pip · `commande` nullable via
+  type-array `["string","null"]`).
+- `tests/test_apply_plan.py` — **16 tests `unittest` (stdlib pur)** : schéma
+  (maison + oracle `jsonschema`), fidélité des comptes aux manifestes source,
+  fusion des confirmations, ordre + graphe SPEC §7, Role avant Role Profile,
+  garde-fous de cohérence (rejet version/cible discordantes), déterminisme,
+  détection d'invariants cassés.
+- **CI** : job `rbac-applyplan-tests` ajouté au **gate** de
+  `.gitea/workflows/ci.yml` (Gitea Actions uniquement · #2).
+- `README.md` + `.gitignore` (output `out/` non commité, re-généré à la demande).
+- **Docs cousues** : `RBAC_50_ROLES_SPEC.md §7` (préambule pointe le run-book
+  consolidé + nouveau ✅ encart livré).
+
+## Anti-invention (#6) appliqué
+- **Zéro chiffre recalculé** : chaque compte du manifeste agrégé provient du
+  manifeste d'un builder source (vérifié par `test_counts_come_from_source_manifests`).
+- Chaque item « à confirmer VPS » (DocType custom / Company / rôles `equipe`) est
+  **repris tel quel** des manifestes d'origine, juste trié et fusionné.
+- L'ordre des étapes et le graphe de dépendances encodent des **contraintes
+  ERPNext v15 documentées** (SPEC §7), pas des décisions fabriquées.
+- Un mélange de volets (versions de contrat différentes) est **refusé**, jamais
+  silencieusement concilié.
+
+## Vérifications effectuées (en-repo, sans toucher au VPS)
+- **16/16 tests verts** (schéma maison + oracle `jsonschema`). Génération réelle :
+  **6 étapes**, comptes agrégés 50 rôles / 116 DocPerm / 45 DocTypes / 28 UP
+  templates / 6 Role Profile ; confirmations VPS = 4 DocType custom + 5 Company +
+  4 rôles `equipe` ; **couverture bijective 50/50 recoupée sur les 3 volets**.
+- **Gate CI local vert (exit 0)** : `guard_constraints.sh`, `validate_json.sh`,
+  `check_docs.sh` (0 lien cassé, mention score présente), YAML `ci.yml` valide.
+- **Régression** : 23 Publiciste + 10 RBAC + 11 fixtures + 12 userperm + 11
+  roleprofile + 16 apply_plan + 16 Faisabilité = **99 tests verts**.
+
+## Non fait (hors périmètre worker · VPS)
+- Exécution réelle du run-book (`bench migrate`, création DocTypes custom,
+  affectation `role_profile_name`, matérialisation `User Permission` par
+  utilisateur) → agent ERPNext Backend (SPEC §7 ét. 2/3/4/5/6).
+
+## Prochaine tâche suggérée
+- **Volet RBAC clos en-repo** (4 générateurs + run-book unifié). Suite logique :
+  Faisabilité S3 (`40_llm_outputs/` + rapports bancables FR/EN/ES) ; ou préparer
+  le hand-off ERPNext (packaging `fixtures/` de l'app OTO à partir des 4 sorties).
+- Frontend/CRM S2 : dépend des layouts LIVE (VPS) → hors périmètre worker.
+
+---
+
+**Auto-score 4Big du livrable Agrégateur RBAC (run-book) : 96/100.**
+Réserve −4 : l'exécution réelle du run-book reste côté VPS (agent ERPNext, hors
+périmètre worker, #8). Validé statiquement en-repo (16 tests verts + schéma
+conforme + recoupement bijectif des 3 volets + gate CI vert · 99 tests de
+régression au total).