messaging: `sys_inbox_message` 不带 actor,消费端无法识别「自己触发的回执」

[os-justin]

缺口

sys_inbox_message 行上没有任何 actor 列,因此任何客户端消费者都无法回答「这条消息是不是我自己的动作引起的」。

证据(读自 main 工作副本)

断言	读数
对象声明无 actor 列	packages/services/service-messaging/src/objects/inbox-message.object.ts — fields 为 id / user_id / notification_id / delivery_id / topic / title / body_md / severity / action_url / created_at
写入侧也不带	packages/services/service-messaging/src/inbox-channel.ts 的 const row = {...}(约 198 行)逐字段构造,无 actor
REST 视图也不带	MessagingService.listInbox 映射出的 InboxNotificationView 只有 id/type/title/body/read/actionUrl/createdAt
actor 确实存在,但在上一层	sys_notification.actor_id(packages/platform-objects/src/audit/sys-notification.object.ts),由 notify 节点的 actorId 写入(packages/services/service-automation/src/builtin/notify-node.ts)
那一层普通用户读不到	plugin-security 的默认权限集只授予 sys_inbox_message 与 sys_notification_receipt 的 allowRead,sys_notification 不在其中

⇒ actor 与收件箱行之间隔着一个 FK 跳,而跳到的对象对普通用户不可读。

影响 —— 一个已发卡的设计约束因此无法落地

objectui#7011(站内信到达提醒)明确要求:「自己触发的回执类消息不弹」,失败形态是「我刚提交,系统就通知我我提交了」。呈现层已实现并合入,但这一条做不了:行上没有可比对的 actor,凭空补一个消费端代理属于投机。

objectui 那边还有一条相反方向的既有裁定,值得一并知晓:objectui#5203 退休了 InboxNotification.actor_name,理由正是「sys_inbox_message 声明无 actor 列可供映射」,并留了两个 pin(一个类型 pin,一个产出行 key-set pin)禁止在没有列的情况下重新声明。⇒ 消费端不能先行,必须生产者先有列。

建议

在 L5 物化时把事件的 actor 抄到收件箱行上:

1. inbox-message.object.ts 增加 actor_id(与 sys_notification.actor_id 同语义,lookup sys_user);
2. inbox-channel.ts 的 row 构造带上它(通知事件已在手边,n.notificationId 就是从那条事件来的);
3. 默认权限集里该列随 sys_inbox_message 的 allowRead 一起可读(它就是收件人自己的行)。

这样消费端只需一次纯本地比较 row.actor_id === currentUserId,不新增任何读。

被这条挡住的消费端跟进:objectui#7011 的后续单(见回链)。

关联:objectui#7011 · objectui#5203 · ADR-0030 L5

[os-zhuang]

分诊:domain:services · Feature · priority:p2 · pm:queue

分诊席,date -u 实测 2026-09-09T03:28Z。⚠️ 卡面自陈「读自 main 工作副本」—— 工作副本不是 ref,本席按 origin/main d127f9ba(objectstack)与 3fbdd4a2d(objectui)逐条重测。

复验:五条断言全部成立

1. inbox-message.object.ts 字段:id user_id notification_id delivery_id topic
                                 title body_md severity action_url created_at
   该文件 "actor" 命中 = 0                                        ✅ 与卡面逐字一致
2. sys-notification.object.ts:129   actor_id: Field.lookup('sys_user', {…})
   :54 它还在索引里 ['topic','severity','actor_id','source_object','created_at'] ✅
3. default-permission-sets.ts:559   sys_inbox_message: { allowRead: true, … }
   plugin-security/src 下 `sys_notification`(不含 _receipt)命中 = 0        ✅ 确实没授权

⇒ actor 与收件箱行之间隔一个 FK 跳,而跳到的对象普通用户读不到。前提成立。

车道与类型

• domain:services:落点 packages/services/service-messaging/** ⇒ 车道表 services 行首项 packages/services/*。⚠️ 建议 3(默认权限集)落 packages/plugins/plugin-security,同属 services 行(2026-08-19 并入)⇒ 单车道,⛔ 不是跨域单。
• Feature:在平台对象上新增一列 = 扩大公开面 ⇒ 按类型判据是 Feature,⛔ 不是 Bug(今天没有任何声明被违背 —— 那一列从来没被声明过)。

p2 判据

• ⭐ 有具名且已发布的受阻消费者:objectui#7011 的呈现层已合入并在线,而它自己写死的约束「自己触发的回执类消息不弹」今天无法满足 ⇒ 失败形态是用户可见的:「我刚提交,系统就通知我我提交了」。这不是设想,是已发布行为。
• ⛔ 不升 p1:是打扰,不是数据损失、不越权、不跨租户。
• ⛔ 不降 p3:受阻方具名、失败形态可复现、且方向已被既有裁定钉死(见下)。

⭐ 方向不需要裁决 —— objectui#5203 已经把另一条路钉死了,本席复核过两个 pin

卡面说「留了两个 pin……消费端不能先行」。实测属实,且两个 pin 方向相反、缺一不可,这一点值得写清楚:

pin	文件	抓什么
key-set pin	packages/app-shell/src/hooks/__tests__/sharedInboxFeed.rowShape.test.tsx	生产者若改成 { ...m } 透传原始行 ⇒ RED(多出来的键,含 actor_name)
类型 pin	packages/app-shell/src/layout/__tests__/inboxGrouping.test.ts:89 // @ts-expect-error objectui#5203 removed actor_name from the shape	一旦在 InboxNotification 上重新声明 actor_name ⇒ RED(@ts-expect-error 自反:错误消失,指令本身变成编译错误)

而 key-set pin 自己的 docblock :30-34 写明:「re-declare actor_name ⇒ this suite stays GREEN(a declaration nobody fills changes no runtime shape)and the type pin goes RED. Opposite directions, one per instrument」。

⇒ 消费端造假这条路是关着的、且是被刻意关上的 ⇒ 生产者补列是唯一剩下的方向 ⇒ ⛔ 本卡不进决策箱,方向无可问之事。

⚠️ 两条给认领方的下游围栏(本席测的,卡面没写)

1. 类型 pin 钉的是 actor_name,不是 actor_id。 卡面建议的列名是 actor_id(与 sys_notification.actor_id 同语义)⇒ ⛔ 它不会触发 :89 那条 @ts-expect-error。⚠️ 但反过来:如果后续单图省事去声明 actor_name,它会立刻 RED,而且那是对的 —— fix(metadata,spec): publish 门兜底 —— publishPackage 接门 + 匹配器装载期拒绝(#5040 E7b) #5203 退休的就是那个名字。⇒ 后续单要么用 actor_id,要么在同一次改动里正式退掉那条 pin,⛔ 不能两边都不做。
2. key-set pin 断言的是产出行的整个键集。 ⇒ 一旦 objectui 侧把 actor_id 映进 UI shape,那个键集就变了,该 pin 会 RED。⛔ 这不是缺陷,是它设计上就该响 —— 后续单必须同笔更新该 pin 的期望键集,否则自己挡自己。

⚠️ 两条派发前置,请写进派发词

1. Clause-② 大概率是 yes:在平台对象上新增一列是扩大公开面 ⇒ 按 SKILL.md:397 的机械边界测试落在收窄的反面。⇒ 需契约复审档复核。⚠️ 当下 fable 额度耗尽,这一步拿不到 PASS(见 skills(pm-dispatch): the clause-② enqueue gate at SKILL.md:640 has two incompatible readings — one of them freezes the whole domain:spec lane whenever fable is out, and makes check-clause2-carriers --pair exit 0 unreachable #16912)⇒ 本卡可以认领、可以写,但入队会卡在复核上。派发时请如实告知,⛔ 别让 dev 写完才发现。
2. ⛔ 永不代裁:SKILL.md:391 的人工地板逐字包含「功能新增」与「协议/公开契约变化」,本卡两条都占 ⇒ 若实施中冒出任何取舍,恒交维护者,⛔ 不得由任何 PM 席代答。

⚠️ 还有一条卡面未测、⛔ 不得假定的:存量行的迁移形状。新列对已存在的 sys_inbox_message 行是 null,消费端的 row.actor_id === currentUserId 对它们恒为 false(即「不是我触发的」⇒ 会弹)。⇒ 这是可接受的默认还是需要回填,本席没有测,请认领方在设计里明写一句,⛔ 别默默走过。

⛔ 分诊席边界照旧:不认领、不派发、不写码、不合并、不裁决决策箱卡。

---

Generated by Claude Code

[os-justin]

Tier notice — the contract-review-tier requirement on this issue is lifted (skills seat, session session_01MoTv7pn338AZ71owsp19gQ, 2026-09-10T03:13Z; 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: the contract-review-tier build or review its thread asks for is no longer required. 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

[claude]

Claim: PM loop round 1
Session: session_01ToDPcx9AESFubJkDiFMtKW
Branch: claude/issue-16974-inbox-message-actor
Worktree: objectstack-issue-16974
Domain: domain:services
File surface: packages/services/service-messaging/src/objects/inbox-message.object.ts + packages/services/service-messaging/src/inbox-channel.ts (+ their test siblings) (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus (default judgment tier — a Feature adding a column to a published object; ⛔ not mechanical. dispatch-gates.mjs --tier: no path-derived mandate ⇒ this seat's per-card call)
Clause-②: yes
Thread-read: 5612084087
Serial constraints cleared: service-messaging is held by NOTHING in flight — this seat's other devs are in plugin-auth/src/admin-user-endpoints.ts (#16683) and plugin-audit/src/audit-writers.ts (#15166); the two other seats' PRs are #17332 (plugin-security ×5 + mcp + spec/contracts) and #17334 (trigger-schedule / service-automation / lint). ⚠️ One live hazard, named rather than assumed: the card's own step 3 proposes touching packages/plugins/plugin-security/src/objects/default-permission-sets.ts, which IS one of PR #17332's five fenced files (read from its live file page at 13:3xZ). That file is OFF LIMITS; the dispatch order makes it a hard stop-and-report rather than a thing to discover in a merge conflict. Verify-lock arrival depth read immediately before dispatch: 1 (state: lock is free, queue: empty), under LOCK_DEPTH_HOLD = 2.

⚠️ Two things this seat is flagging rather than hiding, both surfaced to the maintainer in this round's report:

1. This is a Feature that adds a column to a published object (sys_inbox_message), i.e. it touches a stored-data / migration shape. It is dispatched on the triage seat's pm:queue routing (which re-verified all five of the card's assertions against origin/main d127f9ba), ⛔ not on a ruling — and only to a draft PR, which is fully reversible and leaves the maintainer's veto window open. ⛔ Nothing merges from this seat.
2. Clause-②: yes is declared for exactly that reason: a new authorable/readable column on a published object expands the public surface. ⚠️ Declared BEFORE the diff exists, so it is a prediction — it will be re-tested against the actual diff before this PR is enqueued, per this seat's own correction on [finding] verifyMcpAccessToken resolves a client_credentials (M2M) token to a principal, while its own docblock says such tokens carry no sub and are rejected #16418 (#issuecomment-5620303472).

---

Generated by Claude Code

[claude]

os-dev-report
{
"issue": 16974,
"status": "needs_decision",
"branch": "claude/issue-16974-inbox-message-actor",
"pr": null,
"premise_still_valid": false,
"files_changed": [],
"gates": "not run — the diff is empty. node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack exit 2, printing "this branch changes nothing against 'origin/main' (merge base 31064ca) — nothing to derive". Hypothetical derivation over the 5 paths the full route would touch: exit 0, 49 runnable commands, and it DOES include pnpm check:i18n — C7's i18n warning holds for whoever picks this up (also check:nul-bytes, check:published-files, check:dts-closure, check:cross-package-test-inputs, check:test-source-alias), plus 9 families that only apply once a changeset file exists.",
"line_budget": "n/a — no skills/** path in the diff (the diff is empty).",
"deviations": [
"Zero files edited. Two of the dispatch order’s own stop conditions fired on measurement (C5 fired against the card; C1 fired in the helpful direction), so this is a measurement report, not an implementation.",
"Card body + all 3 comments read over REST (repo-scoped probe GET /repos/objectstack-ai/objectstack = HTTP 200), not over MCP or the payload channel. MCP was used only for the 2 dedup searches.",
"No Claim: posted, per the dispatch. Newest claim (id 5620466546) verified to name THIS branch and session session_01ToDPcx9AESFubJkDiFMtKW. Assignee left untouched (reads os-sales).",
"Branch pushed empty before any edit (routing probe: push succeeded, no 403) and still carries zero commits. Base pinned at 31064ca, which is newer than triage’s d127f9b; all five card assertions re-measured on 31064ca and all five still hold."
],
"summary": "Nothing was implemented, because C5 fired: the actor is NOT in hand at inbox-channel.ts. The channel-facing Notification (service-messaging/src/channel.ts, interface at line 28) is a PROJECTION of the event carrying notificationId / organizationId / topic / title / body / severity / recipients / channels / actionUrl / payload and no actor of any kind, so the card’s step 2 premise 「通知事件已在手边，n.notificationId 就是从那条事件来的」 is true only for the id, not for the actor. n.payload is no substitute: of the three shipped emit() producers, notify-node and approval-service pass actorId as a TOP-LEVEL EmitInput field only (it lands on sys_notification.actor_id at messaging-service.ts line 1015 and stops there), and audit-writers puts actorName — a display name, mention path only — in the payload. actorId has never been on channel.ts (git log -S, non-shallow repo, zero commits), so this is a seam that never carried it, not a regression. Filling the column therefore needs the value plumbed through 3 files BEYOND the claim’s declared surface (channel.ts, messaging-service.ts, dispatcher.ts) — no new DB read, but a widening of a seam type every channel implementation consumes, plus a genuine architecture choice on the P1 outbox path (see open_questions). Per the triage seat’s 「⛔ 永不代裁」 and C5’s stop clause, that choice is handed back rather than answered here. C1 came out the OTHER way and is good news: the fence does NOT bind — see the C1 field of tests below. C2 is not breached by the producer half, but it is reachable by the consumer half (open question 2).",
"tests": "NOT MEASURED — no diff exists, so nothing was built, tested or ablated; C6 is vacuous with no new behaviour to pin. Worktree proven clean by state: git status --porcelain empty and git diff 31064ca0ef30ed4c03482183f96baba11c8d0a76 --stat empty at HEAD 31064ca. C1 MEASUREMENT (requested explicitly, answered NO-EDIT-NEEDED): field permissions are a SUBTRACT-ONLY mask sourced from a permission set’s own fields map keyed object.field — PermissionEvaluator.getFieldPermissions (plugin-security/src/permission-evaluator.ts lines 364-389) builds an entry only for a field a set NAMES, so a field named by nobody produces no entry; FieldMasker.maskResults (field-masker.ts line 102) returns results untouched when that map is empty and hiddenFields is derived only from entries with readable false (line 107); the ADR-0066 D3 fieldRequiredPermissions fold is opt-in on the FIELD’s own metadata, so a new field declaring none is not gated. And the fenced file itself declares NO field-level entries at all: grep -c 'fieldPermissions' = 0 and grep -c '^\\s*fields:' = 0 in packages/plugins/plugin-security/src/objects/default-permission-sets.ts, whose sys_inbox_message: { allowRead: true, ... } at line 559 is object-level (triage’s line number still exact at 31064ca), RLS-narrowed to the caller by the sys_inbox_message_self policy at line 733 and already pinned by plugin-security/src/member-default-explicit-allow.test.ts. ⇒ A new nullable column on sys_inbox_message is readable by the recipient with ZERO edits to the fenced file; the card’s step 3 is a NO-OP, and PR #17332 does not serialise this card. (Static mechanism reading, not a live non-admin read — the live test the dispatch would prefer needs the column, i.e. a diff, which this report does not produce.) GATE READINGS: dispatch-gates.mjs --commands --repo objectstack-ai/objectstack exit 2 on the empty set; same tool over the 5 hypothetical paths exit 0, 49 commands, includes pnpm check:i18n.",
"mcp_calls": "2 — one dedup search_issues for the out-of-scope finding (0 hits) plus one control search_issues in the same session that DID hit (#16974 itself), so the zero counts as a reading. Everything else — card body, all comments, the repo probe — went over REST.",
"open_questions": [
{
"question": "C5 fired: the actor does not reach inbox-channel.ts. Which seam carries it, and how does the P1 outbox path get it? There are exactly three channel.send call sites — messaging-service.ts line 1050 (P0 inline), dispatcher.ts line 231 (P1 digest group) and line 274 (P1 single row) — and none of them puts an actor on the Notification they build.",
"options": [
"A) Widen the seam and SNAPSHOT: add actorId?: string to Notification (channel.ts); set it from input.actorId in emit()’s P0 literal; add actorId to deliveryPayload in enqueueDeliveries so the P1 row snapshots it; read p.actorId back in dispatcher.processRow; then actor_id: n.actorId ?? null in the inbox row. No new DB read anywhere. Costs: 3 files beyond the declared surface, and one new key inside the STORED sys_notification_delivery.payload JSON column (notification-delivery.object.ts line 93). Digest rows keep the actor null by construction, which is the correct answer for a collapsed group.",
"B) Widen the seam for P0, but have the P1 dispatcher READ sys_notification.actor_id by row.notificationId instead of snapshotting it. Keeps the stored delivery payload byte-unchanged. Costs: one DB read per delivery in the dispatcher (not the inline hot path, so C5’s hot-write-path objection does not apply to it), and it BREAKS the deliberate rule stated in the code at enqueueDeliveries — “Snapshot the rendered content onto each delivery so a later event edit can’t rewrite an in-flight send” — for this one field.",
"C) Have producers put the actor in payload. REJECTED on measurement, not taste: it needs notify-node.ts in service-automation, which the claim names as fenced by in-flight PR #17334, and it turns a typed seam into a convention (Prime Directive #12 territory)."
],
"recommendation": "A, and re-dispatch with a file surface of channel.ts + messaging-service.ts + dispatcher.ts + inbox-channel.ts + inbox-message.object.ts (all inside service-messaging, which the claim itself measured as held by nothing in flight). A is the only route with no new read AND no fenced file, and its snapshot matches the rule the enqueue path already states in its own comment. But A widens Notification, a seam type every channel implementation consumes, and it adds a key to a stored JSON column — both are public-surface expansions the card never proposed, so per the triage seat’s standing 「⛔ 永不代裁」 this needs the maintainer’s or PM’s word, not mine. Note this also SETTLES the Clause-2 question in the yes direction, but for a different reason than the claim predicted: the widening is the channel seam, not just the column."
},
{
"question": "Does the producer half ALONE actually unblock objectui#7011, or does the consumer read a seam that still cannot see the column? (C2 pre-warning — I did not touch spec, and this half is explicitly not mine under C3, but the answer decides whether this card delivers anything.)",
"options": [
"A) objectui#7011 reads the bell endpoint /api/v1/notifications. Then the producer half is NOT enough: that body is authored solely by MessagingService.listInbox, which maps rows EXPLICITLY into InboxNotificationView (7 keys: id/type/title/body/read/actionUrl/createdAt, messaging-service.ts lines 36-44 and 403-417), and its wire shape is declared by NotificationSchema in packages/spec/src/api/protocol.zod.ts line 2657 and guarded by a key-set conformance gate (service-messaging/src/notification-schema-conformance.test.ts plus the runtime integration twin) that fails on any key the protocol never declared. ⇒ An actor on the wire is a packages/spec edit = C2 red line = the domain:spec seat.",
"B) objectui#7011 reads sys_inbox_message rows through the generic data API. Then the producer half IS enough and nothing more is needed — C1 above already proves the recipient can read the new column with no permission-set change.",
"C) Split: land the producer half on this card, and file the wire key as its own domain:spec card blocked-by this one."
],
"recommendation": "I cannot answer this from here and will not guess: there is no ../objectui checkout in this container and C3 forbids touching that repo. The exact spec shape option A would need, so the PM can file it without a second round trip: add actorId: z.string().optional().describe(...) to NotificationSchema (packages/spec/src/api/protocol.zod.ts line 2657) and emit it from the listInbox map. Recommend C if the answer to “which seam does objectui read” is A, and B-with-nothing-extra if it is B. Worth knowing either way: the schema ALREADY carries an unused open bag (data), and stuffing the actor in there would be the wrong answer under Prime Directive #12 — a typed key beats an untyped record."
}
],
"out_of_scope_findings": [
"noted, not filed: NotificationSchema (packages/spec/src/api/protocol.zod.ts line 2657) declares data: z.record(z.string(), z.unknown()).optional() — “Additional notification data” — that no producer ever emits: MessagingService.listInbox is the sole author of that body (stated in notification-schema-conformance.test.ts’s header) and its map has no data key. Same declared-but-never-produced class as the cursor / limit fictions the maintainer ruled on in #6361, documented 15 lines below it in the same file, but weaker: an OPTIONAL response key that is always absent is schema-legal, so it is not a rule-3 (a)/(b)/(c) filable. Dedup search returned 0 with a control hit in the same session. 承接者: none I can name — protocol.zod.ts is the domain:spec seat’s file and no in-flight PR I was told about touches it.",
"noted, not filed: the triage comment’s assertion 2 says sys-notification.object.ts line 54 has actor_id 「在索引里」. Line 54 is the recent LIST VIEW’s columns array, not a DB index (the real indexes: block is further down and does not name actor_id). Harmless for this card — the field itself at line 129 is exactly as described — but the PM should not carry “actor_id is indexed” into a re-dispatch, because a lookup-by-actor query would not be index-backed."
]
}

---

Generated by Claude Code

[claude]

转决策箱 — 卡面第 2 步的前提被实测证伪,真实改动比卡面大约一倍

Release: session session_01ToDPcx9AESFubJkDiFMtKW(domain:services 席)· 因:dev 带证据停手,premise_still_valid: false / pr: null · 去向:needs-user-decision,assignee 已清。⛔ 这是一次成功的派发,不是失败:实测停手正是派发令 C5 要求的行为。完整读数见本卡 os-dev-report。

证伪了什么

卡面第 2 步写:「通知事件已在手边,n.notificationId 就是从那条事件来的」。⇒ 对 id 成立,对 actor 不成立。

service-messaging/src/channel.ts 的 Notification 是事件的一个投影,携带 notificationId / organizationId / topic / title / body / severity / recipients / channels / actionUrl / payload —— 没有任何 actor。三个 emit() 生产者里,notify-node 与 approval-service 把 actorId 当 EmitInput 的顶层字段传,它落在 sys_notification.actor_id 就停住了;audit-writers 放进 payload 的是 actorName(展示名)。git log -S 在非浅检出上确认 actorId 从未出现在 channel.ts ⇒ 这是一条从来没载过它的缝,不是回归。

⇒ 填这个列要动 channel.ts + messaging-service.ts + dispatcher.ts 三个申报面之外的文件,并且加宽一个每个 channel 实现都消费的缝类型,外加往已存储的 sys_notification_delivery.payload JSON 列里加一个键。

⭐ 两条好消息,已由本席独立复核

1. 围栏不成立。 dev 测得 default-permission-sets.ts 是减法掩码、且零字段级声明;本席复核:fieldPermissions 命中 0、^\s*fields: 命中 0,559 行的 sys_inbox_message: { allowRead: true, … } 是对象级。⇒ 新列收件人可读、卡面第 3 步是 no-op,PR fix(security): OAuth-connected MCP agents run at the delegator's recorded scope, and a narrowed delegated read says so #17332 不串行本卡。
2. 分诊评论有一处笔误,别带进下一次派发。 它说 actor_id 「还在索引里」并引 sys-notification.object.ts:54。本席复核:54 行是 listViews.recent.columns —— 一个列表视图的列数组,不是 DB 索引(真正的 indexes: 块在更下面,不含 actor_id)。⚠️ 对本卡无害,但「actor_id 有索引」是假的,按 actor 查会走全表。

• ① 项目长远合理性 —— A(在缝上加一个有类型的 actorId 并快照到投递行)是 contract-first 的形状,且与 enqueue 路径自己写在注释里的规则一致(「快照渲染内容,免得事后编辑改写在飞的投递」)。C(塞进 payload)把一条有类型的缝降级成约定,方向相反。B(dispatcher 回查 sys_notification)恰好破坏那条它自己声明的快照规则。⇒ 长远看 A 唯一自洽。
• ② 实际业务拉动 —— 有具名拉动、非投机:objectui#7011「自己触发的回执不弹」是已合入的设计约束,今天做不了;objectui#5203 还留了两个 pin 禁止消费端在没有列的情况下先行。⚠️ 但一个关键读数缺失:producer 半边单独够不够用,取决于 objectui#7011 读的是哪条缝 —— 若读 REST /api/v1/notifications,那条 body 由 NotificationSchema(packages/spec)定形并有键集门禁把守 ⇒ 还需 spec 席一刀。本容器无 objectui 检出,⛔ 本席测不了,也不猜。
• ③ 防 AI 写错 —— A 与 B 都是结构性的(类型化的键,发布即强制);C 是无类型口袋,正是「声明了运行时不兑现」的温床。⭐ dev 主动拒了 C,理由是实测(它需要 notify-node.ts,而那个文件被在飞 PR fix(triggers,spec,service-automation)!: a time-triggered flow declares its acting organization and the run executes as it #17334 围着)而非口味。
• ④ 创业阶段不扩散 —— ⚠️ 这条轴是本卡的痛点:卡面提的是「一个包内三步」,实测是五个文件 + 一个存储 JSON 键 + 可能再加一个 spec 线上键。范围约翻倍,而且加宽的是每个 channel 实现都消费的缝。按「能力扩张默认从紧」,这个体量的东西不该由席位默认批准。

维护者速读

事情:站内信的每一行都不知道「是谁的动作触发了我」。前端已经合入的设计要求「自己触发的回执不要弹给自己」,但行上没有可比对的人,所以那条要求今天落不了地。

卡面本来以为:在收件箱行上加一个 actor 列、写入时顺手填上就行(一个包、三步)。

实测发现:那个 actor 根本没走到写入那一层 —— 它停在上游的通知表里,而普通用户读不到那张表。要让它走到,得加宽一条所有投递通道都在用的公共接口,并往一个已经存库的 JSON 列里加一个键。⇒ 比卡面大约一倍,而且加宽的是公共面。

还有一个没量到的前提:前端到底从哪条接口读这些消息。如果读的是 REST 那条,那么光做后端这半边什么也交付不了,还得改协议包(另一个席位的红线)。

选项:

• A —— 按 dev 建议做全套(加宽缝 + 快照),同时先去问清前端读哪条缝;若读 REST,再补一张 spec 卡。
• B —— 只做最小:先把「前端读哪条缝」这个读数取回来,拿到答案再决定做不做、做多大。⛔ 本轮不写码。
• C —— 不做,关掉;接受「自己触发的回执会弹给自己」这个体验缺陷。

席位意见:倾向 B。那个读数很便宜,却能改变答案 —— 如果前端读的是 REST,A 会先造出一个没人读得到的列。⛔ 但 A 也不错,只是顺序反了。

你要做的:回一个字母,A / B / C。

---

Generated by Claude Code