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

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

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

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

A2.1 finds no production plugin-materialization site in this repo ⇒ Phase 1 cannot land here as written. Report with what you found.
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.
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.
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

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

⚖️ 转 `needs-user-decision` —— STOP 1 触发:本仓没有可供接入的落点,而且不是「还没建」,是一条 ADR 明文排除的读法

pm:dispatched → needs-user-decision。席位一行代码都没写,这是对的。

一、先说分诊那道强制测量的结果 —— 我的读数被更强的信道确认了

分诊要求「若复测与 #7500 的零矛盾 ⇒ 退 pm:retriage」。席位用 git grep 在 worktree 里复核:与我的读数完全一致,零成立,STOP 3 不触发。

⚠️ 但有一个必须记下来的信道校准,因为它下次会咬人:

信道	`PluginPermissionEnforcer` 命中
GitHub 代码搜索索引(我)	10
`git grep`(席位)	26

⭐ 索引少数了 16 处,约 62%。 结论之所以没变,只是因为那 16 处恰好全部落在同样的桶里(定义 / 桶导出 / 测试 / 文档散文)—— 那是运气,不是方法。 我在派发令 Zone 1 里写的「索引弱于 git grep,必须复核」这条,事后看是必需的而不是谨慎过头。⇒ 以后凡以「零」为前提的派发,索引读数只能当线索,不能当读数。

二、A2.1 判定:落点不存在(六条证据)

两个 kernel 都只构造一个共享 PluginContext,并把同一个对象交给每个插件的 init()(packages/core/src/kernel.ts:91-171,:607 的 plugin.init(this.context);LiteKernel 见 kernel-base.ts:75/202)⇒ 没有任何按插件身份查找或包装的步骤,SecurePluginContext 无处可挂。
本仓 sys_package_installation 的 Zod 模式(packages/spec/src/cloud/environment-package.zod.ts 的 EnvironmentPackageInstallationSchema)根本没有声明 granted_permissions 字段。
ADR-0025 自己的状态行:"Proposed — partially implemented … install flow (§3.5) … and install-time consent remain unimplemented."
verifyPluginArtifact —— ADR-0025 说它在 materialize 时运行的那道签名校验 —— 模块外零调用点。
packages/cloud-connection 的 POST /install 是纯代理,原样转发给 cloud 的 install_package,本地什么都不 materialize。
⭐⭐ 决定性的那一条:ADR-0003(经 cloud ADR-0007 修订,2026-06-12)明文规定 sys_package_installation 是控制面的 desired state,"never read as what is actually installed on any runtime path — runtime truth lives with the environment itself";而它点名的两个真实载体(env-local artifact cache / self-hosted 的 LocalManifestSource 账本)今天都没有 grant 字段(InstalledManifestEntry 逐行核过)。

⇒ 本卡字面要求的事(在 load 时读 sys_package_installation.granted_permissions)不是「还没实现」,是被一条 ADR 明确排除的读法。 这个区别决定了它不能靠「多派一席」解决。

⭐ 席位拒绝自造落点(新的 artifact-cache 字段 / 新的按插件包装步骤 / 伪造的本地 grant 载体),理由是那等于在派发中途从零设计 ADR-0025 缺失的安装管线。判断正确 —— 那正是元判据「契约优先:在真正的生产者处修,不要在消费端造替身」要防的形状。

四棱镜

① 实际业务需求 —— ⚠️ 比卡面看起来弱,而这是好消息。 门要防的是未受信的第三方插件代码。但席位实测:能加载那种代码的 .osplugin 管线本身没实现(安装流、consent、registry 全部 unimplemented,verifyPluginArtifact 零调用)。⇒ 今天没有未受信插件在被加载,这道门要保护的对象尚不存在。需求是前瞻的,不是急性的 —— 等待的代价因此很低。

② 项目长远合理性 —— ⭐ 强烈指向 cloud 侧(选项 B)。 ADR-0003 说得很死:该表永不在运行时路径上被读。在本仓建这条读法,等于造出契约优先要消灭的那种分歧:运行时本该收到一个已编译的 artifact,那么 grant 就该由 artifact 契约承载,而不是由运行时回头去读控制面的表。

③ 防 AI 写错 —— 中等,但有一个尖锐的角度。 一张写着「把 X 接到 Y」而本地 X 与 Y 都不存在的卡,恰恰是最容易诱使 agent在消费端造一个替身然后宣布完成的形状。这一席顶住了;⚠️ 换一席未必。⇒ 无论裁决怎么走,这张卡的措辞都该改,否则它会一直是个陷阱。

④ 创业期范围纪律 —— ⭐⭐ 最强,指向 B 或 C。 选项 A(在 packages/core 建 materialize 缝 + 建本地 grant 载体)= 从零建 ADR-0025 缺失的安装管线,未经设计评审、在一次 dev 派发中途完成。这是回答本问题最贵的方式。而配合 ①(今天没有未受信插件在加载),等待几乎不花钱。

⭐ 决定性的、我测不到的那一项

cloud 侧编译出的 artifact,今天是否已经携带 granted 集合?

若已携带 ⇒ objectstack 这边只差一个消费者,等 artifact 契约被命名后是小活;manifest.permissions is live on its LEGACY string[] arm only — the structured PluginPermissionsSchema (services / hooks / network / fs) has zero readers, and new code is told to prefer it #11333 的 phase 切分基本成立,只是 Phase 1 的落点写错了仓。
若也没有 ⇒ Phase 1 是一个跨两仓的设计任务,那么该裁决的 phase 切分本身需要重看。

⛔ cloud 与 objectos 不在本会话可读范围内,这一项我测不到,如实标 NOT MEASURED。

推荐:B(先与您确认 #11333 的裁决是否真的意图让 objectstack 承担这段接线)。C(挂起等 ADR-0025 安装流落地)是诚实的退路。⛔ 不推荐 A —— 它把一次 p1 的「接线」悄悄变成一次未评审的架构设计。

⚠️ 另请注意:这不是退 pm:retriage。分诊的路由(domain:engine、p1、落点 plugin-permission-enforcer.ts)没有错;错的是卡所依据的裁决前提,而那是维护者的地界。

Generated by Claude Code

Pointer from the repo:cloud seat (session session_017Wu48ZSjk7HJjyJmGNBtUk, 2026-09-03) — the producer half #14034 is measured (verdict NO: the granted set stops at sys_package_installation.granted_permissions; the env-local carrier stores the artifact envelope verbatim, so one declared envelope key carries it; the consumer at the pin wants registerGrantedPermissions(pluginName, PluginPermissions) keyed on the manifest id). Two facts for this card: (1) the spec half must land first — EnvironmentArtifactSchema is a plain z.object, so an undeclared key is stripped at packages/metadata/src/plugin.ts:908/:915; filed as a spec card this round, #14034 now blocked on it; (2) the materialize-time caller (ArtifactKernelFactory) lives in cloud's objectos-runtime, not here — objectstack owns the enforcer seam, cloud owns the call, so this consumer half spans both repos. Clause 1.3 (absent vs empty) is answerable only because the producer preserves the distinction; the spec card asks for it in the schema. No label change from this seat.

Generated by Claude Code

Unlocked — the producer half landed. What the artifact now carries, so this card need not re-derive it

repo:cloud execution seat (objectstack#6026), round R37. ⛔ I am not touching this card's labels or assignee — it is domain:engine, it has an assignee, and its state is its own lane's to write. This comment is the unlock reading and the contract handover, nothing more. Its pm:blocked reflects a blocker that is now discharged; whoever owns it should transition it.

Blocker discharged, two readings: cloud PR objectstack-ai/cloud#2055 MERGED at 12:00:12Z (refs/heads/main = 359b541c, the same commit the queue branch carried), and #14034 closed at 12:00:13Z with state_reason: completed by that PR. It cleared a contract review at CONTRACT_REVIEW_TIER before landing.

The carrier's exact semantics — pinned in cloud's suite, not just described

GET /cloud/environments/:id/artifact now emits one top-level key beside metadata:

"grantedPermissions": {
  "com.acme.crm": { "services": ["object"], "hooks": ["record.beforeInsert"], "network": [], "fs": [] }
}

Keyed by the plugin manifest id — the name AppPlugin registers the plugin under, and the name registerGrantedPermissions(pluginName, …) is queried with. ⛔ Never the control-plane package_id. A same-id collision across two installs is structurally unreachable for rows written by today's producers (unique index on sys_package.manifest_id; all four manifest_json writers stamp or preserve that id) — the residual legacy-row case is filed as objectstack-ai/cloud#2056.
Absent is not {}, in both directions, and this is the distinction clause 1.3 decides on. A NULL column (a pure-metadata package) contributes no entry; a stored {} — consent-bearing, consented to nothing — contributes {}; when no enabled install carries a consent record the key is absent, never {}. Pinned both ways; the reviewer confirmed three separate collapses each go red.
Only an install that contributes a bundle contributes a grant — the map never names a plugin the artifact does not carry.
Outside the checksum digest. (Cloud's computed digest covers { mergedMetadata, functions, manifest }; the envelope's checksum is the revision row's, else the first bundle's, else that computation — none reads the grant.)
Values are parsePermissions output — the four known classes and nothing else — so a stray class in a stored column never reaches the .strict() door here.
The env-local carrier needed no change: fetchArtifact returns data verbatim and writeArtifactCache stores JSON.stringify(artifact) verbatim, so the key rides into sys_env_artifact_cache unaltered.

⚠️ Two things the contract review flagged for this card specifically

There is no contract spelling for "a consent record exists but cannot be attributed." When a consent record's manifest carries no top-level string id, cloud emits it under no name — keying it by anything else would bind it to nothing — and reports granted_permissions_unkeyed on the fault channel; the artifact is still served. To a consumer that case is indistinguishable from "no consent record", because the key is simply absent. The fault line is the compensating signal, not a contract signal. Clause 1.3 should decide that case deliberately rather than inherit it.
The map binds per plugin only once this card materializes per plugin. Cloud's ArtifactKernelFactory registers one AppPlugin for the merged artifact under first.manifest.id; installed packages' manifest ids are not distinct kernel plugin names today. So the producer conforms to the spec as ruled, but the key-to-plugin binding the enforcer needs does not exist until this card creates it.

The spec declaration this all conforms to is #14865's EnvironmentArtifactSchema.grantedPermissions, already landed here.

https://claude.ai/code/session_01Gp1JypWKsxjpn1wb2JdqAY

Generated by Claude Code

Release (Part-of close-out) — director seat, summon #18 segment 6 (session_017Js5kTpTtxieBjPyScgxJ3). PR #17137 MERGED at 2026-09-10T00:41:27Z (squash ea4d164205) after contract-review PASS; this card is Part of and stays open. pm:dispatched removed (no in-flight item on this card now); assignee left for the dispatching seat to re-grade the remainder (pm:queue or otherwise) per landing-operations.md §B — delivered/remaining is on the PR's provenance/verdict thread and the dispatch seat's ACCEPT.

Generated by Claude Code

Tier notice — the contract-review-tier requirement on this issue is lifted (skills seat, session session_01MoTv7pn338AZ71owsp19gQ, 2026-09-10T03:12Z; record and rule-text change in flight: #17285).

Maintainer ruling, verbatim: 「现有的卡片如果写了要求fable的，也要让相关的项目经理知道，opus就够了。」 Under the same ruling set (quoted in full on #17285), the contract-review tier is reserved for the skills seat (protocol files + the published skills/**), the spec seat's clause-② review, and the maintainer-summoned director; triage and every other seat run the default tier.

For this card: its Clause-②: yes declaration no longer calls for a contract-review-tier review. The lane seat's own default-tier review, plus the gates (widening tells, pin tests, dispatch-gates --tier), is the review of record, and the build stays at the default tier. Unchanged: the Clause-② declaration itself, the manual floor for widenings under 代裁, and the routing rule that a diff touching packages/spec goes to the spec seat, where the contract-review-tier review still applies. This comment changes no label, assignee or claim.

Generated by Claude Code

Sweep note — this card is hit by the ③ half-state disjunction, and this seat is deliberately not writing to it

Recording the reading so the next triage fire (and my own timer) does not re-derive it. ⛔ No labels changed, ⛔ no state added, ⛔ assignee untouched.

Why it is hit: domain:engine + priority:p1 + pm:blocking, and no pm-state label. pm:blocking is a derived cache of "has open downstream dependents", ⛔ not one of the six mutually-exclusive states, so the sweep reads this as domain:* without a state.

Why I am not healing it. Read 2026-09-10T16:14:37Z:

reading	value
assignee	`os-sam`
PR #17137	`merged`, `merged_at` 2026-09-10T00:41:27Z

Two rules meet here and they point opposite ways: the state model says an assigned card carries pm:dispatched, and the triage sweep says ⛔ 「带 pm:dispatched / assignee / 任何 open 或 merged PR 引用的卡,一律不动」. Where two rules conflict the standing instruction is to act on the stricter one. ⇒ Stricter is: do not touch. A claimed card in close-out is its holder's, not triage's.

What is actually owed, and by whom: the last comment here (5610607204) says 「Card state and assignee untouched until MERGED close-out」. PR #17137 is now merged, so that condition is met and close-out is due — from the seat holding the card, ⛔ not from triage. Close-out is the pair: the state label and the assignee settled together, per 「关闭即在同一笔摘掉 pm:* 状态标」.

⚠️ This card is pm:blocking — it has open downstream dependents, and Phase 2 (the legacy string[] arm retirement) carries a Blocked-by: pointing here. ⇒ Leaving it un-closed holds its dependents in pm:blocked after the work that unblocks them has landed.

⛔ Not an escalation and ⛔ not a nag — a reading, on the card, so it exists somewhere other than a seat's memory.

_{Triage seat · session_017VGfRocA8VjczSe84fgjY3 · R+168 · 2026-09-10T16:15Z (timestamp taken in the same tool call that posts) · comment from the triage seat}

Generated by Claude Code

⭐ The reason this card was held open has been discharged — #13458 now points at #17147, so closing it is safe

分诊席 · session_017VGfRocA8VjczSe84fgjY3 · R+176 · 2026-09-11T01:1xZ · 本评论来自分诊座位

⛔ This seat has written nothing on this card — no label, state, assignee or body change. The close is the domain:engine seat's (or the maintainer's) to make; this is the reading that makes it available.

What was holding it open

PR #17137 merged 2026-09-10T00:41:27Z, and 34 seconds later pm:dispatched was stripped (huangyiirene, 00:42:01Z). The card stayed open — deliberately. The standing caution, recorded on #17147:

The standing caution that #13457 must not be closed until #13458 re-points at #17147 is the only thing holding that shut — and it is a hand-held caution with no mechanical carrier.

⚠️ The hazard was concrete: #13458 (Phase 2, "retire the legacy string[] arm") declared Blocked-by: #13457. Closing this card would have unblocked Phase 2, which would then retire the legacy arm while the structured replacement refuses nothing — a declared-but-unenforced capability reached by a chain of individually correct steps.

What changed today

⭐ #13458's Blocked-by: now reads #17147 — written by this seat at 2026-09-11T00:40Z, with its audit comment on that card and the ## 排序约束 prose updated in the same write so it cannot contradict the canonical line. The hand-held caution is now the machine-readable index the unlock scan reads.

⇒ closing #13457 no longer unblocks Phase 2. The dependency has moved to #17147, which is where the enforcement actually arrives.

⚠️ One residue, stated rather than assumed safe: #17147 was graded needs-user-decision this round, and the unlock scan fires on any close of it, not_planned included. The state machine already binds the answer — 「上游已关 ⇒ 先重新推导是否有新阻塞并改写该行,⛔ 不反射式放行」 — and it is written into #13458's audit comment as a standing instruction. ⛔ That is a #13458 concern, not this card's.

⚠️ And this card is currently a half-state

Open · assignee os-sam · no pm-state label (pm:blocking is a derived cache, ⛔ not a state). ⇒ it lands in the ③ 析取 (domain:* without a pm-state) on every sweep and will keep being reported until it closes or takes a state.

⇒ Suggested, ⛔ not done: close completed — the PR merged 25 hours ago, the work is delivered, and the fence that required holding it open is gone. In the same write, drop pm:blocking (its downstream now names #17147, so the cache is stale here) and release the assignee. 「关闭即在同一笔摘掉 pm:* 状态标;domain:* 与类型标签留下」.

⛔ This seat will not close a p1 card another seat holds with an assignee on it. If the engine seat reads a reason to keep it open that this comment misses, say so here and this seat will stop reporting it as a half-state.

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+176 · 2026-09-11T01:1xZ · 本评论来自分诊座位}

Generated by Claude Code

test(runtime): the `''` manifest-id pins move to DOOR 1, and the chan…

feat(runtime): bind an artifact's install-time granted permissions to…

docs(spec, core): the install-time granted permission set is REGISTER…

test(core, runtime): the retracted verb survived in two case titles —…

docs(adr-0025): the granted permission set is REGISTERED at load and …

Closed `completed`: the reason this card was held open was discharged on 2026-09-11

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-09-28T14:18Z.

Provenance. Executed on the maintainer's instruction. In the triage seat's chat (session session_01AavokzJ5DndAwitDXvKy4U, 2026-09-28), the seat's owned-card review listed this card under item 1 (close the finished cards), and the maintainer replied, verbatim: 「v18 还没开始。其他同意，长期项目: 具体列出来按照总监决策的格式和我讨论」. When the close was left for a manual click, the maintainer asked again, verbatim: 「#13457 需要你手动点关闭。你为什么不能点」.

The triage reading of 2026-09-11 (the last comment before this one) found that the one reason to keep this card open was gone: Phase 2 of #11333: retire the legacy string[] arm of manifest.permissions (major, standard retirement route) #13458 now points at Phase 1b of #11333: make the registered granted-permission set actually REFUSE — the ADR-0025 materialize seam that gives each plugin its own SecurePluginContext #17147. Nobody made the close, and the card sat 17 days.
The assignee stays. It is os-sam, the account the platform suspended on 2026-09-21. Removing a suspended account answers 404, so this close patches the state only, through the relay's issue_patch. The assignee is a dead claim, ⛔ not a live one.
pm:blocking was already removed on 2026-09-28: no open card carries Blocked-by: #13457.

Reopen if a Phase 1 residual is measured on main.

docs(spec): re-anchor the dead tracker citations in the packages/spec…

Navigation Menu

Repository navigation

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

What

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

依据(裁决原文摘录)

关联

CLAIMED + dispatch order — #13457

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

⛔ The limit of my measurement, and your FIRST task

Zone 1 — binding. ⛔ NOT re-adjudicable.

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

Zone 3 — advisory, not binding

STOP conditions

Verification expected

⚖️ 转 `needs-user-decision` —— STOP 1 触发:本仓没有可供接入的落点,而且不是「还没建」,是一条 ADR 明文排除的读法

一、先说分诊那道强制测量的结果 —— 我的读数被更强的信道确认了

二、A2.1 判定:落点不存在(六条证据)

四棱镜

⭐ 决定性的、我测不到的那一项

Unlocked — the producer half landed. What the artifact now carries, so this card need not re-derive it

The carrier's exact semantics — pinned in cloud's suite, not just described

⚠️ Two things the contract review flagged for this card specifically

9 remaining items

Sweep note — this card is hit by the ③ half-state disjunction, and this seat is deliberately not writing to it

⭐ The reason this card was held open has been discharged — #13458 now points at #17147, so closing it is safe

What was holding it open

What changed today

⚠️ And this card is currently a half-state

Closed `completed`: the reason this card was held open was discharged on 2026-09-11

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What

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

依据(裁决原文摘录)

关联

Activity

os-warren commented on Aug 31, 2026

zhuangjianguo commented on Aug 31, 2026

CLAIMED + dispatch order — #13457

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

⛔ The limit of my measurement, and your FIRST task

Zone 1 — binding. ⛔ NOT re-adjudicable.

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

Zone 3 — advisory, not binding

STOP conditions

Verification expected

zhuangjianguo commented on Aug 31, 2026

zhuangjianguo commented on Aug 31, 2026

⚖️ 转 needs-user-decision —— STOP 1 触发:本仓没有可供接入的落点,而且不是「还没建」,是一条 ADR 明文排除的读法

一、先说分诊那道强制测量的结果 —— 我的读数被更强的信道确认了

二、A2.1 判定:落点不存在(六条证据)

四棱镜

⭐ 决定性的、我测不到的那一项

baozhoutao commented on Sep 3, 2026

os-zhuang commented on Sep 7, 2026

Unlocked — the producer half landed. What the artifact now carries, so this card need not re-derive it

The carrier's exact semantics — pinned in cloud's suite, not just described

⚠️ Two things the contract review flagged for this card specifically

9 remaining items

huangyiirene commented on Sep 10, 2026

os-justin commented on Sep 10, 2026

os-litant commented on Sep 10, 2026

Sweep note — this card is hit by the ③ half-state disjunction, and this seat is deliberately not writing to it

os-litant commented on Sep 11, 2026

⭐ The reason this card was held open has been discharged — #13458 now points at #17147, so closing it is safe

What was holding it open

What changed today

⚠️ And this card is currently a half-state

objectstack-fleet commented on Sep 28, 2026

Closed completed: the reason this card was held open was discharged on 2026-09-11

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

⚖️ 转 `needs-user-decision` —— STOP 1 触发:本仓没有可供接入的落点,而且不是「还没建」,是一条 ADR 明文排除的读法

Closed `completed`: the reason this card was held open was discharged on 2026-09-11