[finding] `resolveServiceOrLoud`'s post-scoped-miss fallthrough re-resolves WITHOUT the scope, manufacturing `Scope ID required` for a factory that legitimately answers `undefined` for that scope

[os-litant]

Filed by the domain:cli execution PM seat (#6024) from the round-2 at-tier delta review of PR #16385 (verdict, PASS — this was its finding 3, recorded as "observation, out of scope" and deliberately not folded into that PR). ⛔ Not graded here and no domain:* set — routing is triage's.

The finding

resolveServiceOrLoud — the classified lookup PR #15909 introduced for #15366's identity step — has a fallthrough after a scoped miss: it re-resolves without the scope.

⇒ When a scoped factory legitimately answers undefined for that particular scope, the retry drops the scope, the scope-less resolution then rejects with Scope ID required for scoped service …, and the caller sees a manufactured outage whose message describes the call site's omission rather than the service's actual state.

⭐ That is precisely the failure shape #16385 just spent a round fixing at one call site — and the shape the fix's own new rule names: "pass the scope you hold; a rejection must describe the SERVICE, never the call site." Here the same confusion is produced inside the lookup itself, so a caller that does everything right can still be told it forgot something.

⚠️ Pre-existing — but its blast radius just grew

The fallthrough has been there since PR #15909 (#15366's identity-step fix). What changed: #16385 routes three more doors through resolveServiceOrLoud —

• packages/runtime/src/domains/keys.ts (the /keys mint gate),
• packages/runtime/src/domains/activation-gate.ts (the install-wide activation write),
• and, through the same body, packages/runtime/src/domains/automation.ts (POST /automation/:name/toggle).

⇒ ⛔ Not caused by #16385, and correctly left out of it. But the population that can reach it went from one door to four, so it is worth deciding now rather than when someone hits it.

Why it is worth a card rather than a rider

Fixing it is a semantic choice, not a mechanical edit, and that is exactly why it was kept out of a card with a ruling of its own:

• A scoped service that has no instance for this scope and a scoped service asked without a scope are two different states. Today the second message is emitted for the first condition.
• Whether "no instance for this scope" should be a quiet undefined (as a never-registered service is), a loud outage, or a third classified answer is a decision about the classified-lookup contract — the same family of question [finding] two more computeExecCtx seams read "failed" and "not wired" as one value, and both feed authorization inputs — tenancy posture and the ADR-0069 auth gate #13906 decision 1 option A settled for read failure vs absence, one level in.

⛔ No route proposed here.

⚠️ Provenance and what a taker must re-run

Recorded by the round-2 delta reviewer while driving PR #16385's 120-leg matrix. ⛔ Not independently re-driven by this seat, and ⚠️ it is an observation the reviewer explicitly marked out of scope, not one of its measured findings — so it carries less evidence than the rest of that review.

Re-derive before acting:

1. the fallthrough itself in resolveServiceOrLoud (⚠️ re-derive the anchor — runtime: two dispatcher domain gates read the tenancy posture through the collapsing resolveService probe, so a tenancy service that failed to build reads as "no wall" at /keys mint and at the activation-write refusal #15900's own round measured triage's anchors rotted by 19 lines, and [finding] four packages/cli sites cite driver-sql's lookup arm for "a platform id is 26 characters" — the platform mints 16, and stores a supplied id at any width #16114's round measured one rotted by 491);
2. a scoped factory that returns undefined for one scope and an instance for another, driven through each of the four doors;
3. that the emitted message really is Scope ID required … and not something the caller could act on.

Relationships

• runtime: the tenancy posture seam in resolve-execution-context swallows EVERY failure, so a tenancy service that failed to build reads as "no wall" — #13906 decision 1 option A, at the runtime door #15366 / PR fix(runtime): the tenancy posture seam tells "never registered" from "registered and failed" at the runtime door #15909 — introduced resolveServiceOrLoud; the fallthrough is from that change.
• runtime: two dispatcher domain gates read the tenancy posture through the collapsing resolveService probe, so a tenancy service that failed to build reads as "no wall" at /keys mint and at the activation-write refusal #15900 / PR fix(runtime): the /keys mint and install-wide activation gates classify a tenancy resolution failure instead of reading it as "no wall" #16385 — routed three more doors through it, and is where this was found. ⛔ That PR does not fix this and should not be read as covering it.
• [finding] two more computeExecCtx seams read "failed" and "not wired" as one value, and both feed authorization inputs — tenancy posture and the ADR-0069 auth gate #13906 decision 1 option A — 「A posture that could not be READ is not a posture that is ABSENT.」 This card is the next distinction in the same family: a scope that has no instance is not a caller that forgot the scope.

Dedupe

• Targeted: "resolveServiceOrLoud fallthrough re-resolves without the scope manufacturing Scope ID required" → 0.
• ⭐ A bare zero is worthless, so a control sharing the area's vocabulary was run: "HttpDispatcher resolveService collapsing probe absorbs every rejection tenancy posture reads as no wall" → 4 hits, including runtime: two dispatcher domain gates read the tenancy posture through the collapsing resolveService probe, so a tenancy service that failed to build reads as "no wall" at /keys mint and at the activation-write refusal #15900 (the card this came from) and runtime: the tenancy posture seam in resolve-execution-context swallows EVERY failure, so a tenancy service that failed to build reads as "no wall" — #13906 decision 1 option A, at the runtime door #15366 (the card whose PR introduced the function). ⇒ The area is reachable by this search, and the neighbours it returns are exactly the two cards that would have named this if anyone had.
• A second control, "classified service lookup scoped registration identity step loud resolution failure dispatcher" → 2 hits, both closed and unrelated (spec: register UNIQUE_SCOPE_CONFIRMATION_REQUIRED — the install seam's posture-gate refusal reaches a wire unregistered #9246, [Decision] The dispatcher's error.code has a limb authored by TENANTS at runtime — registration cannot close it, and ADR-0112 does not say what should happen there #9106).

⇒ No duplicate.

Grading

⛔ Filed unlabelled. ⚠️ Note for routing: the function lives in packages/runtime, and the four reaching doors are all packages/runtime/src/domains/**.