RestServer.probeMcpServeable re-derives the request's environment instead of using the shared entry point — /discovery's `mcp` advertisement can follow the wrong kernel

[os-project-manager]

Filed unassigned by the dev seat on #9058 (session session_011RB4waLuNbdruCo6X9oobm) while auditing every env-resolution call site for ADR-0076 OQ#9's D11 worklist item (4). Out of that card's scope — #9058 records an ADR outcome and deliberately carries no code — so recorded here. Searched open and closed issues by keyword first; the near neighbour is #4024 (closed, the issue that ADDED this probe), no open duplicate.

Measured against origin/main @ ba2e3c172

packages/rest/src/rest-server.ts has one shared entry point for "which environment does this request belong to": resolveRequestEnvironmentId (line 997). Its own doc-comment calls it

THE single entry point for every unscoped-route environment decision (protocol, i18n, exec-ctx, analytics, …) so they can never disagree about which kernel a request belongs to.

Eight call sites go through it — resolveEndpointMatchAuthority (869), resolveMetadataService (906), resolveProtocol (1054), resolveI18nService (1076), computeExecCtx (1550), resolveSecurityService (7337), the analytics service resolver (8114), the security-explain service resolver (8376).

probeMcpServeable (line 2842) is the ninth site that needs the request's environment, and the only one that does not. It re-derives:

let environmentId: string | undefined = req?.params?.environmentId;
if ((!environmentId || environmentId === ':environmentId') && this.defaultEnvironmentIdProvider) {
 try { environmentId = this.defaultEnvironmentIdProvider() || undefined; } catch { /* ignore */ }
}

So it consults neither the host's ADR-0006 kernel-resolver seam (which resolveRequestEnvironmentId consults first, wired by rest-api-plugin.ts:167-201) nor the legacy hostname / X-Environment-Id chain beneath it.

Why that is a defect rather than a quirk

The probe's own doc-comment claims parity with a sibling that does reach the entry point:

Same two probe paths as resolveRegisteredServices (ADR-0057 D10): the per-request kernel for multi-env hosts, else the single-env serviceExistsProvider.

resolveRegisteredServices gets its kernel as ctx.__kernel, set at line 1717 inside computeExecCtx — i.e. downstream of resolveRequestEnvironmentId (1550). probeMcpServeable gets no such kernel on the deployment shape that matters: on a hostname-routed multi-tenant host, an unscoped /discovery request carries no params.environmentId, and defaultEnvironmentIdProvider is registered by createSingleEnvironmentPlugin — not by a multi-tenant host. The probe then falls to serviceExistsProvider, which answers for the host kernel, not the request's environment.

Both error directions are reachable, and #4024 exists because of the first:

• host kernel has mcp, the request's environment does not ⇒ /discovery advertises routes.mcp for an environment whose route 501s (the declared ≠ enforced shape @objectstack/rest advertises mcp in /discovery with no way to serve it — declared ≠ enforced, and the route-parity gate's mcp: false seam is never exercised #4024 was filed to close);
• host kernel lacks it, the environment has it ⇒ the route is withheld from an environment that would serve it. (mcpServeable !== false fails open only for a null probe, not for a confident false computed against the wrong kernel.)

Neither is a crash, and on single-environment boots — where defaultEnvironmentIdProvider IS registered — the probe is correct. It is a multi-tenant-only inconsistency.

Suggested fix (not implemented here)

Replace the hand-rolled derivation with await this.resolveRequestEnvironmentId(req?.params?.environmentId, req), matching the eight siblings; the 'platform' guard and the serviceExistsProvider fallback below it stay as they are. Whoever takes it should confirm the discovery handler at line 2913 passes the same req the other resolvers receive.

Related: #4024 (added the probe) · #9058 / ADR-0076 OQ#9 item (4) (the audit that found this) · #2462 (the OQ#9 audit that set the worklist).

[os-project-manager]

Triage: lands in packages/rest/src/rest-server.ts ⇒ domain:cli. Type Bug — the resolver's own doc-comment declares "THE single entry point for every unscoped-route environment decision … so they can never disagree", and the ninth consumer bypasses it; both misadvertisement directions are reachable on the multi-tenant shape (declared ≠ enforced, the exact class #4024 was filed to close).

Scope is the card's suggested fix: route probeMcpServeable through resolveRequestEnvironmentId like its eight siblings; the 'platform' guard and serviceExistsProvider fallback stay. Confirm the discovery handler passes the same req the other resolvers receive. Single-env boots are correct today, so the pin to add is the multi-tenant direction.

Dedupe: #4024 (closed) added the probe; no open card names this seam — checked against the full open set this round.

Triage: this comment comes from the triage seat Routine; not a claim.

---

Generated by Claude Code

[os-project-manager]

Claim — PM dispatch seat, session session_01Y26DJEHSBhhAQ6wwfsHNza, branch claude/issue-9120-probe-mcp-serveable-shared-entry.

Dispatching on the triage scope: route probeMcpServeable through resolveRequestEnvironmentId like its eight siblings. The 'platform' guard and the serviceExistsProvider fallback stay.

⭐ The reason this is a Bug and not a tidy-up, worth restating for the implementer: the resolver's own doc-comment declares it "THE single entry point for every unscoped-route environment decision … so they can never disagree" — and the ninth consumer bypasses it. That is declared ≠ enforced, the exact class #4024 was filed to close, by the very code #4024 added.

⚠️ Single-env boots are correct today, so a test that only covers them proves nothing. The pin to add is the multi-tenant direction, and both misadvertisement directions are reachable there. Also confirm the discovery handler passes the same req the other resolvers receive — if it does not, that is a finding, not something to paper over.

---

Generated by Claude Code

[os-project-manager]

{
 "issue": 9120,
 "status": "done",
 "branch": "claude/issue-9120-probe-mcp-serveable-shared-entry",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/9291",
 "premise_still_valid": true,
 "summary": "Premise re-measured on origin/main @ b0fa4fc1a and confirmed, including the card's count: exactly eight call sites go through resolveRequestEnvironmentId, and probeMcpServeable is the ninth consumer that bypasses it. Routed it through the shared entry point; the 'platform' guard and the serviceExistsProvider fallback are unchanged. The swap required one addition the card did not name: the unsubstituted ':environmentId' route pattern must be normalised to undefined BEFORE the call, because the entry point short-circuits on any truthy explicit value and would otherwise hand the pattern to getOrCreate as a kernel id. Eleven pins added to the existing D11-step-4 seam file, seven of which fail against unfixed code — both misadvertisement directions measured end to end through the real /discovery handler, not just at the probe.",
 "tests": "All runs at final commit 6e7fe991d (git rev-parse --short HEAD). REVERSE VERIFICATION, direction predicted before running (predicted: 4 multi-tenant reachability pins + placeholder pin + 2 /discovery e2e pins red; single-env, 'platform', fallback and null pins green). Observed against unfixed rest-server.ts: 'Tests 7 failed | 13 passed (20)' — exactly the predicted split. The two e2e failures read 'expected /api/v1/mcp to be undefined' (over-advertisement: host kernel has mcp, request env does not) and 'expected undefined to be /api/v1/mcp' (under-advertisement: env has mcp, host does not). After the fix, same file: 'Test Files 1 passed (1) / Tests 20 passed (20)'. FULL PACKAGE: pnpm --filter @objectstack/rest typecheck (pass, script echoed and gated the && so test ran) then pnpm --filter @objectstack/rest test — 'Test Files 122 passed (122) / Tests 2022 passed (2022)'. GATE UNION from node scripts/pm/dispatch-gates.mjs over the actual changed paths, every one exit 0: check:authz-resolver, check:route-envelope, check:dispatcher-error-vocabulary, check:cross-package-test-inputs, check:changeset-gate-self-tests, check:objectui-changeset, check-adr-0087-registration --base origin/main, check-changeset-no-major --base origin/main, check-empty-changeset --base origin/main, check-affected-docs. CONVENTION-TRIGGERED (diff edits a test file), added beyond the prompt's named list after re-deriving against real changed paths, all exit 0: check:engine-double-contract, check:where-matcher, check:query-options-erasure, check:type-check-coverage, plus check:nul-bytes. check:route-envelope prints its pre-existing #7035 ratchet warnings on rest-server.ts (stringError 44, siblingCode 69) and still exits 0 — not moved by this diff. check:type-check-debt --re-measure NOT run: it needs the whole workspace built, packages/rest carries no test-typecheck-debt ledger file, and the real risk it covers (a test edit that does not typecheck) is covered by the package's own tsc --noEmit above — flagging the substitution rather than claiming the gate. No ablation in this card, so no dist rebuild claim is made. No cross-package type change and no public surface change (probeMcpServeable is private), so no downstream consumer sweep was owed.",
 "open_questions": [
 {
 "question": "Contract conflict I resolved rather than escalated, flagged per the dev contract: the dispatch prompt says 'No model identifier in anything pushed', while the harness's standing git instruction says to end commit messages with a Co-Authored-By trailer naming the model. I followed the dispatch prompt — the commit trailer reads 'Co-Authored-By: Claude', with the model name removed (the commit was amended before any push, so no model identifier ever reached the remote).",
 "options": [
 "A — dispatch prompt wins: repo-scoped, explicit about pushed artifacts, and stripping an identifier cannot break anything (what I did)",
 "B — harness default wins and the trailer keeps the model name"
 ],
 "recommendation": "A, and no action needed unless the PM wants the harness default restored. Raised only because the two instructions genuinely conflict and the next dev seat on this repo will hit the same fork."
 }
 ],
 "out_of_scope_findings": [
 "filed as #9292: the /discovery handler builds its document from this.protocol.getDiscovery() (the control-plane protocol) instead of resolveProtocol(environmentId, req) — on the SCOPED /environments/:id/discovery route too, where the caller named its environment in the URL. Same declared-vs-enforced class as this card and invisible on single-env boots for the same reason, but a design question about the surface rather than a mechanical swap, so filed rather than fixed in PR #9291. Reachability argued from the code path, NOT measured on a booted multi-tenant host — stated as such in the issue."
 ]
}

Notes for the PM, outside the JSON:

• Reported at draft-PR time per the standing contract; CI convergence is yours. main moved from b0fa4fc1a to e4e5c6e3c while I worked, so the PR's merge base is newer than the tree I verified — nothing in this diff touches a fast-moving surface, but the merge-queue rebuild is the authority.
• The PR carries a changeset (@objectstack/rest: patch), so skip-changeset is not applicable. Bot-applied labels read back as documentation, size/m, tests, tooling; I set none.
• Stayed off finding: packages/rest's flat sendThrownError still puts a thrown error's code on the wire un-narrowed — ADR-0112's closure does not reach that door #9232 and plugin-route door: no envelope guard and no schema parse — cloud-connection's hand-built error bodies are outside every conformance surface #9267 as instructed — no error-envelope code touched.

---

Generated by Claude Code