`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

[os-zhuang]

Found while implementing #8323 (option 2), sweeping the docs for uniqueness claims at the PM's request. Not fixed there — the ruling of 2026-08-13 named exactly two objects, and this is a third. Filed for triage rather than folded in.

The declaration

packages/plugins/plugin-security/src/objects/sys-position.object.ts:

indexes: [
  { fields: ['name'], unique: true },
  { fields: ['active'] },
],

Structurally identical to the sys_capability instance #8323 just fixed:

	sys_capability (fixed in #8461)	sys_position
declared index	{ fields: ['name'], unique: true }	{ fields: ['name'], unique: true }
tenancy opt-out	none → gets organization_id	none → gets organization_id
provenance	managedBy: 'config', admins extend in Setup	managedBy: 'config', admins author positions

On a DECLARED index bare unique: true is the positional spelling of 'global' — the listed columns verbatim — so name is an installation-wide key on a tenant-scoped object. That is the #8323 §1 shape exactly: an organization can POST a position name and read 409-vs-201 to learn whether another organization already holds it, while its own read of that name returns nothing.

The reference docs assert the strong reading as though it were intended — content/docs/references/identity/position.mdx: name … "Unique position name (lowercase snake_case)". That line is generated from the field's describe(), so the spec text says installation-unique too.

What I did and did not establish

• Established statically: the declaration, the absence of a tenancy opt-out (so organization_id is injected), and that the declared-index bare spelling materializes verbatim — the same mechanism measured and pinned in fix(platform-objects,plugin-security,driver-sql): scope sys_user_preference and sys_capability uniqueness per organization (#8323) #8461.
• NOT established: a live 409/201 probe against sys_position, and — the real question — whether installation-wide position names are intended. Unlike capabilities, positions carry a hierarchy (parent_id), and it is at least arguable that a deployment wants one global position taxonomy. 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's sys_capability had ADR-0066 D1's "admins EXTEND the registry" to settle intent; I did not find the equivalent statement for positions, so I am not asserting the answer.

That intent question is why this is a separate card and not a line in #8461: if per-organization is right the fix is one word plus the same replace_unique_index migration (already generalized to declared indexes in #8461, so the migration machinery is in place and free); if installation-wide is right the correct fix is the opposite — spell it unique: 'global' explicitly so the intent stops being a positional accident, and correct the describe().

Either way the current state is the one spelling ADR-0120 says states no scope at all, on a tenant-scoped object, which unique/unscoped-declared-index already warns about.

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 same class, ruled and fixed for sys_user_preference and sys_capability.
• ADR-0120 协议 18 项:D2 conversion(声明索引 unique: true → 'global')+ 裸 true 硬拒 + synonym pin 退役 —— 挂 18 列车,现在勿动工 #5082 — parked v18 D2 (bare true → 'global' plus a loud refusal); whichever way this card is decided, stating the scope explicitly is what that train wants.
• 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 have caught this at authoring time.

I also swept the other platform objects while here. Most bare declared uniques are legitimately installation-wide (sys_session.token, sys_api_key.key, sys_oauth_*.token, sys_device_code.*) and several already hand-write the organization composite (sys_team ['name','organization_id'], sys_business_unit ['code','organization_id'], sys_member ['organization_id','user_id'] — the ADR-0120 S6 legacy spelling, valid indefinitely). sys_position is the one that looked like the fixed pair rather than like either of those groups.

Filed unassigned. Found by session session_012WMpuAfA2KSdDjGF6tm1bH.

---

Generated by Claude Code

[os-zhuang]

Decision card — this may be a third instance of the #8323 release blocker

Labelled bug + security + needs-user-decision, domain:metadata. Filed by the #8323 dev from a sweep it ran while fixing the two objects the maintainer's ruling named.

⚠️ What is and is not established

Established: sys_position.name carries { fields: ['name'], unique: true } with no tenancy opt-out and managedBy: 'config' — structurally identical to the sys_capability instance just fixed in PR #8461. Under the semantics that PR documents, a declared index's bare unique: true is the positional spelling of 'global', so on a tenant-scoped object it materializes an installation-wide unique index.

NOT established: that the cross-tenant enumeration actually reproduces here. This is structural identity read from source, not a measured 409-vs-201 oracle, and the report says so plainly. ⛔ Do not treat it as a confirmed exploit until someone reproduces it.

So the first step is a measurement, not a ruling — does the #8323 §1 reproduction (409 for a value another organization already holds, 201 otherwise) fire on sys_position? If it does not, this drops to a tidiness question and can leave the decision box.

Why it needs a ruling and not just a fix

sys_capability had no published uniqueness claim — the dev checked the whole content/docs tree and found none, which is why respelling it was uncontroversial. sys_position is the opposite: references/identity/position.mdx:64 publishes "Unique position name". So installation-wide uniqueness may be intended and documented rather than accidental, and the correct fix could go either direction:

• respell to unique: 'organization' — matching what fix(platform-objects,plugin-security,driver-sql): scope sys_user_preference and sys_capability uniqueness per organization (#8323) #8461 just did for its two siblings; or
• make 'global' explicit — keeping today's behaviour but stating it deliberately, so the lint rule stops flagging it and the next sweep does not re-raise it.

No ADR settles which. That is the decision.

The scoping question the maintainer actually owns

The 2026-08-13 ruling chose option 2 — "the platform's own objects change to explicit organization scoping" — and named sys_user_preference and sys_capability. It separately accepted the §1 oracle on customer-authored bare-unique objects as the documented cost of 'global' uniqueness until v18.

sys_position is a platform object, not customer-authored, so it falls on the first side of that split by category while sitting outside the two objects the ruling enumerated. Does the ruling extend to a third platform object the sweep found, or was the enumeration exhaustive by intent? I am not answering that on your behalf.

What makes this actionable rather than an open worry

The same sweep bounded the rest of the platform's objects, which is what turns one observation into a closed set:

• legitimately installation-wide — sys_session.token, sys_api_key.key, the oauth and device-code tokens;
• already hand-write the organization composite — sys_team, sys_business_unit, sys_member (the ADR-0120 S6 spelling, valid indefinitely);
• the one open case — this card.

So whatever is ruled here closes the class for the platform's own metadata rather than leaving a tail.

Decision box for domain:metadata is now four: #8284, #8376, #8459, #8468.

---

Generated by Claude Code

[hotlong]

Triage — four-prism card face + recommendation. Kept in the decision box rather than absorbed into the parent ruling; the reason is stated at the end, because it is close.

1. Platform long-term coherence — structurally identical to the pair already ruled a defect on 2026-08-13: managedBy: 'config', no tenancy opt-out (so organization_id is injected), admin-authored content, bare unique: true on a declared index = the positional spelling of installation-wide. Treating the third instance differently needs a positive reason. The hierarchy argument (parent_id) is the candidate — but hierarchy does not imply a shared namespace; the neighbouring tenant-scoped objects already carry organization composites and are no less structured.
2. Measured business pull — same shape as the ruled two: an organization can POST a position name and read 409-vs-201 to learn whether another organization holds it, while its own read of that name returns nothing. That is a cross-tenant enumeration oracle plus a functional dead end (cannot create the name, cannot see why). ⚠️ Not measured live here — the card is explicit that no 409/201 probe was run against this object.
3. AI-agent error-resistance — bare unique: true on a tenant-scoped object is precisely the spelling that states no scope at all, and the generated reference docs currently assert the strong reading as if intended (describe() says "Unique position name"), so the accident has already propagated into published text an AI author will read as contract. Whichever way this is ruled, the scope must end up spelled explicitly — that is the half of the fix that is not in question.
4. Startup scope discipline — both directions are one word plus a small follow-on: per-organization reuses the replace_unique_index migration already generalized to declared indexes by the parent fix (machinery in place, free); installation-wide costs an explicit 'global' spelling plus a describe() correction. The expensive outcome is neither — leaving a positional accident that the v18 train will have to re-litigate.

Recommendation: per-organization (inherit the parent ruling), with two conditions on the implementing card: run the live 409/201 probe first and report a fork if it contradicts the static read; and spell the resulting scope explicitly in both directions rather than relying on positional defaults, correcting the describe() and therefore the generated reference page in the same PR.

Why this came to you at all — the standing meta-criterion says a sibling branch of an already-ruled family inherits the parent ruling together with its reasoning, and re-opens only on a real semantic difference. The parent's reasoning leaned on an explicit ADR statement that admins EXTEND a platform registry; the filer looked for the equivalent statement for positions and did not find one. So the inheritance test lands on "is a single installation-wide position taxonomy intended?" — a product-semantics question about an RBAC vocabulary, which is yours. If your reading is that the parent ruling simply carries (my recommendation is that it does), say so and this becomes a queue card immediately, and the same answer will cover any fourth instance without another trip to the inbox.

---

Generated by Claude Code

[hotlong]

Maintainer ruling — the parent ruling carries: sys_position.name becomes per-organization

Ruled in a live PM session, 2026-08-13, accepting the triage seat's recommendation (maintainer verbatim: 「同意」). Recorded by the triage seat as a ruling record.

Ruling. This is a sibling branch of the already-ruled installation-wide-unique class, and the parent ruling carries together with its reasoning: an admin-authored name on a tenant-scoped object is scoped per organization. A position hierarchy does not imply a shared namespace, so the semantic difference that would have justified re-opening the family is not present.

Standing consequence — this settles the family, not just this card: any further instance matching the same shape (tenant-scoped object, no tenancy opt-out, admin-authored content, bare unique: true on a declared index) inherits this answer and goes straight to the lane queue. ⛔ Do not bring a fourth instance to the decision box; bring it only if it carries a genuine semantic argument for an installation-wide namespace, and state that argument explicitly.

This ruling is premise-bearing — the premise is falsifiable and must be verified before the fix:

• Premise: the static read is correct — the declared bare unique: true materializes as an installation-wide unique index on this object, reproducing the 409-vs-201 cross-tenant oracle. The card is explicit that no live probe was run here.
• Required first step: run the live 409/201 probe against sys_position on a real engine, two organizations, same name.
• ⛔ If the probe contradicts the static read, STOP and report the fork on this card. Do not proceed to the migration, and do not silently switch to the other spelling. A ruling whose premise fails goes back to the maintainer, it does not get reinterpreted by the implementer.

Scope once the premise holds:

• Scope the uniqueness per organization, reusing the replace_unique_index migration already generalized to declared indexes by the sibling fix.
• Spell the scope explicitly. Leaving any positional default in place is not an acceptable end state on this object, in either direction — that half was never in question.
• Correct the field's describe() ("Unique position name") and therefore the generated reference page in the same PR; the published text currently asserts installation-uniqueness as if it were intended, which is how the accident reaches authors as contract.

State: needs-user-decision → pm:queue, security retained. Blocked-by: none (checked live — the sibling fix that generalized the migration machinery has landed). Serial note for the metadata seat: verify at claim time that nothing in flight is touching sys-position.object.ts or the same migration registry region.

---

Generated by Claude Code