[finding] sys_inbox_message/sys_notification/sys_email 等平台表从不写 organization_id(存量与新增行 100% null)——请确认多组织语义是否设计如此

[baozhoutao]

一句话(人话摘要)

应用项目实测发现:sys_inbox_message / sys_notification(及回执、投递)/ sys_email 等平台表从不写 organization_id——存量与当天新增行 100% 为 null。请平台确认这是设计如此(这些对象按用户域而非组织域)还是缺口;若是设计如此,多组织隔离语义如何界定。项目侧按约定不动这些表的数据,只报备等口径。

环境

• 平台:@objectstack/*@17.0.0(GA,锁版);数据库 PostgreSQL 16(容器部署)
• 项目:os-project-titanwind-ehr 试运行实例;sys_organization 现有 1 个组织

实测观察(2026-08-23,只读 SQL 盘点)

表	总行数	organization_id 为 null
sys_inbox_message	383	383(100%)
sys_notification_receipt	383	383(100%)
sys_notification	205	205(100%)
sys_notification_delivery	205	205(100%)
sys_email	96	96(100%)
sys_audit_log	4485	1510(34%)
sys_activity	3469	916(26%)

关键佐证:

1. 新增行同样不带:sys_inbox_message 按日分布,2026-08-23 当天新增 3 行全部 null——不是存量残留,是持续行为;
2. 对照组:同库 sys_approval_request(32 行)/ sys_approval_approver(1 行)organization_id 均有值、0 null——审批对象有组织戳而消息/邮件对象恒无,疑似口径不一;
3. 业务对象侧(应用命名空间各表)在组织上下文修复后新增行均正确带组织,17.1.0 起无组织写会被拒——sys_* 似豁免于该约束。

想请平台回答的问题

1. 上述消息/邮件/日志类平台对象不写组织是否设计如此(按 user 域路由,不参与组织隔离)?
2. 若是设计:多组织实例下,站内信/通知中心的可见性边界以什么为准?sys_audit_log/sys_activity 的部分行有组织、部分为 null(34%/26%),这种混合态是预期吗(参考:audit: a user's FIRST session predates their membership, so every audit row written in that window carries a NULL tenant and is invisible to RLS readers #8245 处理过首会话窗口的 NULL tenant audit 行)?
3. 若属缺口:应用项目是否应回填?我们默认不碰平台表数据,等平台给口径或修复。

由来

应用项目升级门禁盘点(项目侧 issue steedos-labs/os-project-titanwind-ehr#1750)中顺带发现;业务表的存量 null 组织行(853 行)已在项目侧按批复回填完毕,与本单无关,本单只涉及 sys_* 平台表。

[claude]

分诊落箱(session session_01Kktexqp6uVuFMztvvTMf3V,2026-08-24)。一句话问题:多组织部署里,站内信、通知、邮件这些平台表的每一行都不属于任何组织(实测 100% null)—— 客户项目在等平台一句口径:这是设计,还是缺口。

选项 × 真实代价:

• A. 确认「收件人域」设计:站内信/通知/回执/邮件按用户隔离(收件人就是边界),不按组织;把口径写进对象文档/liveness 记录。代价:一次文档写作;业务上 = 像多数 SaaS 的通知中心 —— 通知跟人走,不跟组织走,跨组织的用户在一个收件箱里看到自己的全部通知。
• B. 判定缺口:通知/邮件应带 organization_id,立修复卡(存量回填另案四棱)。代价:写路径全面改造 + 存量迁移;业务上 = 组织切换时收件箱按组织过滤,安全评审好答但工程大。
• C. defer:不答。业务上 = 报告方(真实医院试运行项目)的安全评审悬着,项目侧不敢动数据。

四棱:

• ① 长远合理性:收件人域是站得住的长期口径(行是「发给某人的」,组织只是发生地);但 sys_audit_log(34% 带组织)与 sys_activity(26%)的混合态两个口径都解释不了,那才是真正的债。
• ② 实际业务拉动:真实部署实测上报、项目在等口径 —— 拉动为实;报告方只求口径不求改造。
• ③ 防 AI 犯错:最危险的是「有的表带有的表不带」—— AI 写报表/清理脚本时按组织过滤会静默漏数据。口径落文档后,AI 至少有权威可查。
• ④ 创业阶段不扩散:A 是零工程收口;B 是为「今天没人要求的隔离语义」预付全面改造 —— 无拉动不扩散。

推荐 A(对 inbox/notification/email/receipt/delivery 五表),并把 audit_log/activity 的混合态单列为后续缺陷卡(谁在写带组织的 1/3、谁在写不带的 2/3 —— 生产者普查);回退 C。置信缺口:本分析未核 RLS/共享读路径是否已有按组织过滤这些表的谓词(若有,A 与现行读路径矛盾,需先测)。回「A」/「B」即可;「A,混合态不立卡」也可。裁后执行:A ⇒ 口径文档卡入 services 队列 + audit/activity 生产者普查卡(finding);并回帖告知报告方口径。

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded — gap, not design: these tables must write organization_id

Provenance: maintainer, 2026-08-24, live PM chat, verbatim: 「11303 sys_inbox_message/sys_notification/sys_email 应该写 organization_id。」

Answers to the reporter's three questions:

1. Not by design — a gap. sys_inbox_message, sys_notification (+ receipts, deliveries) and sys_email must stamp organization_id on write, same as sys_approval_request already does. The producers (notification outbox/emit paths, email send path in plugin-email/services) are the fix site.
2. Visibility boundary follows org isolation once stamped. The sys_audit_log / sys_activity mixed state (34%/26% null) is the same gap on those writers: new rows get stamped going forward.
3. Backfill: the app project should NOT touch platform tables. Default posture for existing rows follows the maintainer's standing 2026-08-23 precedent on backfills (「10950 不考虑存量」): no retroactive backfill unless the maintainer separately orders one; the fix is forward-stamping.

State: needs-user-decision → pm:queue (services lane), type Bug. Dispatch notes: multi-tenancy/security-adjacent — the writers are engine-context emit paths (ADR-0103 notes receipts are context-less bare engine writes — the fix must thread org context to them, not fabricate it); pin per-producer (each writer stamps, and a walled fresh boot writes zero org-less rows into these tables). Reporter (titanwind-ehr project) can be pointed at this ruling as the official口径.

---

Generated by Claude Code

[os-sam]

Claim + dispatch — ruled a gap, forward-stamping only

• Session: session_01APWX2AwT3a4xDcjPCe8bk4 (os-sam, domain:services execution seat)
• Branch: claude/issue-11303-stamp-organization-id-on-platform-writes
• Worktree: ../objectstack-11303 (per-repo; ⛔ never the shared checkout; ⛔ never git stash)
• pm:queue → pm:dispatched

Authority: maintainer ruling 5393621706, 2026-08-24, verbatim 「11303 sys_inbox_message/sys_notification/sys_email 应该写 organization_id。」 — not by design, a gap. The producers are the fix site.

The two instructions that decide whether this lands well

⭐ Thread the org context to the writers — do NOT fabricate it. The ruling says this in its own dispatch note, and it is the whole difficulty: ADR-0103 records that receipts are context-less bare engine writes. A writer with no organization in scope must not be handed a guess (the "current" org, the first org, the recipient's first membership). If a producer genuinely cannot reach an organization, that is a finding to report, not a place to invent one — a fabricated organization_id is worse than a null, because a null is visibly missing and a wrong value is silently authoritative.

⛔ No backfill. Forward-stamping only, per the maintainer's standing 2026-08-23 precedent on existing rows (「10950 不考虑存量」). Existing org-less rows stay as they are unless the maintainer separately orders otherwise. ⛔ Do not write a migration, and ⛔ do not "opportunistically" stamp an old row you happen to touch.

Surface, and an honest warning about its size

Ruled in scope: sys_inbox_message, sys_notification (+ receipts, deliveries), sys_email, and — same gap on those writers, new rows stamped going forward — sys_audit_log and sys_activity. sys_approval_request already stamps and is the reference shape.

That is a wide producer surface across several packages. Measure the producer census first. If it does not fit one reviewable PR, report the proposed split before writing it rather than delivering a partial sweep that looks complete. A half-stamped set of tables is the exact "some tables carry it, some don't" state the card's own four-axis analysis calls the most dangerous outcome for AI-written reports and cleanup scripts.

⚠️ Two live collisions in this lane — read before you touch a file

• Adopt the referenceVia pointer-pair declaration on the remaining polymorphic pairs (sys_audit_log, sys_approval_request, sys_record_share, sys_share_link, sys_automation_run) — measured per object, not as a sweep #11386 / dev in flight is editing sys_audit_log (referenceVia pointer pairs, alongside sys_approval_request, sys_record_share, sys_share_link, sys_automation_run). Direct overlap. Coordinate through me before touching that object; if a conflict arises, merge, never rebase, re-derive your anchors from content, and ⛔ never trade measurement quality for speed to dodge it.
• PR fix(audit): declare sys_activity.type as an open, author-extensible vocabulary #11659 (sys_activity declaration, plugin-audit) is armed for the merge queue right now. It touches the field declaration, not the writers, so overlap should be nil — but rebase your branch off main after it lands rather than working around it.

Required pins

1. Per producer: each writer stamps organization_id. One pin per producer, named — ⭐ pin identities, not a count; an offsetting error holds a count constant while identity inverts.
2. ⭐ A walled fresh boot writes ZERO org-less rows into these tables. This is the end-to-end pin the ruling names and the one that catches a producer you missed. A per-producer suite alone goes green with an unenumerated writer still emitting nulls.
3. Fail-loud, not fail-guess: a writer that cannot resolve an organization refuses or warns audibly — pin whichever behaviour you implement, and say in your report which you chose and why.
4. single posture is not broken by the change — the over-denial control.

Discipline

⭐ Write the failing pin BEFORE any source edit, on an otherwise-unmodified tree, with the signature predicted in writing first — no restore in the loop means no restore can silently fail. If you must ablate: anchored grep on disk in both directions; capture REPO_ROOT="$(git rev-parse --show-toplevel)" and restore against an absolute path; git hash-object against the HEAD blob is the proof, and ⭐ an EMPTY hash is FAILURE, not a match (#11539). ⛔ Green under ablation is NOT MEASURED.

⚠️ A zero-hit needs a positive control first, and ⭐ a control run through the same broken channel validates nothing. ⭐ Use git grep <ref> — plain grep on the shared working tree reads an unknown state. exit 99 / queue-timeout / PREREQUISITE NOT MET / MODULE_NOT_FOUND / unexplained 143 = NOT MEASURED, never a pass. Capture every exit code before any pipe; an unwired script name exits 254 and reads green through one.

Fences

⛔ Zero packages/spec ownership — if the change wants a spec edit, stop and report. ⛔ Never edit content/docs/releases/, docs/adr/**, .claude/**, skills/**, AGENTS.md, CLAUDE.md. ⛔ Draft PR only; do not flip ready, do not arm auto-merge, do not merge.

Clause-② assessment: currently no — stamping a column on write changes neither accept/reject behaviour nor the public surface, and touches no packages/spec path. ⚠️ If your implementation turns out to change what a write door accepts or rejects, stop and tell me — that reclassifies the card and changes its landing path.

---

Generated by Claude Code