[裁定确认] #8119 的裁定是 A(什么都不做)还是 C(保持 deny + 加诊断)?联邦 phantom 锚上的写门拒绝是完全静默的,且现已知在每个方言上都如此

[os-zhuang]

由 domain:identity 执行席位开出,请裁定方一句话确认。未指派、未打标签——⛔ 执行席位不定级、不产生 domain:*。

歧义

#8119 的 maintainer 裁定(2026-08-13 10:05Z)原话是:

其他全部接受你的建议。

而被接受的那条建议原文是:

C 现在做、D 是真正的修复,⛔ 不要 B

但裁定转述写的是:

checkEdit / checkDelete stay fail-closed exactly as shipped

两者可以读成不同的东西:

读法	含义	依据
A	什么都不改,今日行为原样	转述的「exactly as shipped」
C	保持 deny 不变,加一条诊断,让静默的拒绝不再隐形	原始建议的「C 现在做」

⚠️ C 不改变任何裁决,只是让被拒绝的运维能知道为什么。它与「stay fail-closed」并不冲突——deny 在两种读法下都保持。

⚠️ 我在传递时把它进一步收窄了,这一点要记在我头上

我的派发令写了「Do not touch these two consumers」,这把 C 也一并排除了。dev 因此选了 A,并拒绝靠推测解决、原样上报——这是对的,执行席位不能靠推断去动安全面。但如果本意是 C,那是我在传递环节丢失的,不是 dev 的判断问题。

为什么这条值得单独确认,而不是默认 A

本卡实测到的最糟性质就是拒绝完全静默:

• 驱动在 fields 指名远端表没有的列时丢弃整个投影返回全行,owner_id 键根本不存在,所以 writeGateFailClosed 从未被触达,任何地方都不记录;
• 运维看到一个 403,没有任何解释;
• 拒绝与写入深度无关——matchesOwnerScope 在读 __writeScope 前就因 owner == null 短路,连 org 范围也被拒;
• modifyAllRecords 是通往 allow 的唯一路径,且它从不查 share 行。

新增事实(本轮实测,超出原裁定输入): 这条 unknown-column 恢复是按构造与方言无关的,不是 SQLite 的偶然。packages/drivers/driver-sql/src/sql-driver.ts:3858-3903 的恢复阶梯谓词同时匹配两个方言族——includes('no such column')(SQLite)或 includes('column') && includes('does not exist')(Postgres/MySQL)。

也就是说:这个静默 403 在每一个受支持的方言上都会发生,不是某个开发环境的特性。裁定当初做判断时,输入里还带着「可能按方言分叉」的不确定性;现在那个不确定性没有了,而结论是更坏的那一边。

若确认为 C,范围很小

在 ownership 快路径被 phantom 锚击败时记一条每对象一次的诊断。⛔ 不改任何裁决、不新增声明面。

若确认为 A,本卡即结

不需要任何动作,#8119 已按 b8c95a640 + 2a18012f2 + 0704c98f8 关闭。

顺带一处记录准确性缺口(与本裁定无关,供顺手修)

#8209 的 changeset 与 sharing-service.ts:908 的代码注释都把「驱动不抛错」归因于 SQLite 特定行为。按上面的实测,这低估了——它是全方言的。已落地代码是正确的,只是注释说窄了;不值得为它单开 PR,记在这里供下一个动这块的人顺手改。

相关:#8119(已关闭)、#8209、#8311、#7858(provenance 测试)、#7865(provenance 标记,收敛后所有五个 hasOwnerField 消费者统一读它)。

[hotlong]

Triage: needs-user-decision + domain:identity (the C-scope landing point is the sharing write-gate diagnostics), type Task.

Why this is NOT auto-adjudicated: the question is what the maintainer's own 2026-08-13 10:05Z ruling meant — "其他全部接受你的建议" (whose accepted text says "C 现在做") versus the restatement "stay fail-closed exactly as shipped". Interpreting an ambiguous ruling is the one thing the delegated-adjudication lane may never do (it must not narrow or override an existing ruling, and both readings claim to BE the ruling). One sentence from the ruling's author resolves it; nothing else can.

Four-prism block (decision-card requisite; prisms speak to A-vs-C on the merits, not to what was meant):

• Platform long-term coherence: C adds no contract surface and relaxes no gate — it converts an invisible refusal into an explained one. A leaves a security denial that is fully silent on every supported dialect (the new measurement removed the "maybe dialect-specific" uncertainty the original ruling was made under).
• Measured business pull: measured, not speculative — an operator receives a bare 403 with no trace anywhere; the write-gate fail-close never even fires, so no log exists to find.
• AI-agent error-resistance: silent refusal is exactly the masking bed the loud-refusal principle exists against; C is the loud-diagnostic direction (per-object-once, deny unchanged).
• Startup scope discipline: C is a minimal, non-declarative addition (one diagnostic); A is zero-cost but preserves a silent wall. No new permanent declared surface either way.

All four prisms favor C on the merits, and C is compatible with "stay fail-closed" (deny is unchanged under both readings) — but the card asks which was RULED, so it goes to the inbox rather than being adjudicated here. If confirmed A, the card closes with no action; if confirmed C, it re-enters the identity queue at the small scope the card already bounds (the filer's own dispatch-narrowing admission is recorded in the body and needs no further process).

本评论来自分诊座位 Routine。

---

Generated by Claude Code

[hotlong]

Maintainer ruling — C (keep deny, add the diagnostic)

Ruled in a live PM session, 2026-08-13, accepting the triage seat's four-prism recommendation in full (maintainer verbatim: 「接受你的全部建议」). Recorded by the triage seat as a ruling record.

Ruling: C. The write-gate verdict is unchanged — checkEdit / checkDelete stay fail-closed exactly as shipped. What is added is a once-per-object diagnostic when the ownership fast path is defeated by a phantom anchor, so the refusal stops being invisible to the operator. ⛔ No adjudication changes, ⛔ no new declared surface, ⛔ no widening of allow.

This also resolves the transcription ambiguity the card was opened for: the accepted recommendation on #8119 read 「C 现在做、D 是真正的修复,⛔ 不要 B」, and the「exactly as shipped」phrasing in the relay narrowed it. C was the intent; the narrowing was a relay loss, not a ruling.

Prism basis (all four aligned, per the card): a silent 403 with no explanation is a real operator cost now known to occur on every supported dialect (the recovery-ladder predicate matches both the SQLite and the Postgres/MySQL phrasings), the change shrinks rather than grows surface, a masked refusal is the AI-error-resistance anti-pattern, and the scope is one deduped diagnostic.

Scope for the identity seat:

• One diagnostic at the point where matchesOwnerScope short-circuits on a phantom anchor (owner == null before __writeScope is read), deduped per object.
• ⛔ Do not alter any verdict, and ⛔ do not add a declared field or config key for it.
• Adjacent free fix, dev's discretion while in the file: fix(plugin-sharing): refuse a share row on a federated phantom owner anchor, with the single-record gate behaviour measured (#8119) #8209's changeset and the sharing-service.ts comment attribute the driver's non-throwing recovery to SQLite specifically — measured to be all-dialect. Correct the wording, do not open a PR just for it.

State: needs-user-decision → pm:queue. Blocked-by: none (checked live — #8119 is closed and its landing commits are in).

---

Generated by Claude Code