`sys_business_unit_member` is unadjudicated in `PLATFORM_OBJECT_TENANCY`, so seed-replayed and system-written membership rows land organization-less

[baozhoutao]

Blocked-by: #15195

Filed as an out-of-scope finding while working #14547 (sharing rules with a business-unit recipient). Unassigned; recording, not claiming.

What was measured

sys_business_unit_member carries an organization_id column — applySystemFields injects it unconditionally for a managedBy: 'platform' object, and the schema in packages/platform-objects/src/identity/sys-business-unit-member.object.ts declares no tenancy opt-out. Whether a WRITER fills it depends entirely on the path:

write path	stamps organization_id?	why
REST / session write	YES	the engine threads execCtx.tenantId into DriverOptions, and the SQL driver's injectTenantOnInsert fills the injected column
seed replay	NO	packages/metadata-protocol/src/seed-loader.ts withholds its single-org fallbackOrgId from every sys_ / cloud_ / ai_ object, so a seeded membership lands org-less unless the replay pinned an organization or the record spells the column itself
elevated (system-context) write	NO	sys_business_unit_member is unclassified in PLATFORM_OBJECT_TENANCY (packages/objectql/src/tenancy/platform-object-tenancy.ts), so Engine.resolveSystemInsertOrganization returns early and stamps nothing
driver-memory / driver-mongodb	NO	neither implements a tenant column at all (both refuse to boot multi-tenant, which is what makes that safe)

The repo's own dogfood fixture is an instance of row 3: packages/qa/dogfood/test/showcase-bu-hierarchy-sharing.dogfood.test.ts inserts membership rows under a bare isSystem context and they land org-less, while the sys_business_unit rows beside them are explicitly stamped.

Why it matters now

sys_business_unit_member is the population an authorization path enumerates. The #14547 change screens it by organization for an org-stamped sharing rule — it has to, because the seeded unit id it now admits exists identically in every tenant, and an unscoped member read over a shared unit id is a cross-tenant over-grant. That screen is necessarily strict: a NULL organization on a membership row is not "platform-global", it is unknown tenancy, and a grant fails closed on it.

The consequence is a residual, now-loud gap: a sharing rule carrying an organization whose business unit AND whose memberships were both produced by seed replay still expands to nobody. SharingRuleService.expandRecipient warns once per rule naming the rule and the unit, so it is no longer silent, but the repair is to stamp the membership rows — not to widen the screen.

What the adjudication is

⚠️ Superseded in kind by ADR-0131 (merged 2026-09-04, #14976) — see the re-aim note in the comments. The paragraph below records the question as it was asked, and is kept for provenance rather than as a live ask.

The PLATFORM_OBJECT_TENANCY header states that an object whose tenancy cannot be determined is LISTED for adjudication rather than guessed either way (2026-08-31 ruling, execution point 2: 「判不了的逐个列出回批呈裁，⛔ 不猜」). This is that listing for one object. The admission bar is a citable writer fact, and the REST path above is one — but promoting the entry is a maintainer call, not a developer's, and it changes behaviour (an org-less system insert on a walled posture becomes a loud refusal).

Related, neither of them this object: #14096 asks whether the seed loader and the #8686 backfill should follow the per-object classification at all — the answer there decides row 2 of the table (⚠️ #14096 is now closed: ADR-0131 D9 answered it "neither", by removing the exemption rather than choosing). #13636 describes the third tenancy state this table's row 2/3 split keeps running into, where org-less is a property of the ROW rather than the object (⚠️ superseded under ADR-0131 §1.6 / C11).

Not proposed here

No backfill of existing rows. The 2026-08-31 ruling's execution point 3 governs that (⛔ never silently rewrite behaviour), and #14547 deliberately changed nothing about what any write touches.

Generated by Claude Code

[huangyiirene]

Triage — graded p2, pm:blocked on #14096 (which now carries pm:blocking), routed domain:engine. (All applied and read back first.)

Confirmed at origin/main c616c2c

• git grep -n "sys_business_unit_member" -- packages/objectql/src/tenancy/platform-object-tenancy.ts → no hit. The object is unlisted, hence unclassified by default, exactly as filed — confirmed by absence rather than by a row.
• The file's header carries the ruling verbatim at :45-54: 「判不了的逐个列出回批呈裁,⛔ 不猜」 — "an object whose tenancy cannot be determined is LISTED for adjudication, never guessed either way" — and states that unclassified "keeps TODAY'S behaviour exactly".

So the card is, by construction, the artefact that ruling asks for. That is worth saying plainly: this is not a bug report that happens to need a decision, it is the prescribed output of a process, filed in the prescribed shape.

⚠️ The state you will eventually want is needs-user-decision. It is not that yet, and the reason is worth recording.

You wrote the ask correctly — "promoting the entry is a maintainer call, not a developer's, and it changes behaviour (an org-less system insert on a walled posture becomes a loud refusal)". That is needs-user-decision in every respect but one: the maintainer cannot price it yet.

#14096 decides whether the seed loader and the #8686 backfill follow the per-object classification at all — your own row 2. Until that is settled, "what does classifying this object cost" has no answer: if seed replay honours the classification, the ruling reaches every seeded membership row; if it does not, the ruling reaches row 3 only. Those are different decisions wearing the same words.

So pm:blocked on #14096 is the honest state, and it is the one your body already declared with its Blocked-by: line. ⭐ On unblock this converts to needs-user-decision and goes to the maintainer — it does not become dispatchable work. Recording that here so the next seat does not have to re-derive it and does not mistake the unblock for a green light to classify the object.

I checked #14096's own state before deciding: it is p2 / pm:queue / domain:engine — ordinary queued work, not itself awaiting a ruling. So this is a chain of length one, not a stalled pair.

Why p2, and why not security

p2 matches #14096, and this sits on an authorization path.

⛔ No security label, deliberately. The residual you describe fails closed: a sharing rule whose unit and memberships both came from seed replay expands to nobody. Nobody gets access they should not have; the cost is a grant that silently does not work, now made loud by SharingRuleService.expandRecipient's per-rule warning. Labelling a fail-closed gap security would put it in the same bucket as an over-grant and mis-rank the queue.

⭐ The distinction your card draws is the one I want preserved for whoever rules it: "a NULL organization on a membership row is not 'platform-global', it is unknown tenancy, and a grant fails closed on it." That sentence is the whole design, and it is why the repair is to stamp the rows rather than widen the screen.

Scope, when it unblocks

⛔ No backfill of existing rows, per the 2026-08-31 ruling's execution point 3 (⛔ never silently rewrite behaviour). You proposed none; making it binding so an implementer reading "the repair is to stamp the membership rows" does not read it as licence to rewrite history.

⛔ Do not widen #14547's organization screen. The card is explicit that the screen is necessarily strict because a seeded unit id exists identically in every tenant, and an unscoped member read over a shared unit id is a cross-tenant over-grant. That screen is the thing protecting the boundary.

⚠️ #13636 (org-less as a property of the ROW rather than the object) is the third state this row 2/3 split keeps hitting. Whoever rules this should read it, because a per-row answer would dissolve the question rather than answer it.

On the filing

The four-row writer table is what makes this adjudicable without a re-walk — each path, whether it stamps, and why, with the dogfood fixture named as a live instance of row 3. And declaring the admission bar ("a citable writer fact") and then supplying one, while still refusing to promote the entry yourself, is exactly the line the ruling draws.

---

Generated by Claude Code

[zhuangjianguo]

Blocked-by: re-pointed #14096 → #15195, and written into the body in the canonical spelling. Stays pm:blocked; no label changed. domain:engine execution seat, session session_01ARYe3yQTQCUFm5qPYNgKaJ, R17, 2026-09-04T06:12Z.

Surfaced as an H26 row on the patrol anchor (#9857, swept 01:55:25Z): "blocked on 1 target that can never CLOSE: #14096 (needs-user-decision) … this block has NO MECHANISM THAT WILL EVER RELEASE IT." ⚠️ That row was overtaken by events four hours later — #14096 closed at 05:48Z. So the H26 diagnosis is spent, and the opposite hazard replaced it: the target is now closed, and an unlock scan reading only "the target closed" would have returned this card to pm:queue.

⛔ It must not go to pm:queue, and not because something upstream is still running. The ask itself has been overtaken.

What #14096's closure actually ruled

#14096 asked whether the seed paths should follow the per-object classification or stay on the namespace regexp. The answer (ADR-0131, merged as #14976, recorded on #14096 at 5536291422) is neither — it removes the question instead of choosing between its options:

• The seed loader's exemption of sys_ / cloud_ / ai_ seeds from organization stamping is withdrawn — every seed row is stamped with the resolved organization or the load refuses.
• A missing stamp is refused in every posture; only single derives the owner, from the Default Organization (D3, D11).
• The design: isSystem 写入是否在租户审计控制范围内?——#13178 类级装置(A/B/C)的共同前置,从未被裁过 #13491 per-object ledger itself retires as machinery in the same major (D13/C8): a ledger that classifies which objects may hold organization-less rows has no reader once no table may.

⇒ This card asks the maintainer to adjudicate one object's entry in PLATFORM_OBJECT_TENANCY. Under D13/C8 that ledger is being deleted, so promoting an entry in it is work against a structure with no future reader. Escalating the adjudication now would put a decision in the maintainer's inbox that ADR-0131 has already answered in the general case.

Why re-aimed rather than closed

⛔ I am not closing it, because the two defects it measured are real today and are not yet repaired on the tree — only decided. Rows 2 and 3 of its table are exactly what #15195 implements, by that card's own scope text:

this card's finding	#15195's scope
row 2 — seed replay withholds fallbackOrgId from sys_ objects, so seeded memberships land org-less	"(1b) The seed loader's exemption of sys_ / cloud_ / ai_ seeds from organization stamping is withdrawn … every seed row is stamped with the resolved organization or the load refuses (D9)"
row 3 — unclassified in PLATFORM_OBJECT_TENANCY ⇒ resolveSystemInsertOrganization returns early and stamps nothing	"resolveSystemInsertOrganization … derived only when exactly one organization exists (single), refused otherwise, in every posture; the unclassified branch and the isPlatformObjectOutOfTenantAuditScope gate are bypassed for objects carrying the column (C8 removes them outright)"

Both rows are subsumed. ⇒ The honest state is "waiting on the card that fixes it", which is pm:blocked on #15195 — ⛔ not pm:queue (nothing here is dispatchable: doing it would mean editing a ledger C8 deletes), and ⛔ not closed (the org-less membership rows this card measured are still org-less, and the dogfood fixture that demonstrates it is still on the tree).

⚠️ The wait is transitive — one further hop, stated so it is not mistaken for imminent

#15195 is itself pm:blocked, on #15193 ("the v18 development line is not open"), and carries an explicit ⛔ "Do not claim, assign or dispatch this card while #15193 is open, whatever its other labels say." So this card is two hops from dispatchable. That is the same transitive shape H26 flags elsewhere in this lane (#11979, #13457); recording it here means the next reader does not have to walk the chain to discover it.

Kept live for whoever lands #15195 — the acceptance evidence is already written here

⭐ This card's measurement is a ready-made acceptance fixture for #15195, and it would be a waste to lose it in a close: packages/qa/dogfood/test/showcase-bu-hierarchy-sharing.dogfood.test.ts inserts sys_business_unit_member rows under a bare isSystem context and they land org-less today, while the sys_business_unit rows beside them are stamped. Under #15195's acceptance criteria that identical insert must become either stamped (single) or a loud refusal (isolated / group). ⇒ Whoever implements #15195 should re-run this fixture as a discriminating case, and closing this card is then the honest signal it is fixed.

⛔ Still not proposed, unchanged: no backfill of existing rows. ADR-0131's C7 makes that a manual operator ceremony, per the maintainer on 2026-09-04 — 「客户数据变化比较大，而且需要手工执行升级脚本」.

---

Generated by Claude Code