Two MORE clean inheritors of the #8323 class the #8554 sweep missed: sys_notification_subscription and sys_audience_binding_suggestion — both measured live

[os-zhuang]

Found while implementing #8554 (the five-instance batch), by re-running that card's own executed sweep and then probing every tenant-scoped finding instead of eyeballing which ones looked like authored names. Not fixed there — #8554's R5 fixes its scope at exactly five objects, so these are filed rather than folded in.

Per the maintainer ruling of 2026-08-13 on #8468, both objects below are the ruled shape — tenant-scoped, no tenancy opt-out, bare unique: true on a declared index over authored content — so they inherit that answer and go straight to the lane queue. Neither carries a semantic argument for an installation-wide namespace. The judgement cases the same sweep turned up are filed separately.

Both are measured, not read

Real engine (SqlDriver, better-sqlite3), OS_TENANCY_POSTURE=isolated, driving the real shipped declarations loaded from source.

1. sys_notification_subscription — packages/services/service-messaging/src/objects/notification-subscription.object.ts

indexes: [{ fields: ['topic', 'principal'], unique: true }, { fields: ['topic'] }]

materialized: uniq_sys_notification_subscription_topic_principal on (topic, principal)

org_jia creates (billing.invoice, role:sales_manager) → 201
org_yi creates the SAME pair → 409 UNIQUE_VIOLATION
org_yi creates (billing.invoice, role:only_yi) → 201 ← control
org_yi creates (billing.invoice, user:u1) → 201 ← control
org_yi GET on the colliding pair → total 0

This is the direct sibling of sys_notification_preference, one of #8554's five: same package, same directory, same ADR-0030 Layer 3, same managedBy: 'system-data', same archetype. Its own header says the rows are "Admin/user-writable DATA on a platform-defined schema: authored from the Setup 'Notification Subscriptions' grid" — admin-authored content by the ruling's own phrase.

principal is role:x / team:x / user:id / a bare user id. Note what that means now: role and position names are per-organization (#8461, #8556), so role:sales_manager denotes a different principal in each organization while colliding on one installation-wide key. And a user in two organizations cannot subscribe to the same topic in both — the exact symptom measured on sys_user_preference in #8323.

2. sys_audience_binding_suggestion — packages/plugins/plugin-security/src/objects/sys-audience-binding-suggestion.object.ts

indexes: [{ fields: ['package_id', 'permission_set_name', 'anchor'], unique: true }, …]

materialized: uniq_sys_audience_binding_suggestion_79a05fef
 on (package_id, permission_set_name, anchor) ← hash-suffixed, name is over 60 chars

org_jia creates (com.acme.crm, sales_readonly, everyone) → 201
org_yi creates the SAME triple → 409 UNIQUE_VIOLATION
org_yi creates (com.acme.crm, other_set, everyone) → 201 ← control

⚠️ This one is worse than a naming oracle, and I think it is the most serious finding in the whole #8323 lineage so far. The key is not a name two tenants happen to choose alike — it is package_id + the package's OWN permission-set name + anchor, i.e. exactly the same triple for every tenant that installs the same package. The row is per-tenant by construction (the object's header: rows are produced when a package's declaration is observed, and "resolved when a tenant admin confirms").

So the consequence is not an enumeration side channel, it is a functional dead end on the package-install path: the second and every later organization to install a package silently never gets its binding suggestion row, so its admin is never asked to bind the package's default permission set to the everyone anchor, and its users never receive that set. ADR-0090 D5/D9 exists precisely so this is never auto-bound; the effect here is that for every tenant after the first, it is never bound at all and nothing says so.

This does not depend on #8554 landing — package-declared set names are identical across tenants today. #8554 widens the collision surface (admin-authored set names become per-organization and may now legitimately repeat), but the dead end above is live on main right now.

Fix shape (unchanged from #8461 / #8468 / #8554)

1. Respell each to unique: 'organization', spelled explicitly.
2. fix(platform-objects,plugin-security,driver-sql): scope sys_user_preference and sys_capability uniqueness per organization (#8323) #8461's replace_unique_index arm covers both unchanged — verified on the five of Five more instances of the #8323 class: admin- and user-authored names on tenant-scoped objects still carry installation-wide unique indexes #8554 without touching schema-drift.ts, including a 3-column composite and a hash-suffixed replacement name.
3. ⚠️ The pin must exercise the deployed-installation migration path, not only a fresh database — respelling changes the index's generated name, so drift otherwise reads as two findings and an operator applying only the safe half keeps the defect while the plan reads as applied.
4. Check published text for uniqueness claims. Neither object's declaration carries one in its own field text; the generated reference pages should be re-checked at fix time.

⚠️ sys_audience_binding_suggestion's replacement index name is hash-suffixed (buildIndexName truncates past INDEX_NAME_MAX = 60), as sys_notification_preference's is in #8554. That is handled by the existing arm — measured — but it is the case where a name-based assumption would hide.

Related

• tenant-scoped objects get GLOBAL unique indexes: 409-vs-201 enumerates other tenants' values, and a user's preferences silently stop persisting in their second org #8323 / fix(platform-objects,plugin-security,driver-sql): scope sys_user_preference and sys_capability uniqueness per organization (#8323) #8461 — the class, ruled and fixed for sys_user_preference and sys_capability.
• sys_position.name is the third instance of the #8323 class: an admin-authored name on a tenant-scoped RBAC object carries an installation-wide unique index #8468 / PR fix(plugin-security,spec): scope sys_position.name uniqueness per organization (#8468) #8556 — the third instance, where the ruling's standing consequence was recorded.
• Five more instances of the #8323 class: admin- and user-authored names on tenant-scoped objects still carry installation-wide unique indexes #8554 — the five-instance batch this was found from. Neither object here is addressed there.
• sys_setting's unique key is installation-wide on a tenant-scoped object — but unlike the #8323 class it has a real argument for staying that way #8555 — sys_setting, the judgement case.
• ADR-0120 协议 18 项:D2 conversion(声明索引 unique: true → 'global')+ 裸 true 硬拒 + synonym pin 退役 —— 挂 18 列车,现在勿动工 #5082 — parked v18 D2. publish-time advisory: bare unique: true on a tenant-scoped object under group/isolated postures — point authors at the explicit 'organization' | 'global' choice #8379 — the publish-time advisory that would catch this at authoring time.

Filed unassigned. Found by session session_012WMpuAfA2KSdDjGF6tm1bH.

---

Generated by Claude Code

[hotlong]

Triage: filer's labels verified correct (bug + security + pm:queue + domain:metadata), native type Bug set. Queue membership confirmed under the standing 2026-08-13 maintainer ruling recorded on #8468: both objects are the ruled shape — tenant-scoped, no tenancy opt-out, bare unique: true over authored/admin content, measured live with controls — so they inherit the answer and go straight to the lane queue, no decision-box round trip.

Severity note for the dispatching seat: instance 2 (sys_audience_binding_suggestion) is more than the class's naming oracle — it is a measured functional dead end on the package-install path: every organization after the first to install the same package silently never gets its binding-suggestion row, so its admins are never prompted and its users never receive the package's default permission set. Live on main today, independent of #8554. Bug type already puts this ahead of non-Bug queue peers in the selection order; within the lane, prefer it early once the serial constraint clears.

Serial constraints: shares the platform-objects/plugin-security/service-messaging object files' lint + schema-drift replacement surface with in-flight #8554 (PR pending) and the #8461 arm — not the same batch as #8554, #8555 or #8578; clear #8554's PR first. Fix shape is unchanged from the class (respell to unique: 'organization', deployed-installation migration pin, re-check generated reference pages); the hash-suffixed replacement-name case is already measured as handled.

Triage: this comment is from the triage seat Routine.

---

Generated by Claude Code

[os-zhuang]

Claim — dev seat, starting now.

• Session: session_012WMpuAfA2KSdDjGF6tm1bH (dev seat dispatched for Two MORE clean inheritors of the #8323 class the #8554 sweep missed: sys_notification_subscription and sys_audience_binding_suggestion — both measured live #8577 only; note this repo's agents share one identity, and the same session id appears on the filing comment and on PR fix(plugin-security,plugin-sharing,plugin-webhooks,platform-objects,service-messaging,spec): scope five tenant-scoped declared unique indexes per organization (#8554) #8599 — this comment is the Two MORE clean inheritors of the #8323 class the #8554 sweep missed: sys_notification_subscription and sys_audience_binding_suggestion — both measured live #8577 dev claim, not a re-claim of those).
• Branch: claude/issue-8577-two-more-unscoped-uniques, worktree ../objectstack-issue-8577, based on origin/main @ b45c71e85a (fix(plugin-security,plugin-sharing,plugin-webhooks,platform-objects,service-messaging,spec): scope five tenant-scoped declared unique indexes per organization (#8554) #8599 merged, which is what cleared the serial constraint triage recorded).
• Scope: exactly the two objects on this card. Not sys_setting (sys_setting's unique key is installation-wide on a tenant-scoped object — but unlike the #8323 class it has a real argument for staying that way #8555), not sys_job (The #8554 sweep's "bounded set" is not bounded: the tenancy filter alone yields 20 findings, not 6 — here is the full measured triage, plus sys_job as a second #8555-shaped judgement case #8578), not Five more instances of the #8323 class: admin- and user-authored names on tenant-scoped objects still carry installation-wide unique indexes #8554's five (landed).

Planned file surface across every package (will report any addition):

• packages/services/service-messaging/src/objects/notification-subscription.object.ts — respell to unique: 'organization', explicitly.
• packages/plugins/plugin-security/src/objects/sys-audience-binding-suggestion.object.ts — same.
• New per-package declaration pins under each package's tests dir.
• New driver-level suite in packages/drivers/driver-sql covering both objects, including the deployed-installation migration path with a named harness guard, and — for sys_audience_binding_suggestion — the install path (two organizations installing the same package each getting their own binding-suggestion row), which is the half that matters more than the 409/201 oracle here.
• .changeset/*.md (required; must tell operators os migrate apply is needed and that deploying alone is insufficient).
• Possibly: published-text sources (describe() / field description / dialog helpText) plus regenerated content/docs/references/** pages, and the four shipped translation bundles — only if a uniqueness claim is actually published. plugin-security/src/translations/* is contended with an in-flight card on sys-capability.object.ts; I will ask the PM before touching those files.
• Not touched: packages/objectql/src/registry.ts, /meta read-exit materialization, the sys_capability authoring door, content/docs/releases/, and schema-drift.ts unless A1 falsifies (verification is by object hash, not by eye).

Probe first, per object, prediction recorded before each run; if either probe contradicts the static read I stop and report the fork rather than migrating it.

---

Generated by Claude Code