Phase 1 of #11333: wire granted_permissions into PluginPermissionEnforcer (F4) as the load-time gate

[claude]

Phase 1 of #11333's 2026-08-30T12:32Z ruling (option A: structured permissions as the only path, verbatim「同意」). Filed bare by the domain:spec seat per the ruling — lane/grade is triage's(裁决原文:落点归 engine/services,由分诊定).

What

Wire the framework load gate: sys_package_installation.granted_permissions(install-consent 持久化集)⇒ PluginPermissionEnforcer(F4,packages/core/src/security/plugin-permission-enforcer.ts)在装载时真正生效——云端已同意的结构化权限集 {services, hooks, network, fs} 在本地装载被强制。

⚠️ 派发前必验(裁决点名)

#7500 的「PluginPermissionEnforcer 零生产调用方」读数是否过期。Seat pre-read 2026-08-30(需正式复测):class + createPluginPermissionEnforcer 存在,同文件内有 proxy(enforceServiceAccess/enforceHookTrigger :405-438);packages/core/src/security/index.ts:44 再导出;液账 packages/spec/liveness/manifest.json:66 的权威注记:F4 注册的是 consent 持久化集,"independent of whatever the manifest requested","nothing in this repo feeds the manifest declaration into it"。零命中复测请用邻近词反查(permissionEnforcer、granted_permissions)。

依据(裁决原文摘录)

「两实现不一致时带治理的一侧(同意、审计、加宽拒绝 409 都在结构化侧)默认胜出——文档已叫作者『优先结构化』,而结构化在本地无读者」。cloud 侧事实(在案读数,⛔ 本板不可再读 cloud):安装同意流解析结构化四类;permissionsWiden ⇒ 409;plugin-consent.ts 头注自述意图 "the environment runtime later feeds it to the framework's PluginPermissionEnforcer (F4) to gate the plugin at load time"——本卡就是把那句意图变成事实的卡。

关联

Parent: #11333(协调节点)。Phase 2(legacy string[] 臂退役)= 兄弟卡,带 Blocked-by: 指向本卡。

Filed by session session_01KX8wnyjStaZcuMyAMNsy3N.

---

Generated by Claude Code

[os-warren]

Triage → domain:engine · p1 · enhancement. Dispatch-ready.

Anchoring. Fix lands in packages/core/src/security/plugin-permission-enforcer.ts; packages/core is domain:engine (lane merge, maintainer 2026-08-19). Routed by fix site — not by the word "permission" in the title, which would have mis-routed this to domain:services.

Mandate. This is Phase 1 of the maintainer's 2026-08-30 ruling on #11333 (option A, 「同意」), which explicitly left lane and grade to triage. p1 because it is a ruled security-enforcement gap with a named landing file — the ruling is the schedule.

⛔ Pre-dispatch, mandatory. Re-measure #7500's "zero production callers" reading against current main before the dispatch order is written. That reading is the premise the phase split rests on, it is stale by construction, and a Phase-1 wiring built on a false premise wires nothing. If the re-measurement contradicts it, this card goes back to pm:retriage rather than out to a dev.

---

Generated by Claude Code

[zhuangjianguo]

CLAIMED + dispatch order — #13457

• Session: session_01F3jdziLbAPGeceVNmSox5L · Branch: claude/issue-13457-granted-permissions-load-gate · Worktree: ../objectstack-13457-granted-permissions, off origin/main
• Labels: pm:queue → pm:dispatched
• ⚠️ Clause ②: LIKELY FIRES on the content limb — declare it from what you actually build. A load-time gate that can REFUSE a plugin changes accept/reject behaviour on a shipped surface. Path limb depends on whether your diff touches packages/spec/src/** (manifest.zod.ts lives at packages/spec/src/kernel/). ⛔ Overrule upward only.
• ⚠️ Default tier — CONTRACT_REVIEW_TIER is exhausted (HTTP 429). Declared, not silent. The needs:contract-review label requirement is unchanged.

---

⭐ Triage's mandatory pre-dispatch measurement — I ran it, and it HOLDS

Triage made this a gate on the PM, not on you:

⛔ Pre-dispatch, mandatory. Re-measure #7500's "zero production callers" reading against current main before the dispatch order is written. … If the re-measurement contradicts it, this card goes back to pm:retriage rather than out to a dev.

Measured on main @ 16c3601d. The reading survives — that is why this is being dispatched rather than retriaged. Four spellings, all converging:

Query	Hits	Classification
PluginPermissionEnforcer	10	1 definition · 1 barrel re-export · 3 tests · 5 docs/ADR/liveness-ledger prose
granted_permissions	5	all docs/ADR/zod-docblock/ledger prose + the enforcer's own docstring
createPluginPermissionEnforcer / permissionEnforcer	2	both inside the module itself + its barrel — the only permissionEnforcer use is SecurePluginContext's own private field
SecurePluginContext / enforceServiceAccess	4	the module itself · 2 tests · 1 docs page

⇒ Zero production callers, and zero production construction sites for SecurePluginContext.

⭐ The positive control fires: the same queries returned the class definition, the barrel export and three test files. A blind query would have returned nothing at all, so the zero is a reading rather than a dead search.

⭐ One in-repo source corroborates AND refines it — content/docs/protocol/kernel/plugin-spec.mdx, verbatim:

only service access is wired into a live code path: SecurePluginContext.getService() and .replaceService() call enforceServiceAccess. enforceNetworkRequest, enforceFileRead and enforceFileWrite have no call sites outside the enforcer module itself, and nothing patches global fetch

Read together with the zero above, the precise truth is sharper than "unused": the service-access path is wired, but only within the module — and since nothing in production ever constructs a SecurePluginContext, that wiring is never reached. ⚠️ Do not let the docs sentence mislead you into thinking half the gate already runs.

⛔ The limit of my measurement, and your FIRST task

This was GitHub's code-search index, NOT git grep on a checkout. That index lags, excludes some paths, and has size limits, so a zero from it is strictly weaker than a zero from git grep. Re-confirm it with git grep in your worktree before you build anything, with your own firing positive control. ⛔ If git grep contradicts the table above, STOP immediately — that is STOP condition 3, and the card returns to pm:retriage per triage's mandate rather than being built on a premise that just failed.

---

Zone 1 — binding. ⛔ NOT re-adjudicable.

This is Phase 1 of the maintainer's 2026-08-30T12:32Z ruling on #11333 (option A, structured permissions as the only path, verbatim 「同意」). The ruling's reasoning, quoted:

两实现不一致时带治理的一侧(同意、审计、加宽拒绝 409 都在结构化侧)默认胜出——文档已叫作者『优先结构化』,而结构化在本地无读者

1.1 — Scope is Phase 1 ONLY. Wire sys_package_installation.granted_permissions (the install-consent set) into PluginPermissionEnforcer (F4) so it actually gates at load time. ⛔ Phase 2 — retiring the legacy string[] arm — is a sibling card carrying Blocked-by: this one. Do not touch it.

1.2 — ⛔ cloud is NOT readable, and the card already forbids re-reading it. The cloud-side facts (consent flow parses the structured four classes; permissionsWiden ⇒ 409; plugin-consent.ts says "the environment runtime later feeds it to the framework's PluginPermissionEnforcer (F4) to gate the plugin at load time") are 在案读数 — recorded findings you inherit and ⛔ must not re-derive or contradict. This session's repo scope is objectstack-ai/objectstack + objectstack-ai/objectui only.

1.3 — ⭐⭐ The gate must FAIL SAFE, and this is the whole risk of the card. Installing enforcement where none ran means plugins that load today can start being refused. ⛔ A first-party / built-in plugin has no sys_package_installation row at all, and an existing third-party installation may carry an empty or absent grant set. An absent grant set must NOT mean "deny everything" — that would brick boot. Measure what the absent case must do and pin it in both directions. ⚠️ If the correct answer is not derivable from the ruling, that is STOP condition 2 — report, ⛔ do not choose.

1.4 — ⛔ Do not weaken the existing pin. packages/core/src/plugin-loader.retired-fields.pin.test.ts carries a positive control asserting the security barrel still publishes PluginPermissionEnforcer. It must keep passing.

---

Zone 2 — PM mechanism assumptions. Measure these; ⭐ falsifying one is a reportable success.

A2.1 — ⭐⭐ THE ONE THAT DECIDES WHETHER THIS CARD CAN LAND HERE AT ALL. "A production plugin-materialization site exists in this repo to wire into." The enforcer registers a set the cloud control plane persists. My assumption is that this repo's plugin loader reaches a point where it materializes a third-party plugin and could construct a SecurePluginContext around it. Falsifiable and quite possibly false: if the only place that knows the granted set lives in cloud, Phase 1 has no local source to read and cannot land here as written. Find the site, or establish there isn't one — ⇒ STOP condition 1.

A2.2 — "buildPermissionsFromGrants is the adapter, and it is already correct." It is exported from the security barrel alongside the enforcer, which suggests it converts the persisted grant shape into PluginPermissions. Verify what it actually does on the pinned shape rather than trusting the name.

A2.3 — "registerGrantedPermissions is the right entry point." granted-permissions.test.ts already exercises it (PluginPermissionEnforcer.registerGrantedPermissions), so the primitive exists and is tested. Confirm the wiring needs no new primitive — if it does, say why.

A2.4 — "Only service access matters for Phase 1." Per the docs quote, enforceNetworkRequest / enforceFileRead / enforceFileWrite have no call sites and nothing patches global fetch. ⚠️ So wiring the load gate may make {services, hooks} real while {network, fs} stay declarative. If so, say it loudly in the PR — shipping a gate that enforces two of four declared classes while the docs imply four is exactly the declared≠enforced shape this repo exists to remove. ⛔ Do not silently widen to fix it; that is a bigger card.

---

Zone 3 — advisory, not binding

• The liveness ledger (packages/spec/liveness/manifest.json) carries an authoritative note on this exact split, including "nothing in this repo feeds the manifest declaration into it". ⚠️ If your change makes that note false, the ledger row needs updating in the same PR — a ledger that describes the previous world is worse than no ledger.
• ⛔ Never edit content/docs/releases/. If content/docs/protocol/kernel/plugin-spec.mdx becomes wrong because of your diff, correcting it is in scope — it is not release-owned.
• ⛔ Never git stash. Worktree-first before your first edit.

STOP conditions

1. A2.1 finds no production plugin-materialization site in this repo ⇒ Phase 1 cannot land here as written. Report with what you found.
2. Enforcement would refuse something that loads today (absent/empty grant set, first-party plugins) and the ruling does not settle what the absent case means ⇒ report; ⛔ do not pick a default that silently denies.
3. Your git grep re-confirmation contradicts my search-index measurement ⇒ ⛔ STOP and report; the card returns to pm:retriage, per triage's own instruction. Do not build on a falsified premise.
4. Any other open PR claims your paths. Verify BEFORE your first edit. ⚠️ Three sibling seats are live: The undeclared-field door sits in FRONT of the hooks, so a key a beforeInsert hook writes has no door at all — and the drivers then disagree (memory stores it, SQL throws a raw statement error) #13657 (packages/objectql insert/update ↔ hook seam — conceptually adjacent to enforceHookTrigger, but a different package; flag it if you land in the same file), [finding] If-Match: "" silently DISABLES optimistic concurrency — a quoted-empty entity-tag is read as "no token" and the guarded write proceeds unguarded #13576 (packages/metadata-protocol OCC ingress), measure: census the dependents of the SQL driver's orWhereNull tenant-wall carve-out before deciding its future (NULL org_id rows are globally visible on shared-DB walled deployments) #13564 (packages/drivers/driver-sql, read-only). ⚠️ Note also that packages/core/src/security/ recently received perf(core): cheapen the authz transport scan so a slow test stops aborting the Test Core shard #13656 — check git log there before editing.

Verification expected

The git grep re-confirmation with its own firing positive control; the A2.1 verdict (the wiring site, or its absence) stated first because everything depends on it; both-direction pins for 1.3 (granted surface enforced and the absent-grant case not denied); the full packages/core suite; an ablation proving the new gate's pins fail without it (mutation proved on disk by anchored greps both ways + changed blob hash; restore proved byte-identical to HEAD under a trap with absolute paths); the gate family from node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack; a changeset. ⭐ State explicitly which of the four permission classes your gate actually enforces (A2.4). ⛔ Report anything unmeasured as NOT MEASURED, never as a pass. ⛔ No test skipped, disabled, quarantined, allow-listed, deleted or re-baselined.

---

Generated by Claude Code

[zhuangjianguo]

os-dev-report

{
  "issue": 13457,
  "status": "blocked",
  "branch": "claude/issue-13457-granted-permissions-load-gate",
  "pr": null,
  "premise_still_valid": false,
  "summary": "A2.1 VERDICT (decisive): no production plugin-materialization site exists in this repo to wire granted_permissions into. Both kernels construct exactly ONE shared PluginContext at construction time and hand that SAME object to every plugin's init() (packages/core/src/kernel.ts:91-171 + line 607 `plugin.init(this.context)`; packages/core/src/kernel-base.ts:75/202 for LiteKernel) -- there is no per-plugin identity lookup or wrapping step anywhere a SecurePluginContext could be attached. The local Zod schema for sys_package_installation (packages/spec/src/cloud/environment-package.zod.ts EnvironmentPackageInstallationSchema) declares no granted_permissions field at all. The whole .osplugin code-plugin pipeline that would even load untrusted third-party code -- install flow SS3.5, the sys_plugin/sys_plugin_version/sys_plugin_installation registry SS3.8, install-time consent -- is docs/adr/0025-plugin-package-distribution.md's own status line: 'Proposed -- partially implemented ... install flow (SS3.5) ... and install-time consent remain unimplemented.' Confirming that in code: verifyPluginArtifact, the artifact/signature check ADR-0025 names as running 'at materialize time', has zero call sites outside its own module -- nothing in production ever calls it. packages/cloud-connection's POST /install handler is a pure proxy to cloud's sys_package/install_package action (forwards body, returns cloud's response verbatim); it materializes nothing locally. Architecturally this is not an oversight: ADR-0003 (revised by cloud ADR-0007, 2026-06-12) states sys_package_installation is control-plane desired state 'never read as what is actually installed on any runtime path -- runtime truth lives with the environment itself (env-local artifact cache for cloud-managed environments; the LocalManifestSource ledger ... for self-hosted runtimes)', and neither of those two carriers has a grant field today (LocalManifestSource's InstalledManifestEntry checked line-by-line -- no such field). Phase 1 as scoped ('wire sys_package_installation.granted_permissions into PluginPermissionEnforcer at load time') therefore has no local integration point in objectstack to build against -- inventing one (a new artifact-cache field, a new per-plugin context-wrapping step, a fabricated local grant carrier) would not be 'Phase 1 of a ruling', it would be designing the missing ADR-0025 install/materialize pipeline from scratch, unreviewed, which is out of this card's scope and violates Prime Directive #12 (contract-first: fix it at the true producer, don't fabricate a consumer-side stand-in). STOP condition 1 fires; per the dispatch order this is reported rather than built. No code was written or changed.",
  "tests": "git grep re-confirmation of triage's search-index measurement (STOP condition 3 check), run in the worktree before any edits: `PluginPermissionEnforcer` = 26 hits total, all classify as definition/barrel-reexport/tests(granted-permissions.test.ts, plugin-permission-enforcer.test.ts, plugin-loader.retired-fields.pin.test.ts)/docs-ADR-liveness-prose -- ZERO production callers. `createPluginPermissionEnforcer`/`permissionEnforcer` = hits only inside plugin-permission-enforcer.ts itself + its barrel re-export. `SecurePluginContext` / `new SecurePluginContext(` = hits only inside granted-permissions.test.ts and plugin-permission-enforcer.test.ts (test-only construction) plus the docs page and the barrel export -- ZERO production construction sites. `enforceServiceAccess`/`enforceHookTrigger`/`enforceNetworkRequest`/`enforceFileRead`/`enforceFileWrite` = hits only inside the enforcer module + its own tests + the docs sentence quoted in the dispatch order. `granted_permissions` = 5 hits, all docs/ADR/zod-docblock/ledger prose, none of them a live reader. `sys_package_installation` grepped repo-wide (60+ hits): every one is ADR prose, CHANGELOG history, docs/references pages, or the schema file itself -- none is a runtime read of a granted_permissions column, because that column is not declared in this repo's schema for the object. Positive control fired throughout (definitions, barrel, tests, docs all returned). CONCLUSION: git grep agrees exactly with triage's search-index measurement -- STOP condition 3 (index contradicted by grep) does NOT fire; the zero holds and is stronger than before. Because A2.1's STOP condition 1 fired and no code was written, the following are NOT MEASURED / not applicable: packages/core full suite, both-direction pins for 1.3, ablation, `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack`, changeset. The pre-existing pin `packages/core/src/plugin-loader.retired-fields.pin.test.ts` was read but not touched -- unweakened, unmodified.",
  "mcp_calls": "4",
  "open_questions": [
    {
      "question": "Phase 1 (#13457) has no local plugin-materialization site to wire granted_permissions into: ObjectKernel/LiteKernel hand every plugin the same single shared PluginContext with no per-plugin identity lookup, sys_package_installation's local schema has no granted_permissions field, and ADR-0025's own status line says the install flow / consent / registry that would produce one are unimplemented in objectstack. How should this card proceed?",
      "options": [
        "A. Re-scope this card into a design task: build the missing local foundation in packages/core (a materialize-time seam in kernel.use()/PluginLoader that resolves a per-plugin grant record and constructs SecurePluginContext) PLUS a real local carrier for the granted set (an artifact-cache field, a LocalManifestSource field, or a fetched-at-boot record) -- since ADR-0025 SS3.5's install flow is itself still 'Proposed -- partially implemented,' this is materially bigger than 'wire an existing gate' and needs its own design/ruling rather than a Phase-1 dev dispatch.",
        "B. Confirm with the maintainer whether #11333's ruling intended objectstack to own this wiring at all: ADR-0003 (revised by cloud ADR-0007) states sys_package_installation is control-plane desired state 'never read... on any runtime path' -- architecturally the runtime is meant to receive an already-compiled artifact, and no such artifact carries granted_permissions today on either side of the repo boundary this card can see. Phase 1 may belong in `cloud` (compiling the artifact) with objectstack only consuming it once that artifact contract exists.",
        "C. Leave the card queued/blocked until the ADR-0025 install-flow work (or a follow-up ADR defining the local artifact contract) lands elsewhere, and re-open Phase 1 then, unchanged as written."
      ],
      "recommendation": "B, because the missing piece is not code nobody wired -- it is a data channel that does not exist yet on either side of this session's readable repo boundary, and Prime Directive #12 (contract-first) says fix it at the true producer rather than fabricate a consumer-side stand-in; fabricating a local grant carrier now (option A) would be undocumented, unreviewed architecture invented mid-dispatch, exactly the shape #12 exists to prevent. A is the right fallback only if the maintainer explicitly wants objectstack (not cloud) to own designing that artifact contract; C just defers the same question without answering it."
    }
  ],
  "out_of_scope_findings": []
}

---

Generated by Claude Code