fix(runtime, metadata-protocol): the permission-set clone door copies a set that grants on an object this deployment does not install, and member_default's feed grants re-land - #30310

📓 Docs Drift Check

This PR changes 3 package(s): @objectstack/metadata-protocol, @objectstack/plugin-security, @objectstack/runtime, touching 6 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/concepts/metadata-lifecycle.mdx (via ObjectStackProtocolImplementation (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx (via SaveMetaItemRequest (symbol, a top-level type))
• content/docs/permissions/system-context.mdx (via handlePermissionSetCloneWrite (symbol, a top-level function))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v16.mdx (via ObjectStackProtocolImplementation (symbol, a top-level class))
• content/docs/releases/v17/17-0.mdx (via ObjectStackProtocolImplementation (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin c66f171f0b5680a2e17282e0c8f20eb8b38a57b8 && git checkout c66f171f0b5680a2e17282e0c8f20eb8b38a57b8
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin bfca0efb79ac5df2049f392cdecd3bbeeea9ec61 d770fe2150f293162ce906de2fb910370edcc6fc && git checkout -B drift-repro bfca0efb79ac5df2049f392cdecd3bbeeea9ec61 && git merge --no-ff d770fe2150f293162ce906de2fb910370edcc6fc

node scripts/docs-audit/affected-docs.mjs --json bfca0efb79ac5df2049f392cdecd3bbeeea9ec61

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs bfca0efb79ac5df2049f392cdecd3bbeeea9ec61 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

domain:server#2 · os-bill · session_01Utp6Cbvcmv8YWFhFJwzjKL

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 591198e4e1052010cefbce18714abc7ec526b92e
Local-runs: none
Scope: packages/metadata-protocol/src/protocol-door-requests.ts, packages/metadata-protocol/src/protocol-save-door-refusals.ts, packages/metadata-protocol/src/protocol-save.ts, packages/metadata-protocol/src/protocol.ts, packages/metadata-protocol/src/protocol.unknown-grant-object-refusal.test.ts, packages/runtime/src/domains/permission-set-clone.ts, packages/runtime/src/domains/permission-set-clone.test.ts, packages/plugins/plugin-security/src/objects/default-permission-sets.ts, packages/plugins/plugin-security/src/member-default-explicit-allow.test.ts, packages/plugins/plugin-security/src/member-default-feed-grants.integration.test.ts, packages/plugins/plugin-security/src/comment-reaction-own-record-floor.test.ts, .changeset/30108-member-default-feed-grants.md, .changeset/30255-clone-inherits-held-grants.md + packages/rest/src/meta-item-write-routes.ts, packages/rest/src/meta-save-request.ts, packages/runtime/src/domains/meta.ts, packages/runtime/src/domains/packages.ts, packages/metadata-protocol/src/protocol-package-commits.ts, packages/metadata-protocol/src/protocol-authoring-gate.ts, packages/metadata-protocol/src/protocol-history-and-publish.ts, packages/metadata-protocol/src/protocol-packageless-overlay-migration.ts, packages/runtime/src/domains/automation.ts, packages/services/service-automation/src/flow-credential-migration.ts, packages/services/service-datasource/src/plugin.ts, packages/cli/src/commands/migrate/organization-ownership.ts, packages/spec/src/api/protocol.zod.ts, packages/spec/src/api/protocol.test.ts, packages/qa/dogfood/test/permission-set-clone-door.dogfood.test.ts

Read-only review of the PR body, file list, the net diff origin/main...591198e4 (13 files, +707/−24), cards #30255 and #30108 with every comment, and the head's check-runs. Not read: the dispatch order, the seat's conclusions, the seat hand-off file. No dev report for #30255 exists on either card or on the PR at review time, so ③ reads the #30108 report (6647979158) and the PR body's own claims. One probe-free verification was done with git on the fetched ref only (blob hashes, diffs, greps); nothing was built, run or re-run.

① Derived judgments

• Commit 1 (e7226bbc) is byte-identical to 490d136f on its five paths. Verified by blob hash: .changeset/30108-member-default-feed-grants.md 91be2f6b, comment-reaction-own-record-floor.test.ts 9cb68c48, member-default-explicit-allow.test.ts b6650923, member-default-feed-grants.integration.test.ts ac307a2c, objects/default-permission-sets.ts af3bc8d2 — each equal at 490d136f and e7226bbc. git diff 490d136f e7226bbc -- [five paths] is empty. At the head, four of the five are still identical; only the changeset moved (blob 2a40eb8b), by exactly the one added bullet that names the clone-door fix. So the re-land carries the earlier PASS record 6648282410 forward unchanged, and the ruling A rows (sys_comment read/create/edit, sys_activity read, no delete, no row policy) are as reviewed.
• Accept-set change of commit 2 — exactly one, in one place. ProtocolSaveFacet.saveMetaItemUnaudited (protocol-save.ts:1582), in draft and in publish mode and never for a migrate-stored re-save, now hands request.inheritedGrantObjects to unknownGrantObjectSaveRefusal, which drops those keys from its unknown list AFTER the four existing filters (registry getObject by exact name, declared object row, pending object drafts, the set's own current held grants) and before composing the 422. Keys not in the inherited set are refused exactly as before; the message text does not move. No other refusal reads the key: the publish door (protocol-history-and-publish.ts:832) passes batchObjects and 'publish' and no inherited set; the restore door (protocol-authoring-gate.ts:147) passes three arguments; PUT /meta passes none. So the only save that skips the refusal for any key is one whose in-process caller states inheritedGrantObjects, and the only such caller in the tree is the clone door's step 7.
• Which keys the clone door states. inheritedGrantObjectsOf(clone) = Object.keys(clone.objects), where clone = structuredClone(source.definition) minus PERMISSION_SET_CLONE_DROPPED_KEYS (read decorations, protection fields, packageId, managedBy, protection, adminScope, isDefault) with only name and label set. objects is not touched between the catalog read and the save, so the stated set equals the source's grant keys exactly; the clone body is closed to { name, label, package? } with any other key refused 400 before the catalog is read. The two unit pins assert the save request's exact key set and that the value equals the source's Object.keys(objects).
• Dogfood evidence is the dev's local reading, not CI's. The Dogfood Regression Gate shards are skipped on a pull request (the aggregate job reports success with every shard skipped), so the formerly red case a platform set ... copies into its shipping package's pair is green on this head only by the PR body's 34/34 reading. The unit pin that stands in for it in CI is the new metadata-protocol case (protocol.unknown-grant-object-refusal.test.ts:368), which drives the real saveMetaItem with an unregistered object in the inherited set and asserts both the save and the refusal of a non-inherited key. Judged with what is there.

② Semver level

• Clause-②: yes (widening) — correct, and the reachability claim holds in the tree: @objectstack/metadata-protocol's index.ts exports ObjectStackProtocolImplementation; its saveMetaItem(request: SaveMetaItemRequest) (protocol.ts:10712) is typed by the non-exported alias in protocol-door-requests.ts, which gains inheritedGrantObjects?: readonly string[]. The key is therefore in the . entry's type graph as a new optional member of a public method's parameter: a widening, nothing narrowed.
• Metadata-protocol: none — correct: no authorable key, value or type moves; packages/spec is untouched.
• Changeset levels: @objectstack/plugin-security patch (Clause-②: no, Metadata-protocol: none → patch); @objectstack/metadata-protocol patch and @objectstack/runtime patch (Clause-②: yes (widening) with Metadata-protocol: none → a non-protocol widening ships patch). All three follow the rule.
• Declaration lines: the PR body's two lines are byte-identical to .changeset/30255-clone-inherits-held-grants.md's. .changeset/30108-member-default-feed-grants.md carries its own Clause-②: no line, unchanged from the reviewed landing and true for the package it versions; the body states the PR-wide maximum. Noted, not a finding: the fleet's reader takes one declaration per body and one per changeset, and each is accurate for what it covers.
• Spec parity, observation only: the spec's SaveMetaItemRequestSchema (protocol.zod.ts:1103) and the MetadataProtocol.saveMetaItem signature (protocol.zod.ts:4512) do not declare the key. The local request type already carries two server-only keys the schema does not (source, storedParentVersion), so this follows the tree's precedent; and keeping a server-derived key OUT of the wire schema is the safer posture, since a future door that parses a body with that non-strict schema strips it. The protocol.test.ts:2566 comment that lists the implementation's parameter type as its measure is now further behind; not this PR's to move.

③ Boundary flags

From the #30108 dev report (6647979158), all re-landed unchanged in commit 1:

1. Condition 1's premise ("member_default also reaches everyone, externals included") was measured false — org_external holds no everyone anchor and resolves external_default — reported as a corrected premise, not a fork. The integration test's block 3 pins it on the real resolver, and the ruling's intent (the grant widens nothing for an external) holds.
2. enable.feeds: false gates create and re-thread, not read, before and after the grant; open question answered A (land as is) and the residual recorded in the seat's ACCEPT, not a new card. Unchanged here; still the one documented residual of ruling A.
3. dispatch-gates --commands run without paths; 4. the teardown fixture fetched at depth 1; 5. the full build for two dist-reading gates ran outside os-verify-lock; 6. write budget 4 not 3. Process deviations with no effect on the tree.

For #30255 (this PR's second commit): the card's claim (6649260029) declared Clause-②: no — expected ... the dev re-declares if measurement says otherwise; the PR re-declares yes (widening) with the measurement, as the claim provided for. The claim's file surface named the clone door and/or the refusal plus tests and one changeset; the diff adds the refusal's wiring (protocol-door-requests.ts, protocol-save.ts, protocol.ts) and restores the second changeset — both inside "whichever the measurement names" and the re-land. Every ⛔ of the claim holds: the dogfood test is not in the file list, member_default's two rows are byte-identical, no packages/spec, ui, skills, docs/adr or .claude path. The body's pnpm lint and derived-gate readings are said to be "in the seat hand-off", which this review does not read; the head's Lint & Repo Gates success stands in for them.

④ Design judgment

Security first — can any external caller set inheritedGrantObjects? No, at this head. Every .saveMetaItem( producer outside tests was read (15 sites):

• PUT /api/v1/meta/:type/:name, REST door (packages/rest/src/meta-item-write-routes.ts:341): the request literal is typed TransportScopedMetaRequest of the SPEC's SaveMetaItemRequest, which has no such key, so the key cannot even compile into this door; it spreads only saveOptions.request, a closed Pick of parentVersion | mode | surface built by metaSaveRequestOptions from If-Match / If-None-Match / ?mode / ?surface (meta-save-request.ts:118), never the body.
• PUT /meta on the runtime dispatcher (packages/runtime/src/domains/meta.ts:1607): built field by field, the same closed saveOptions.request, item is data.
• Clone door (permission-set-clone.ts:546): the one producer of the key; its body is closed (readCloneBody, unknown keys 400) and the value is computed from the set the door read from the security catalog.
• Package duplicate and unmanaged import (protocol-package-commits.ts:768, :934), app un-hide (packages.ts:2249), flow clone (automation.ts:2482), the three stored-row migrations (protocol-save.ts:2554, protocol-packageless-overlay-migration.ts:587/:651, flow-credential-migration.ts:222), the external-table import (service-datasource/plugin.ts:243), the CLI ownership ceremony (organization-ownership.ts:905): each builds from stored rows or server values, field by field; none spreads a body or options object; none states the key.
• No door parses a wire body with SaveMetaItemRequestSchema and forwards the result (its only non-test readers are the spec's own tests); no generic protocol[handler](body) dispatch exists in rest, runtime, adapters or the hono server; no in-tree MCP save producer exists at this head (the mcp surface is refused over HTTP and no in-process MCP caller of saveMetaItem is in the tree). The clone-door host wrapper (protocol.ts:1367) forwards arguments it is handed by server code only.

So the key is server-derived only, as the design requires, and the refusal that #28990 put in front of hand-authored sets still fronts every path a person or client can reach.

Does the clone door pass only keys the source holds? Yes (① third bullet). Should-fix S1: inheritedGrantObjectsOf reads the COPY, so the invariant rests on the copy step never gaining an edit to objects between the catalog read and the save. Derive the set from source.definition.objects instead and the invariant is structural; the two unit pins already compare against the source's keys and would hold unchanged. Not a defect today.

Is the alternative (treat optional-plugin platform objects as known) better? No. A boot without plugin-audit holds no registration for sys_comment, so "known" would need a hand-kept vocabulary of names optional plugins MAY register, maintained in the refusal; it would loosen every door (/meta, publish, restore, import) for those names, and the catch it exists for — a hand-typed grant on a name nothing serves — would stop firing for exactly the names an author is likeliest to copy by hand. The chosen rule is the refusal's own held rule applied to a copy: narrower, and it leaves the source's grant judged where the source introduced it.

Does the fix leave non-clone paths refused, and is that intended? Yes and yes. A fresh hand-authored set granting sys_comment through PUT /meta on a boot without plugin-audit is still 422, with the remedy sentence unchanged ("create the object first, or remove the grant"); a draft's publish and a restore are unchanged; a re-save keeping the grant was already exempt by held. That is the #28990 contract: the grant applies to nothing on that deployment, and the author, unlike the clone door, is adding it now.

Should-fix S2 (follow-up card, not this PR): the package duplicate door (protocol-package-commits.ts:768) and the unmanaged import (:934) also copy a stored permission set verbatim into a new name under mode: 'publish' and state no inherited set, so a stored set that grants on an object of an optional plugin not installed here (saved while it was, or imported) is refused 422 on those doors by the same rule this PR corrects for the clone. Not main-red, not in #30255's surface; the same inheritedGrantObjects mechanism applies and should be filed as its own card rather than widened into this PR.

Tests against the code they cite: the new metadata-protocol case drives the real saveMetaItem with a registry that knows qa_widget only, saves a copy inheriting qa_plugin_object, and refuses a second copy whose qa_typo is not inherited with nothing stored — both halves of the accept-set change, by code, status, path and sentence. The runtime pins assert the save request's exact key set, so the key cannot be dropped or renamed silently. The re-landed plugin-security tests are the reviewed ones.

Check-runs on this head, polled four times over eight minutes, last read at 2026-11-05T05:56Z: Lint & Repo Gates, TypeScript Type Check, Build Core, Governed Surface Queue Guard, Test UI, Live E2E UI, Check Changeset, Check PR Size, PR-body guards success; Lint UI, Type Check UI, Build & E2E UI skipped (no ui/ path); Test Core still in progress (shard 6/8 done, seven shards running); Dogfood Regression Gate shards skipped on a pull request, as on every PR. Judged with what is there: nothing red; the one in-progress required context must be green before the queue, as always.

Implemented-by: session_01Utp6CatT2ajve5PJf1Hhzj
Reviewed-by: session_01Utp6Cbvcmv8YWFhFJwzjKL

VERDICT: PASS

Should-fix (neither blocks): S1 derive the inherited set from source.definition.objects rather than from the copy; S2 file a follow-up card for the duplicate-package and unmanaged-import doors, which copy a set verbatim and state no inherited set.

Generated by Claude Code

domain:server#2 · os-bill · session_01Utp6Cbvcmv8YWFhFJwzjKL

维护者速读

• 改了什么： 两笔。① 按字节原样重新落地 [Decision] Every non-admin member of a new app sees "no permission" for comments and activity on records they can read #30108（member_default 给 sys_comment 读/建/改、sys_activity 读，无删除、无行策略），它曾是 PR fix(plugin-security): every member reads and posts comments, and reads the activity history, of the records they can read #30222，因弄红 main 被 revert: PR #30222 (main red #30255) #30262 回滚。② 修 main red: Dogfood Regression Gate (2/3) fails permission-set-clone-door after PR #30222 (member_default grants sys_comment) #30255 的根因：权限集克隆门把「源权限集本来持有的授权对象键」作为 inheritedGrantObjects 交给保存，保存门的「未知对象授权」拒绝跳过这些键。所以在没装 plugin-audit 的部署上，复制 member_default 不再报 422。
• 为什么改： 没装 plugin-audit 的部署（verify 的 bootStack、showcase）没有注册 sys_comment / sys_activity，克隆 member_default 时撞上 422，dogfood 的 permission-set-clone-door 在 main 上转红。
• 风险与回滚： 放行只发生在克隆门这一处，键由服务端从源权限集读出，任何请求体都写不进来（复审已逐条追过 15 个 saveMetaItem 调用方）。手写的新权限集授权给未知对象，照旧拒绝。回滚即撤本 PR，member_default 回到 revert: PR #30222 (main red #30255) #30262 之后的状态。
• 先看： packages/runtime/src/domains/permission-set-clone.ts 的 inheritedGrantObjectsOf(source.definition)，再看 protocol-save-door-refusals.ts 的 unknown 过滤。
• 两分钟验证： pnpm --filter @objectstack/metadata-protocol exec vitest run src/protocol.unknown-grant-object-refusal.test.ts。
• 需要您做的： 无，席位经合并队列落地（非受管面，733 行）。
• 席位意见： ACCEPT。契约复审 PASS（6650931967），S1 已在 d770fe2 修掉，S2 已建卡 Package duplicate and unmanaged import refuse a copied permission set that grants on an optional plugin's object not installed here (same 422 the clone door had, #30255) #30319。

席位核对 — ACCEPT · domain:server#2 · head d770fe2150f293162ce906de2fb910370edcc6fc

• 形态: draft, author objectstack-fleet[bot] (relay pr_create), no assignee, no review request; 13 files, +709 −24; check-governed-merges --pr 30310: NOT governed (0 of 13 paths), 733 lines ≤ 3000.
• 契约复审: CONTRACT_REVIEW_TIER (served above the declaration face's floor: a permission-baseline change plus a relaxation of a security refusal). PASS 6650931967 on 591198e4: commit 1 blob-identical to 490d136f on all five paths (earlier PASS 6648282410 carried forward); exactly one accept-set change (saveMetaItemUnaudited forwards inheritedGrantObjects; publish, restore and PUT /meta pass none); the key is server-derived only; Clause-②: yes (widening) reachability holds; Metadata-protocol: none.
• 591198e → d770fe2 (seat read): one file, permission-set-clone.ts +13 −11: inheritedGrantObjectsOf now takes the source definition and the call site passes source.definition, so only keys the source holds can ever be passed (closes S1). Docblocks reworded to match. No accept-set change beyond the reviewed one; no further contract review owed.
• Dev readings: os-dev-report 6651655007 on main red: Dogfood Regression Gate (2/3) fails permission-set-clone-door after PR #30222 (member_default grants sys_comment) #30255 (new head, three commits): full build 119/119; dogfood permission-set-clone-door + permission-unknown-grant-object-refusal 2/2 files, 18/18 tests on d770fe2; runtime typecheck and clone-door eslint exit 0; 4 ablations red then restored by blob; derived gates 65, --ran 65 run / 0 NOT-MEASURED; pnpm lint exit 0. [Decision] Every non-admin member of a new app sees "no permission" for comments and activity on records they can read #30108 report 6647979158 (deviations and open question carried as reviewed).
• 门禁 check-runs: 591198e: 35 success, 0 failed. d770fe2 in progress at ACCEPT; auto-merge waits on the required contexts. Dogfood shards do not run on PRs or in the merge queue, so the dev's local dogfood reading above is the evidence for the formerly red case (lesson from fix(plugin-security): every member reads and posts comments, and reads the activity history, of the records they can read #30222).
• 范围外去向: Package duplicate and unmanaged import refuse a copied permission set that grants on an optional plugin's object not installed here (same 422 the clone door had, #30255) #30319 (package-duplicate and unmanaged-import doors, S2).
• 落地条款: Fixes main red: Dogfood Regression Gate (2/3) fails permission-set-clone-door after PR #30222 (member_default grants sys_comment) #30255, Fixes [Decision] Every non-admin member of a new app sees "no permission" for comments and activity on records they can read #30108. Clause-②: yes (widening), Metadata-protocol: none, changesets patch for @objectstack/plugin-security, @objectstack/metadata-protocol, @objectstack/runtime. Ordinary queue landing by this seat: pr_ready + automerge_enable on this head.