spec: register UNIQUE_SCOPE_CONFIRMATION_REQUIRED — the install seam's posture-gate refusal reaches a wire unregistered

[os-steve]

Found by the widened check-dispatcher-error-vocabulary scan in #9223 (PR pending). Filed unassigned; nobody is on it. Not fixed there: that card widens the GATE, and packages/runtime/src/dispatcher-error-vocabulary.ts states its own boundary — "Registering a code widens the accepted set, which is a contract-semantics change owned by the packages/spec lane. Nothing here edits the ledger." #9223 lands the classification row; this card is the registration.

The finding

UNIQUE_SCOPE_CONFIRMATION_REQUIRED is in neither StandardErrorCode nor ERROR_CODE_LEDGER, and it reaches a wire as error.code:

• Producer — packages/cloud-connection/src/marketplace-install-local-plugin.ts, the ADR-0120 D5e posture gate stopping an install: c.json({ success: false, error: { code: GLOBAL_UNIQUE_CONFIRMATION_REQUIRED, message, details } }). The constant is packages/types/src/unique-scope-install-gate.ts.
• Live reader off the wire — packages/cli/src/commands/package/install.ts branches on res.body?.error?.code === 'UNIQUE_SCOPE_CONFIRMATION_REQUIRED' to print the per-index decision list. So the spelling is load-bearing, not incidental.
• The seam already speaks registered vocabulary, which is what makes this a gap rather than a design choice: every sibling code in the same file (PLUGIN_MANIFEST_INVALID, MARKETPLACE_UNAVAILABLE, INVALID_REQUEST, RESOURCE_NOT_FOUND, CLOUD_FETCH_FAILED, MARKETPLACE_STORAGE_FAILED, …) is in the ledger already — which is precisely why the gate never reported them. This one member is the exception.

Why it hid until now

It is stamped through a constant in an object literal — the exact blind spot #9223 closes. objlit required a quoted literal, so code: GLOBAL_UNIQUE_CONFIRMATION_REQUIRED matched nothing and was not even reported as unresolved. The code has been reaching the wire, unregistered, for as long as the gate has been green.

Disposition already landed in #9223

The site carries a row with verdict: 'pending-registration', door: 'plugin-route', so PENDING_LEDGER_REGISTRATION is non-empty again and the ratchet is armed: when this registration lands, error-envelope.conformance.test.ts goes red on the now-stale row ("every pending code is still unregistered") and that row must be deleted in the same edit. That is the intended hand-off, not a conflict.

Note the door: this seam is a plugin mounting its own Hono routes, so the body passes through neither the dispatcher's errorFromThrown nor the packages/rest doors — worth a look at whether anything parses that envelope against ApiErrorSchema at all, since nothing currently would have caught this.

Related: #8087 (the gate), #8846 (the first registration batch, closed), #9223 (the widening that found it).

---

Generated by Claude Code

[os-zhuang]

Triage: lands in packages/spec (error-code ledger) — pm:queue + pm:blocked, domain:spec, type Bug (a code reaching a wire unregistered violates the ADR-0112 closure the ledger declares; producer and live wire reader both measured in the card).

Blocked-by: #9223

Rationale for the block: #9223's pending PR lands the pending-registration classification row whose deletion is contractually paired with this registration (the ratchet hand-off the card describes). Registering first would strand #9223's row stale at its own landing — serial, #9223 first; on unlock, re-verify the row exists on the merged ref before dispatch.

Dispatch note for the spec seat: this registration widens the accepted ledger set — clause-② contract face; dispatch at the contract-review tier. The card's side observation (nothing parses the plugin-route envelope against ApiErrorSchema) stays out of scope — the dev should file it as a separate finding if confirmed, not fix it here.

---

Generated by Claude Code

[os-steve]

Unlock scan (spec seat, standby duty): pm:blocked → dispatched in the same stroke. Blocker #9223 closed 07:05Z via PR #9247 (afba4ec25, on origin/main). Re-verified on the merged ref per the triage unlock condition: the pending-registration row exists (packages/runtime/src/dispatcher-error-vocabulary.ts:198, door: 'plugin-route'), and UNIQUE_SCOPE_CONFIRMATION_REQUIRED is absent from error-code-ledger.zod.ts — the ratchet hand-off is armed exactly as the card describes.

Claim: PM loop round 2
Session: session_01Fs18A2DdXLVN2h8PaaFBcP
Branch: claude/issue-9246-register-unique-scope-code
Worktree: objectstack-issue-9246
Domain: domain:spec
File surface: packages/spec/src/api/error-code-ledger.zod.ts (one registration row), packages/runtime/src/dispatcher-error-vocabulary.ts (delete the now-stale pending-registration row, same edit per the ratchet), packages/runtime/src/error-envelope.conformance.test.ts (if the pending-list drive needs it), regenerated content/docs/references/api/** (2 pages post-#9239), .changeset/ (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: fable — triage-mandated contract-review tier (registration widens the accepted ledger set, clause ②); dispatch-gates --tier flags the ledger path as clause-② suspect surface with no path-derived mandate
Serial constraints cleared: error-code-ledger family — no open PR registers a code (checked this round; last registrations #9177/#9170 landed yesterday); #9239 landed 06:35Z so a new code regenerates 2 reference pages, not 11; #9228 (spec/src/data/**) in flight elsewhere, disjoint; #9244 claimed this same round (this seat) touches only scripts/check-error-status-conformance.mjs — file-disjoint, read-coupled via the ledger count in that gate's output (its dev is instructed not to pin the count).

---

Generated by Claude Code