[objectstack-fleet]

Requested by 田騏 · project thread

Fixes #27662

Clause-②: no
Metadata-protocol: none

维护者速读

• 改了什么： 外部对象用 columnMap 把远端列映到 owner_id、但驱动没把这列返回时，成员写入被拒的同时，服务器重新打出一行 warn（每个对象一次），点名「驱动没有返回映射的 owner 列」。
• 为什么改： sharing: a private external object whose driver serves owner_id without declaring it in fields gives every member every row — hasPhantomOwnerAnchor reads fields only, so the read filter goes unscoped (epic #27261, found by #27332's dev) #27425 把这种映射算作已证 owner 后，[裁定确认] #8119 的裁定是 A(什么都不做)还是 C(保持 deny + 加诊断)?联邦 phantom 锚上的写门拒绝是完全静默的,且现已知在每个方言上都如此 #8418 的诊断不再触发，运维只看到一个 403，没有任何日志。
• 风险与回滚： 只加日志，判决不变（三个写判决矩阵用例照旧）；回滚即 revert 本 PR。
• 先看： packages/plugins/plugin-sharing/src/sharing-service.ts 的 notePhantomAnchorWriteDeny（新分支按「行里没有 owner_id 键」判定）；同文件新常量 UNSERVED_OWNER_WRITE_DENY_NOTICE；测试文件末尾的 [#27662] 块。
• 两分钟验证： pnpm --filter @objectstack/plugin-sharing exec vitest run src/federated-phantom-owner-scoping.test.ts，预期 57 个用例全绿，其中 [#27662] 块 6 个。
• 需要你做的： 无，席位落地。

What changes

• matchesOwnerScope passes the pre-image row it already read to the [裁定确认] #8119 的裁定是 A(什么都不做)还是 C(保持 deny + 加诊断)?联邦 phantom 锚上的写门拒绝是完全静默的,且现已知在每个方言上都如此 #8418 diagnostic. No new query.
• notePhantomAnchorWriteDeny keeps its phantom-anchor branch byte-for-byte. A second branch fires when the object is federated, is not phantom-anchored, and the row came back with no owner_id key at all. It logs the new exported UNSERVED_OWNER_WRITE_DENY_NOTICE with the same payload (object, ownerField, userId) under the same once-per-object latch.
• The discrimination is the key, not the value. A driver that applies the map and serves a NULL owner is an ordinary owner-less row and stays silent. A missing record (no row) stays silent too.
• hasPhantomOwnerAnchor and federated-phantom-anchors.ts are not touched: the new branch reuses the already-exported isFederatedObject and reads no columnMap itself, so it adds no fourth reader to the set spec: resolveInjectedColumnProvenance does not know the external.columnMap → owner_id arm plugin-sharing honours since #27425, so the #7858 convergence row and the two columnMap readers diverge (epic #27261) #27661 is consolidating.

Tests

New [#27662] block in federated-phantom-owner-scoping.test.ts:

• a map-ignoring plugin driver denies on edit, delete and at org depth, and logs exactly one unserved-owner notice (never the phantom one);
• the wording names the driver and external.columnMap;
• a second object gets its own line, a second caller does not re-arm the first;
• a map-applying driver stays silent on an own row (allow), another owner (deny) and a served NULL owner (deny);
• a declared-owner control stays silent on allow and deny;
• a record that does not exist stays silent.

Acceptance notes

• Wider than "mapped" by design. The new branch also fires for a federated object that DECLARES owner_id when its driver returns rows without that key (for example the SQL driver discarding a projection that names a column the remote table lacks). That is the same operator-facing fault, and the message says "maps (external.columnMap) or declares". The card's declared-owner control (owner present) is silent, as pinned.
• The method keeps its notePhantomAnchorWriteDeny name to keep the diff small; its doc comment now names both notices.

Verification

Readings for head 41cbab7c are in the os-dev-report on the card.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-sharing, touching 4 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/plugins/plugin-sharing/src/index.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

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

• content/docs/releases/v17/17-3.mdx (via SharingService (symbol, a top-level class))
• content/docs/releases/v18/18-1.mdx (via SharingService (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.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/plugins/plugin-sharing/src/index.ts) — pages documenting those are invisible to this run
• the SDK route bridge reached 58 of 210 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 11 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json d7625ea4500aa244c792d55b5d7668c80dbc10fe → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ebdd7f0432b1f637b3c95be92127e272a90f7d98 — the merge of head 41cbab7ca8dd5fff1bef5ea38f186b9877b56e6f into base d7625ea4500aa244c792d55b5d7668c80dbc10fe, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

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

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

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

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 d7625ea4500aa244c792d55b5d7668c80dbc10fe → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

epic:#27261#1 · marchtian · session_017ihL2c5z3q4h8inrn5kwqV
ACCEPT · PR #27760 @ 41cbab7ca8dd5fff1bef5ea38f186b9877b56e6f · 2026-10-29T22:54Z

维护者速读

• 改了什么： 外部对象通过 columnMap 映射（或直接声明）了 owner 列，但驱动返回的行里根本没有这一列时，成员的写入照旧被拒，但服务器重新打出一行诊断，每个对象最多一次，告诉运维是驱动没把 owner 列返回来。
• 为什么改： plugin-sharing: the #8418 phantom-anchor write-deny diagnostic goes silent on a federated object that maps owner_id through external.columnMap over a plugin driver that ignores the map (epic #27261) #27662：sharing: a private external object whose driver serves owner_id without declaring it in fields gives every member every row — hasPhantomOwnerAnchor reads fields only, so the read filter goes unscoped (epic #27261, found by #27332's dev) #27425 之后，这种情况不再算「幻影 owner」，原来的诊断就不响了。
• 风险与回滚： 只是日志，拒绝逻辑完全不变；驱动正常返回了 owner 列、只是值为 NULL 的行仍然不打日志。changeset patch · Clause-②: no。还原即回滚。
• 先看： packages/plugins/plugin-sharing/src/sharing-service.ts 的 notePhantomAnchorWriteDeny。
• 两分钟验证： 单跑 federated-phantom-owner-scoping.test.ts。
• 需要你做的： 无，席位落地。

席位意见：ACCEPT。

席位核对

1. Shape: +171/−8, 4 files, read by the seat. matchesOwnerScope passes its pre-image row to the diagnostic. The new arm keys on a federated, non-phantom object whose row has no owner_id key at all. The pre-image read runs under SYSTEM_CTX, so the sharing scope cannot hide the row and turn the notice silent. null stays silent, and so does a missing row (the record does not exist). The latch is the same, and the verdict is unchanged: return false is untouched.
2. Premise measured: the dev reports plugin-sharing 1296/1296, typecheck exit 0, two ablations red and restored, and 61/61 derived gates with 0 NOT-MEASURED (report 6510399455).
3. Gate check-runs on 41cbab7c: 48 runs: 35 success, 13 skipped, 0 failed or pending. mergeable_state: clean.
4. Accepted deviation: a federated object that declares owner_id and whose driver omits the key also gets the notice. It is the same operator fault, and the message says "maps or declares". No overlap with spec: resolveInjectedColumnProvenance does not know the external.columnMap → owner_id arm plugin-sharing honours since #27425, so the #7858 convergence row and the two columnMap readers diverge (epic #27261) #27661: federated-phantom-anchors.ts is untouched, and the arm reads no columnMap.
5. Out of scope: none.
6. Landing: not governed (check-governed-merges --pr 27760: 179 lines ≤ 3000). No contract face is touched (Clause-②: no, no published schema, not governed), so CI plus this read suffices. One new named export (UNSERVED_OWNER_WRITE_DENY_NOTICE), beside its sibling; by the fix(objectql): a plugin driver's request-shaped read refusal answers 400 INVALID_QUERY with its message, not 503 retry-later #27648 precedent that is no declaration. Landed by the seat through the relay.