From c18be84e8a1333d18839f921196b96aecdede90e Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 24 Aug 2026 10:04:04 +0000 Subject: [PATCH] docs(adr-0056): reconcile Consequences with the P2/P4 pure model MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two bullets in ADR-0056's Consequences still described the original Option B (capabilities editable in Setup as an exception), contradicting P2, P4, and Decision 3/4 of the same file: - "Capabilities are authored once, in Setup, through the `sys_capability` picker" — P2 says capabilities are designed in the structured editor, "not authored in Setup", and the code agrees: the picker (CapabilityMultiSelectField) is rendered by Studio's PermissionMatrixEditor, while Setup stamps the read-only `permission-facet-link` widget on all six facets including `system_permissions`. - "hence P2 keeps that grant in Setup and first-class", preceded by "an admin who ... lacks `studio.access` can no longer *design* them" — Decision 1/3 and A2 (revised) settle the opposite: the same editor has two entry points, and Setup's env-scope metadata route runs under `setup.access`, which is what dissolves the bootstrap knot. Prose only; no code, no schema, no other file. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01CSoz9uGhaaSgiq3hshtN7L --- docs/adr/0056-permission-editing-studio.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/docs/adr/0056-permission-editing-studio.md b/docs/adr/0056-permission-editing-studio.md index 070cbee1c0..b118c3f4af 100644 --- a/docs/adr/0056-permission-editing-studio.md +++ b/docs/adr/0056-permission-editing-studio.md @@ -222,8 +222,9 @@ change framework source). - **One authoring path per concern.** Objects/fields/RLS/tabs/admin-scope are authored once, in Studio, through validated editors the explain engine (D6) - and publish linter (D7) can see. Capabilities are authored once, in Setup, - through the `sys_capability` picker. + and publish linter (D7) can see. Capabilities are designed once, in Studio, + through the `sys_capability` picker (P2); Setup only assigns permission sets + to users (P1b) and shows every facet read-only (P1). - **The Setup/Studio audience split (ADR-0084 / studio.app) is honored:** operators assign and grant-entry; makers design permissions. - **AI-authoring safety improves** exactly where ADR-0090 wants it: no security @@ -240,10 +241,15 @@ change framework source). summary reads — so Studio edits aren't reflected in Setup until the projection refreshes. Display-freshness only (enforcement reads the authoritative metadata), but it needs a framework-side fix to close the loop. -- **Studio becomes load-bearing for permission ops.** An admin who can assign - sets but lacks `studio.access` can no longer *design* them. That is the - intended boundary, but it makes "who holds `studio.access`" operationally - important — hence P2 keeps that grant in Setup and first-class. +- **The structured editor becomes load-bearing for permission ops.** Designing a + set now means opening the permission matrix editor; no facet can be authored + from the record's own fields any more. The same editor has two entry points + (Decision 1) — the package-scoped Studio Access pillar (`studio.access`) and + Setup's own env-scope metadata route (`setup.access`) — so an operator who + lacks `studio.access` can still design a set at environment scope, including + granting `studio.access` itself. That is what dissolves the bootstrap knot A2 + worried about, and why P2 puts the capability picker in the structured editor + instead of keeping a Setup exception (Decision 3). ## Open design questions