Files
oto-enterprise-os-dtp/05_activity_log/2026-08-01.md
T
Claude Code DTP Worker 37903685c0 [DTP-Worker] Sprint 8 · buffer · RBAC/userperm_gen : la TABLE « Mapping scope_donnees → mécanisme » — la FONCTION d'enforcement ROW-LEVEL (quel mécanisme Frappe natif applique CHAQUE portée + si un User Permission template est émis), CŒUR sécurité du module — était transcrite EN PROSE (README:33-38) SANS AUCUN gate d'IDENTITÉ. Le bloc RBAC « 3 volets » ne gate QUE la ventilation par mécanisme (« 28/16/2/4 »), aveugle à QUEL mécanisme applique QUELLE portée.
Gate ajouté (check_readme_claims.sh) : par portée le mechanism (1er token backtické) + le verdict « Template émis ? » recomputés de out/user_permission_plan.json byte-gaté, exacts ; identité d'ensemble portées table == portées artefact (ni fantôme ni manquante) ; cohérences croisées : chaque portée mappe UN SEUL mécanisme (fonction) · verdict uniforme par portée · template émis SSI user_permission_company (invariant « template SSI entite »).

7 morsures vérifiées (README réaffecte entite→none_consolidated = row-level enforcement abandonné · bascule verdict oui→non · échange portée = fantôme+manquant · retrait ligne · table supprimée · artefact réaffecte entite · artefact non-uniforme casse SSI) ; restauré = green · exit 0. Working tree byte-restauré (git checkout --, JAMAIS git clean) · 7 gates re-verts. ci/README.md (récap + détail 2e surface userperm_gen) mis à jour.
2026-08-01 00:10:13 +00:00

4.8 KiB

Activity Log · 2026-08-01 · Claude Code DTP

Session 20260801_000201 · Buffer S8 · Domaine RBAC/userperm_gen : la table « Mapping scope_donnees → mécanisme » — la FONCTION d'enforcement ROW-LEVEL (quel mécanisme Frappe natif applique CHAQUE portée de données + si un User Permission template est émis), CŒUR sécurité du module — était transcrite EN PROSE (README:33-38) SANS AUCUN gate d'IDENTITÉ. Le bloc RBAC « 3 volets » existant ne gate QUE la ventilation par mécanisme (« 28 entite · 16 groupe · 2 own · 4 equipe »), un COMPTE aveugle à QUEL mécanisme applique QUELLE portée.

Tâche : Sprint 8 · buffer (DevOps CI/CD · QA). Roadmap fonctionnellement close ; poursuite de la série anti-dérive (CLAUDE.md #6). Même patron d'IDENTITÉ que le mapping RBAC fixtures_gen (séparation des pouvoirs set_user_permissions) ou la cross-cohérence PERMISSIONS Legal/CONFOTUR (role_id→actions) — appliqué à la surface data-derived distincte du même README rbac/userperm_gen : la table qui associe chaque portée de données à son mécanisme d'enforcement, jamais gatée hors son compte agrégé.

Dérive silencieuse fermée :

  • 05_deliverables_mvp/rbac/userperm_gen/README.md:33-38 — table « Mapping scope_donnees → mécanisme » : nomme, PAR portée, le mechanism Frappe natif (owndocperm_if_owner · entiteuser_permission_company · groupenone_consolidated · equipevps_confirm_team) ET le verdict « Template émis ? » (oui pour entite seul, sinon non (null)).
  • Source faisant autorité (byte-gatée par check_artifacts) : out/user_permission_plan.json — chaque entrée porte scope_donnees + mechanism + user_permission_template (null ou objet). Le mapping est une fonction : chaque portée → exactement un mécanisme ; template émis SSI entite/user_permission_company.
  • Piège : le bloc de ventilation est AVEUGLE à l'identité de ces couples. RÉAFFECTER une portée à un mécanisme plus permissif (entitenone_consolidated : le row-level enforcement ABANDONNÉ, sur-exposition des données inter-entités — la restriction même que le module pose), RENOMMER un mécanisme ou BASCULER le verdict « Template émis ? » laisse le README périmé pendant que l'artefact dit autre chose → l'agent ERPNext Backend câblerait le mauvais mécanisme (le risque même que la table veut prévenir). Aucune suite tests/ (qui teste des FONCTIONS de mapping/résolution, pas la prose) n'attrape ce « vert trompeur ».
  • État courant : aucune ligne périmée — les 4 couples portée→mécanisme et leurs verdicts recoupent l'artefact exactement (anti-invention #6, rien à réécrire). Le défaut est la surface ungated.

Gate ajouté (ci/check_readme_claims.sh, nouveau bloc « RBAC/userperm_gen Mapping » après le bloc CRM gardes) : (1) par portée — le mechanism (1er token backtické de la colonne) ET le verdict « Template émis ? » (**oui** / non (null)) recomputés de user_permission_plan.json, prose exigée EXACTE ; (2) identité d'ensemble — portées de la table == portées de l'artefact (set-diff : ni fantôme ni manquante). Cohérences croisées en bonus (mordent un plan INTERNEMENT incohérent) : chaque portée mappe UN SEUL mécanisme (fonction, pas relation) · « Template émis » UNIFORME sur les entrées d'une portée · template émis EXACTEMENT pour user_permission_company (l'invariant « template SSI entite » du README:36/61) · ensemble des portées NON VIDE. Un claim absent échoue AUSSI (traçabilité).

7 morsures vérifiées : README réaffecte entitenone_consolidated (mécanisme périmé · élévation de portée) · README bascule entite « Template émis » oui→non (verdict périmé) · README échange une portée groupefamille (absents=[groupe] + en trop=[famille] + ligne INTROUVABLE) · README retire la ligne own (absents=[own]) · table entière supprimée (les 4 absents + toutes lignes INTROUVABLES) · artefact réaffecte toutes les entrées entitenone_consolidated (README périmé sur mécanisme ET verdict) · artefact rend une entrée own porteuse d'un template (« Template émis » NON uniforme [False,True] · invariant SSI cassé) ; restauré = green : 4 portées · table == artefact · par-ligne exact · fonction/uniforme/SSI verts · exit 0. Working tree byte-restauré (git checkout --, JAMAIS git clean) · 7 gates re-verts.

  • ci/README.md (table récap du pipeline + paragraphe détaillé « 2ᵉ surface rbac/userperm_gen ») mis à jour.
  • Hors périmètre worker (VPS · #8) : néant (gate bash/python3 stdlib en-repo ; édition hors 05_deliverables_mvp/*/out ⇒ 0 dérive d'artefact).
  • Auto-score 4Big : 96/100.