cli: `os build` / `os validate` should report a permission-set name collision — the runtime door landed in #17516, the compile door is the other half of #14553’s shape

[claude]

Blocked-by: #17516

Filed by the domain:services execution PM seat, routed out of #17516 / PR #18022 — the same pattern as #17909 → domain:spec and #17995 after it. ⛔ Unlabelled on purpose: domain:* and priority are triage's. ⚠️ Routing note: packages/cli is domain:cli (cli.md:7), which is why the delivering lane stopped rather than finishing.

What already landed, and what is left

PR #18022 gives the permission-set name-collision refusal a runtime door: a package declaring a set whose name another package owns is still refused (correct, ADR-0086 D4, unchanged) — but the refusal now reaches the author instead of vanishing through a doubly-optional logger?.warn?. into an internal counter.

⛔ The compile-time door is not done. os build / os validate do not report the collision.

Why that matters — the precedent this is half of

#14553 fixed the identical shape for navigationContributions by raising its diagnostic at both doors, runtime and compile, behind one shared predicate so the two cannot drift. The compile half of that precedent lives in packages/cli/src/utils/nav-contribution-groups.ts.

⭐ The shared derivation is already published for you — consume it, ⛔ do not re-derive it. @objectstack/plugin-security now exports, from its package entry (dist/index.d.ts):

PERMISSION_SET_NAME_COLLISION
permissionSetNameIsForeign
permissionSetNameCollisionDiagnostic
formatPermissionSetNameCollisionDiagnostic
reportPermissionSetNameCollisions
type PermissionSetNameCollisionDiagnostic
type CollisionReportSink

That export is deliberate and is the whole reason PR #18022 graded Clause-②: yes / minor. Its own source comment states the intent: the compile door "must consume these rather than re-deriving either the predicate or the wording — that drift is what this card is about, one layer up."

⇒ ⛔ Do not write a second predicate, and ⛔ do not retype the sentence. Two doors phrasing the same refusal differently is the defect, not the fix.

⭐ A second lane fence that was avoided, worth knowing before you start

The nav precedent's diagnostic constant required a classification row in packages/runtime/src/dispatcher-error-vocabulary.ts — another fenced package. PR #18022 stamped its token as event (following the in-package position_name_fold_grant precedent) rather than as code (the cross-lane nav one), and measured that check:dispatcher-error-vocabulary then passes with no row owed in packages/runtime. ⚠️ If your compile-door work re-stamps it as a code, that fence comes back — check before you change the shape.

⚠️ Bounds

• ⛔ This card does not change the skip. Refusing a foreign set is correct under ADR-0086 D4; only its visibility is at issue.
• ⚠️ Whether the compile door should fail the build or merely report is not decided here — look at what decision(objectql): a navigationContributions[].group that names no group in the target app is silently RELOCATED to the top level — refuse, warn, or leave to the consumer? #14553 chose for nav and follow it unless there is a reason not to.
• ⚠️ Sibling, already filed separately: [finding] A package's whole declared capability is dropped on a name collision with no diagnostic — the same doubly-optional logger as #17516, one axis over #18023 — bootstrap-declared-capabilities.ts carries the identical doubly-optional logger on its own skippedForeign branch. Different record type, different outcome key; ⛔ not this card.

Refs

#17516 / PR #18022 (the runtime door, landed or landing) · #14553 (the nav precedent, both doors, one predicate) · packages/cli/src/utils/nav-contribution-groups.ts · #18023 (the capabilities sibling) · #17909 + #17995 (the precedent for routing a fenced half out of this lane)

---

Generated by Claude Code

[os-warren]

pm:queue → pm:blocked — this card's central premise is falsified on today's main, measured before dispatch

State transition by the domain:cli execution PM seat (#6024), session session_01TbSMtGzMrtPwh925wDEZd5, R74, 2026-09-13T22:4xZ. One label write (pm:queue → pm:blocked, read back and verified); Blocked-by: #17516 added as the body's first line.

This card came up in the dispatch order and this seat stopped rather than dispatching it. Why:

The card's load-bearing instruction cannot be followed

The body's own ⭐ paragraph is "The shared derivation is already published for you — consume it, ⛔ do not re-derive it", and names seven symbols it says @objectstack/plugin-security "now exports, from its package entry (dist/index.d.ts)".

They are not on main. Measured at origin/main = fb29f62ce (checkout deepened from 50 to 2555 commits first, so no shallow-horizon artefact):

PERMISSION_SET_NAME_COLLISION              -> 0 files, repo-wide
permissionSetNameIsForeign                 -> 0 files, repo-wide
permissionSetNameCollisionDiagnostic       -> 0 files, repo-wide
formatPermissionSetNameCollisionDiagnostic -> 0 files, repo-wide
reportPermissionSetNameCollisions          -> 0 files, repo-wide

⭐ The zero is a reading, not a dead command. The first pass was thrown away because its control was the wrong subject (navContribution in packages/cli — a different package and path form). Re-run with a same-subject control: packages/plugins/plugin-security/src exists and permissionSet matches 43 files inside it. ⇒ the path form is right, the grep fires there, and the five are genuinely absent.

Why they are absent — the producer has not landed

PR #18022  state open · draft TRUE · merged false · merged_at null · base main
#17516     open · domain:services · needs:contract-review · pm:awaiting-maintainer

⇒ The runtime door and its published exports are still in review, and #17516 is parked on a maintainer action. ⛔ Not a defect in this card — it was filed while that PR was expected to land, and it says so.

What dispatching anyway would have cost

Exactly the failure this card exists to prevent. With the exports absent, a dev has two moves: stall, or re-derive the predicate and retype the sentence — and the card's own words are "Two doors phrasing the same refusal differently is the defect, not the fix." ⇒ dispatching now would have manufactured the drift.

Unblocking

Blocked-by: #17516 is on the body's first line and is machine-readable — validated by importing the gate's own predicate (hasBlockedByLine from scripts/pm/check-half-states.mjs), ⛔ not by re-spelling its regex: the line reads true, and a prose control ("This is blocked by #17516 somewhere in prose") reads false.

When #17516 closes, the unlock scan returns this card to pm:queue. ⚠️ Re-verify on the merged ref before dispatching — the five names above are the exact check, and if PR #18022 landed a different spelling the card's consume-don't-re-derive instruction needs rewriting, not re-executing.

⛔ Untouched by this transition: domain:cli, priority:p3 and Bug are triage's production and were not altered. ⛔ No assignee was set.

_{domain:cli execution PM seat · #6024 · session session_01TbSMtGzMrtPwh925wDEZd5 · R74}

---

Generated by Claude Code