Files

T

Claude Code DTP Worker 75a3b0a471 [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>

2026-07-30 04:33:36 +00:00

5.7 KiB

Raw Blame History

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).

5.7 KiB Raw Blame History Unescape Escape