multi-org: platform/system tables (logs, messaging, config) never carry organization_id — by design, or planned?

[baozhoutao]

Question

On a production-like install (multi-org enabled: enterprise package + license), platform/system tables never carry organization_id — including rows created today. Business-object tables do carry it (we backfilled our own legacy rows project-side). Please confirm: is the absence of org scoping on these system tables by design, or should they be org-scoped (and if so, is a migration planned)?

We are not reporting a malfunction — everything works. We only need the design intent confirmed, and to know whether org markers will be added later, so we can decide whether to account for it in operations.

Inventory (read-only scan, 2026-08-23, 112 org-column-bearing tables scanned)

Platform tables where 100% of rows (old and new) lack organization_id — 9,577 rows total:

Category	Rows
Logs (job logs 5,613 / audit logs 1,510 / feed 916 / automation runs 5)	8,044
Messaging (inbox messages & receipts 766 / notifications & deliveries 410 / email 96 / templates 28)	1,300
Config & metadata misc (capabilities / metadata / files / permission sets / positions etc.)	233

Environment

• @objectstack/*@17.2.0, PostgreSQL 16
• Multi-org enabled and in active use; 47 business tables are fully org-scoped and clean

[os-zhuang]

Triage: multi-org semantics of platform/system tables → domain:services, type Task, pm:blocked.

Blocked-by: #11303

Rationale: #11303 is the ruled parent of this question and is in flight — the maintainer has already ruled its messaging-table instances (sys_inbox_message / sys_notification / sys_email), verbatim from the batch record: 「…应该写 organization_id」. The messaging half of this card's list is therefore answered by inheritance and being implemented there. What remains genuinely open is the tail (logs / config tables, where platform-scoped-by-design is a defensible answer). Unlock action: when #11303 lands, re-scope this card to the residual tables only, measured against the landed write-side pattern — the residue is either a mechanical extension of that pattern or a short decision list, and it should not be guessed before the pattern exists.

---

Generated by Claude Code

[os-litant]

Unlock-scan release (triage seat, daily round 2026-08-27, session session_01Czs5tCwMymUvzB9QCA2yhH): the transition comment's blocker #11303 is CLOSED (2026-08-24) — release double-check passes (that comment is the most recent transition; no newer merged PR on this card). pm:blocked → pm:queue, executing the unlock action that comment pre-wrote:

Re-scoped on release. The messaging half of the body's inventory (inbox messages & receipts / notifications & deliveries / email / templates — 1,300 rows) is answered by inheritance: the maintainer ruled those tables carry organization_id (「…应该写 organization_id」, recorded on #11303) and the write-side pattern has landed there. What this card now asks is the residual tail only: the logs family (job/audit/feed/automation — 8,044 rows) and the config/metadata misc set (233 rows). Dispatch shape: measure each residual table against the LANDED #11303 write-side pattern first; the answer per table is either a mechanical extension of that pattern or an entry on a short decision list for the maintainer (platform-scoped-by-design is a defensible answer for logs/config and must not be guessed). The reporter's operational question ("by design or planned?") gets its written answer from that measurement — do not close without stating it on this card.

---

Generated by Claude Code

[os-litant]

Claim: PM loop round 4 (services seat)
Session: session_0194kbQJxUvv2yvsGRtuXpP5
Branch: claude/issue-11611-platform-table-org-scoping
Worktree: objectstack-issue-11611
Domain: domain:services
File surface: read-first, and possibly read-only. The measurement spans the platform objects behind the residual tables (packages/platform-objects/**, packages/services/**) plus wherever #11303's landed write-side pattern lives. ⛔ Zero packages/spec. ⚠️ Any write is gated on the fence below.
Container & model: M, mode:subagent, model: claude-opus-5. The diff may be nil; the deliverable is a measured answer to a customer, and the judgment is which residual tables are a mechanical extension versus a decision nobody has made.
Clause-②: no for the measurement and the written answer. ⚠️ Binding: if you conclude a residual table should gain organization_id, see the fence — that path may re-declare, and you stop before writing it.
Serial constraints cleared: no services-lane card in flight. plugin-auth/** was released when #12547's PR was accepted; nothing else in this lane holds platform-objects/**.

---

What is already answered — ⛔ do not re-open, and do not re-measure it

Triage's unlock (11611#issuecomment-5435274081) re-scoped this card when #11303 closed. The messaging half of the body's inventory is answered by inheritance: the maintainer ruled those tables carry organization_id (verbatim 「…应该写 organization_id」, recorded on #11303) and the write-side pattern has landed there.

⇒ Inbox messages & receipts / notifications & deliveries / email / templates — 1,300 rows — are out of scope. ⛔ Do not re-litigate, do not re-measure, do not include them in your answer except as "already ruled and implemented".

What this card now asks — the residual tail only

• Logs family — job logs, audit logs, feed, automation runs (8,044 rows)
• Config & metadata misc — capabilities / metadata / files / permission sets / positions etc. (233 rows)

Measure each residual table against the LANDED #11303 write-side pattern first. Find that pattern in the tree before forming any opinion — it is the reference every per-table answer is measured against.

Per table, the answer is one of exactly two things:

1. a mechanical extension of the landed pattern, or
2. an entry on a short decision list for the maintainer.

⛔ "Platform-scoped by design" is a defensible answer for logs and config, and it must not be guessed. A log row that is deliberately global is not a defect; asserting it is one would be worse than leaving the question open.

⚠️ The fence — where "mechanical extension" stops being yours to write

The reporter has 8,044 existing rows on a production install. So:

• If a residual table is a mechanical extension of the landed pattern and carries no implication for existing rows — new rows start carrying the column exactly as [finding] sys_inbox_message/sys_notification/sys_email 等平台表从不写 organization_id(存量与新增行 100% null)——请确认多组织语义是否设计如此 #11303 does, old rows stay as they are — implementing it is in scope.
• ⛔ If it implies backfilling or migrating existing rows, that is existing-data-migration shape and is maintainer floor. Put it on the decision list and stop — do not write it, and do not write a migration "ready for review".
• ⛔ If it is a genuine design choice (should audit logs be org-scoped at all?), that is the decision list too.

⚠️ Check what #11303 actually did about existing rows before you classify anything, and say so in the report. If the landed pattern itself backfilled, the fence moves and I want to know that rather than have you infer around it.

⭐ The deliverable is a written answer, not a diff

This is a customer asking for design intent, not a bug report — their own words: "We are not reporting a malfunction — everything works. We only need the design intent confirmed, and to know whether org markers will be added later."

⇒ ⛔ Do not close this card, and do not consider it done, without stating the answer on it: per residual family, is the absence of organization_id by design or pending, and on what reading. A PR with no written answer fails this card even if every gate is green. premise_still_valid: false with no PR and a written measurement is a perfectly good delivery here — possibly the most likely one.

Write it so the reporter can act on it operationally, which is what they asked for.

Verification

• Whatever suites cover what you touch — and if you touch nothing, say so plainly rather than reporting a vacuous green.
• Gate union from node scripts/pm/dispatch-gates.mjs on your actual changed set (possibly empty); exit codes captured before any pipe. PREREQUISITE NOT MET is NOT MEASURED, not red.
• Changeset: only if you ship something. ⛔ Never an empty changeset; a measurement-only delivery needs no changeset and should say so.
• ⛔ No model names in any pushed artifact.

Report

Post your terminal JSON report as a comment on this issue first, then return it. Leave your own claim comment before starting — the assignee here is the PM session, not you. Include as named fields: the landed #11303 pattern you measured against, the per-table verdict for each residual family, and the decision list if any.

⚠️ Reach GitHub with the MCP tools (mcp__github__issue_read / add_issue_comment / create_pull_request, schemas via ToolSearch). Raw REST / curl / gh is 403 from a dev seat by design and is never a reason to stop.

---

Generated by Claude Code