recall(): the ruled hard retract cannot be built under #10753's constraints — two independent measured blockers, raised per that ruling's own fork clause

[os-sam]

Filed by the domain:services execution seat (session_01APWX2AwT3a4xDcjPCe8bk4) executing #10753's ruling, not appealing it. That ruling ends with its own escape hatch, verbatim:

adding a provenance column to an engine-owned platform object is NOT approved by this ruling (raise it separately if the implementation truly cannot proceed without it — that is the fork clause).

The implementation measured that it truly cannot proceed. This card is that raise.

What already landed, so this card is not read as "the feature failed"

PR #11450 (Part of #10753) landed the authenticated-user scoping half the ruling named — markReadAsCaller(caller, ids) / markAllReadAsCaller(caller), which take no target user: the recipient is derived from ExecutionContext.userId, so "mark someone else's inbox read" has no spelling on the plugin-facing surface. No new column, no packages/spec edit.

⭐ That closes the reported symptom. The card was filed for a single-approver flow, and there the approver who clears the request is the recipient whose badge is stuck — the hook runs inside exactly the identity the new surface reads. recall() only becomes necessary for multi-approver fan-out, which #10753 does not evidence.

⇒ Nothing is on fire. This is a decision about a ruled verb that has no buildable form today.

Blocker 1 — authorization: recall is an EMITTER-side verb, and emitter-scoped ≠ authenticated-scoped

The ruling anchors the implementation on the authenticated axis. On that axis the only expressible predicate is "the caller is one of the recipients", which yields a recipient-scoped retract — not the ruled hard recall across all recipients.

⛔ Shipping that under the name recall was refused deliberately, and the reason is worth keeping:

Naming a recipient-scoped dismiss recall is precisely the shape that makes AI-written hooks wrong with confidence — the author reads "recall" and believes the message is gone for everyone.

Emitter provenance does not exist anywhere, measured:

surface	what it carries
sys_notification	topic · payload · severity · dedup_key · source_object · source_id · actor_id · created_at
sys_inbox_message	no emitter column
EmitInput	no emitter field
kernel DI	one shared PluginContext (core/src/kernel.ts:65,:91); getService carries no caller identity

⚠️ actor_id is the user who caused the event, not the emitting plugin. ⛔ Pressing it into service as provenance would be wrong and would look right.

Blocker 2 — mechanism: there is no cancellation expression, and the thing that looks like one is a race

Independent of any column. INotificationOutbox declares exactly enqueue | claim | ack | list | claimDigest. The ruled hard recall's "cancel pending/unclaimed deliveries" step has no site.

⚠️ And it is worse than simply absent:

ack(id, { success: false, suppressed: true }) would appear to work — neither MemoryNotificationOutbox.ack nor SqlNotificationOutbox.ack checks that the row was ever claimed — but it races claim() with no compare-and-set, and increments attempts on a delivery that was never attempted.

⇒ An implementer reaching for the obvious workaround gets a silent corruption, not a refusal. Tracked on its own terms as #11453, because it is a standing contract gap whatever happens to this card.

⭐ Why the two blockers together change the shape of the decision

Granting the provenance column does not unblock recall. Blocker 2 still requires widening INotificationOutbox, which is an unrelated contract decision.

⇒ Deciding them in one stroke would settle two independent questions under a ruling framed about one column. They are separated here on purpose.

Options

1. Defer recall until there is measured pull. Cost: markRead is authenticated-scoped and safe; the multi-approver fan-out case stays unserved, and Console 顶栏铃铛未读角标在审批处理完成后不更新 #10753's Q2 stays formally unimplemented. Nothing degrades.
2. Approve emitter provenance (emitter on EmitInput → emitter_id on sys_notification) and rule the outbox cancellation contract. Cost: a provenance column on an engine-owned platform object — which the Console 顶栏铃铛未读角标在审批处理完成后不更新 #10753 ruling explicitly withheld — plus a widened INotificationOutbox; legacy NULL emitter_id rows become closeable by nobody (acceptable under 90d retention, but should be ruled out loud rather than defaulted).
3. Redefine the verb honestly — ship the recipient-scoped retract under a name that says so (dismiss, not recall). Cost: it does not serve the emitter case at all; it is a different feature wearing the honest name.

[facets-block]

• 实际业务需求 — 已报告的症状(单审批人)已被 feat(messaging): scope the plugin-facing inbox writes to the authenticated caller #11450 关掉;recall 只服务多审批人扇出,而卡面没有该场景的证据。⇒ 拉动为未测量,不是零,但也不是已证实。
• 项目长远合理性 — 阻塞 2 是一条真实的契约缺口(ack 在未 claim 行上静默成功且竞态),它独立于本卡存在,应当按自己的条件裁,而不是被一次关于「一根列」的重裁顺带决定。选项 2 把两件不相干的事绑在一起。
• 防 AI 写代码犯错 — ⛔ 选项 3 若沿用 recall 之名是最危险的:作者读到「撤回」会相信消息对所有人消失。若取 3,名字必须改。而选项 2 的溯源列给 AI 一条可机械遵守的模式(emit 时留句柄、办结时按同一句柄撤回),写错自己的 id 会响亮失败。
• 创业阶段不扩散需求 — 选项 1 面为零。选项 2 同时动engine-owned 平台对象与一条服务契约,是本卡里最大的一次扩面,而拉动尚未测得。

推荐:1(暂缓),并把 #11453 作为独立契约卡按自己的条件推进。 若将来出现多审批人扇出的真实拉动,再以那份拉动为依据重开选项 2 —— 届时溯源列的代价有具体收益可对照,而不是为一个假设付账。⛔ 本席不代裁:给 engine-owned 平台对象加列、以及历史 NULL 行「无人可关闭」是否可接受,都是产品与数据模型决定。

Refs

#10753(裁决与 fork clause)· PR #11450(已落地的认证作用域半边)· #11453(阻塞 2,独立契约缺口)· #11452(读侧同形缺陷:listInbox(userId, …) 允许任何插件读任何用户的收件箱)· ADR-0103(回执为无上下文裸引擎写入)

[claude]

决策箱勤务补块(分诊席,session session_01Kktexqp6uVuFMztvvTMf3V,2026-08-24;卡内两条实测阻断为据)。一句话问题:裁决要的「撤回通知,对所有收件人生效」今天造不出来 —— 系统根本不记「这条通知是谁发的」,而记录发件人需要动一张平台核心表,那正是原裁决明说「另行上报」的事。本卡就是那次上报。

选项 × 真实代价:

• A. 批准加发件人来源列(engine-owned 平台对象 + EmitInput 契约扩面):硬撤回可建。代价:平台表结构 + 契约两处永久扩面,为一个今天没有业务实例的场景(多审批人扇出)。
• B. 收件人侧「本人清除」换个诚实名字(不叫 recall):单审批人症状已由 feat(messaging): scope the plugin-facing inbox writes to the authenticated caller #11450 关闭,此为零新增。代价:「撤回」这个动词从产品词汇表消失。
• C. 挂起 recall 动词,等多审批人扇出出现真实证据再回来:今天不动任何表。代价:卡留档,动词悬置。

四棱:① 长远:A 的来源列本身是干净方向(审计友好),但为未证需求预建结构违背 implementation-first。② 业务拉动:零 —— 报告的症状(徽章卡住)在单审批人流里已被 #11450 关闭;多审批人扇出无实例。③ 防 AI:卡内引文已说透 —— 把「本人清除」命名为 recall 是让 AI 自信写错的形状,B 若采必须换名;C 不引入任何可误用面。④ 创业:C 是唯一零扩面选项。

推荐 C(关本卡 not planned 留档,recall 动词在多审批人扇出有真实用户证据时随新卡重开,届时 A 是预登记方向);回退 B(换名)。置信缺口:未测企业侧(树外)是否已有多审批人扇出在用 —— 若有,推荐翻转为 A。回「C」/「A」/「B」即可。裁后执行:C ⇒ 关卡引本块;A ⇒ 立契约卡走 spec 席条款②档。

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded — Option 1: defer recall; closing not-planned

Provenance: maintainer, 2026-08-24, live PM chat, batch acceptance, verbatim: 「四维分析一致的，接手你的建议。」 The facets block in the body is aligned on option 1, so 1 is adopted.

Ruled: recall is deferred until measured pull exists. The reported symptom is already closed by PR #11450 (authenticated-scoped markReadAsCaller); the multi-approver fan-out case stays unserved knowingly; #10753's Q2 remains formally unimplemented by decision. #11453 (the outbox ack-races-claim contract gap) proceeds on its own merits, independently — this ruling neither blocks nor licenses it. No emitter-provenance column is added to sys_notification (option 2 declined for now), and no recipient-scoped verb ships under the name recall (option 3's hazard stands recorded).

Closing not planned per the hold discipline (no mechanizable restart trigger exists). Reopen condition, recorded: a real report of a stuck unread badge in a multi-approver approval flow — that measured pull reprices option 2 with a concrete benefit to weigh the provenance column against. Downstream: any Blocked-by: #11454 line (e.g. on #10753) unlocks via the standard scan; the services seat re-verifies on current refs before acting.

---

Generated by Claude Code