The HTTP MCP surface has a SECOND un-merged skill read — `buildMcpBridge.listSkills` in packages/runtime, the half #8328's fix cannot reach

[qq9340100]

Split out of #8328 at review time. Filed by the domain:cli seat, PM session session_01NaS1PAHJcPfAA2acnV53Tn, on the maintainer's direct channel. Unassigned.

The fact

There are two skill reads behind MCP prompts, not one. #8328 was written as though there were one, and its fix (PR #8724) closes only the first:

surface	read	status
stdio (long-lived server)	packages/mcp/src/mcp-server-runtime.ts → bridgePrompts	fixed by PR #8724
HTTP /api/v1/mcp (built per request)	packages/runtime/src/domains/mcp.ts → buildMcpBridge.listSkills	not fixed — this card

Measured on origin/main @ 3508678, packages/runtime/src/domains/mcp.ts:400:

listSkills: async () => {
    const meta: any = await getMeta();
    return (await meta?.list?.('skill')) ?? [];
},

It reads IMetadataService.list('skill') directly — the registry/loader listing, one layer below the sys_metadata overlay merge, which lives in the protocol's getMetaItems. It also has no diagnosed wrapper at all, so it does not carry #6504's completeness verdict either: a known-partial skill surface presents as a complete one.

Why this matters more than a second call site usually would

⚠️ #8328's own three-step reproduction runs through this endpoint. The card says "query the skill over MCP prompts", and both that repro and the pnpm dev banner point at the HTTP surface. So with PR #8724 merged and nothing else, the reproduction on #8328 still answers {"prompts":[]} — verified by #8328's implementer against a running server with the fix in place.

That is why PR #8724 is deliberately Part of #8328 rather than Fixes, and why #8328 must not be closed on the strength of it.

The decision is already made — this is application, not adjudication

The maintainer ruling on #8328 (2026-08-13 ~23:50Z, verbatim 「接受你的全部建议」, option 3) already settled the direction: read from the protocol's merged layer rather than pushing the override merge down into MetadataService. That ruling is unchanged and applies here; only its scope estimate — "entirely inside packages/mcp" — turned out to cover half the surface.

⛔ Do not re-open the layer question here. Option 2 (push the merge into MetadataService.list() for every consumer) remains deliberately not chosen, and the contract question is archived unscheduled as #8722.

What a fix has to be careful about

• Reuse the seam, do not re-derive it. PR fix(mcp): read skill prompts from the protocol's merged metadata listing #8724 exports McpMergedMetadataRead (a duck-typed getMetaItems seam) from packages/mcp. A second hand-rolled shape here is the "one rule, N places" divergence this whole family of cards exists to remove.
• Per-request construction is the real difference. The stdio bridge is assembled once at plugin start(); this one is built per request by the runtime, from a per-environment metadata service (getMeta()), so a multi-tenant host serves each environment its own skills. The merged read has to be resolved on the same per-environment seam — ⛔ not captured once at boot, which would cross-serve environments.
• ⛔ No fallback to the un-merged listing when the merged read throws — same rule PR fix(mcp): read skill prompts from the protocol's merged metadata listing #8724 pinned. Falling back answers registry rows in the shape of merged ones, restoring this defect silently at exactly the moment an overlay is most likely to be the thing being missed.
• IMetadataService.list() presents a known-partial answer as a complete one — the #5840 shape on the plural read #6504's verdict should be added here, not just preserved — unlike the stdio bridge, this read never had a diagnosed wrapper, so this is a gap to close rather than a contract to keep intact. Say so explicitly if you conclude otherwise.
• The ?? [] on a missing meta is load-bearing for hosts with no metadata service; keep the absent-host path reading as it does today.

Serial

Sequence after PR #8724 merges — it exports the seam this should consume, and landing both against one un-merged baseline is how two individually-green changes end up jointly wrong. Different package (packages/runtime vs packages/mcp), so no file conflict, but the dependency is real.

#8328 stays open and carries Blocked-by: this card; it closes when this half lands and its own reproduction finally reflects the override.

Source

Found during PM review of PR #8724 by its implementer, who measured it rather than inferring it and correctly declined to fix it outside the declared file surface. packages/runtime is domain:cli, the same lane as #8328.

[qq9340100]

Claim: PM loop round 2 — the sequencing precondition is now satisfied
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Branch: claude/issue-8726-http-mcp-bridge-merged-skill-read
Worktree: objectstack-issue-8726
Domain: domain:cli
File surface: packages/runtime/src/domains/mcp.ts + tests in packages/runtime/src/** (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: PR #8724 MERGED, and the seam this card consumes is verified present on origin/main — export interface McpMergedMetadataRead at packages/mcp/src/mcp-server-runtime.ts:238. That was the whole reason this card was filed pm:queue with a sequencing note rather than dispatched immediately: landing both halves against one un-merged baseline is how two individually-green changes end up jointly wrong. packages/runtime carries no in-flight claim. This seat's other cards — #8679 (plugin-security), #8566 (plugin-webhooks), #8231 (examples/**), #8628 (service-job) — are all disjoint.

⚠️ This is the half the users actually hit. #8328's own three-step reproduction and the pnpm dev banner both point at /api/v1/mcp, so until this lands that reproduction still answers {"prompts":[]} even with #8724 merged. #8328 is Blocked-by: this card and closes when it lands.

The decision is already made and ⛔ not re-openable: the maintainer's option-3 ruling on #8328 (2026-08-13 ~23:50Z, verbatim 「接受你的全部建议」) says read from the protocol's merged layer, and explicitly does not push the override merge down into MetadataService. This card applies that same decision at a second call site.

Dispatched under the maintainer's direct channel, verbatim instruction: 「identity ＋ services ＋ cli 优先处理 bug」.

---

Generated by Claude Code

[qq9340100]

Review of PR #8759 — ACCEPT, landing held until CI converges

Reviewed against GitHub. Path face: 3 files — domains/mcp.ts, one new test, one changeset. All packages/runtime; no docs/adr/**, no skills roots, no releases ⇒ normal landing path, surface held exactly.

⚠️ My ruling 2 was not implementable as written, and the substitute is better

I ordered: "Reuse the seam, ⛔ do not re-derive it — PR #8724 exports McpMergedMetadataRead." Measured, it is not reachable from packages/runtime: packages/mcp exports that type from its module but its package index re-exports only MCPServerRuntime + config, its exports map exposes only ., and @objectstack/runtime deliberately carries no @objectstack/mcp dependency — the MCP service is resolved by name and the bridge is duck-typed precisely so a host can mount the dispatcher without that package, a property @objectstack/rest relies on.

So obeying me literally would have required editing packages/mcp/src/index.ts (outside the declared surface) and creating a runtime → mcp dependency the architecture is built to avoid. My instruction would have damaged the thing it was meant to protect.

⭐ The resolution is better than what I asked for: point at what McpMergedMetadataRead itself duck-types — Pick<MetadataProtocol, 'getMetaItems'> from @objectstack/spec/api, already a runtime dependency, the contract ObjectStackProtocolImplementation declares implements, and the same declared shape the package's two other getMetaItems consumers read. That serves "one rule, one place" more strongly than reuse would: a Pick cannot drift from the contract; a re-written signature could. Disclosed rather than quietly substituted, which is what makes it checkable.

#8328's reproduction passes — and it is pinned in both directions

The point of this card. Two fresh showcase boots, same three steps, only the build differing:

step	pre-fix	fixed
PUT /api/v1/meta/skill/repro_skill {active:true}	200	200
GET /api/v1/meta/skill (control)	serves the row	serves the row
POST /api/v1/mcp → prompts/list	{"prompts":[]}	[{"name":"repro_skill",…}]

⭐ And {active:false} removes the prompt again — the surface tracks the overlay both ways, not merely "non-empty once". A one-directional check would have passed on a build that simply always lists everything.

The rulings

• Per-request, per-environment seam — my flagged assumption, and it held: deps.resolveService(context, 'protocol', envId), the identical function and scoping getMeta uses, never captured at boot. Two multi-environment tests pin it, which is the failure mode (cross-serving environments) that a boot-time capture would have introduced silently.
• ⛔ No fallback to the un-merged listing on throw — held. The throw reaches the client; per AGENTS.md a failure handed to the caller is not a degradation, so that branch logs nothing.
• Structural absence kept distinct from failure — a host with no metadata protocol keeps the registry listing, ?? [] intact, and the pre-existing http-dispatcher.mcp.test.ts pin passes untouched.
• IMetadataService.list() presents a known-partial answer as a complete one — the #5840 shape on the plural read #6504's verdict added (this read never had one) and asked of listDiagnosed directly, because getMetaItems swallows a MetadataService failure into its own catch — the same reasoning fix(mcp): read skill prompts from the protocol's merged metadata listing #8724 used, reached independently.
• ⛔ Option 2 not taken; Should the sys_metadata overlay merge move down into MetadataService.list(), so every consumer gets merged rows? #8722 stays archived.

⭐ Two pieces of self-correction worth naming

The reverse-verification prediction failed usefully. Predicted 6 red / 4 green; measured 8/4 — and rather than accept the beat, it examined the four greens and found two that could not fail in either direction: one asserted only the absence of another environment's skill (an empty list satisfies it), the other only that nothing was logged (also true of a build with no verdict machinery). Both rewritten to assert what discriminates; re-measured 10 red / 2 green, the two greens being genuine absent-host invariants. That is the second time this round a failed prediction has exposed vacuous assertions instead of being rounded off.

check:type-check-debt caught a real regression — the new test file took @objectstack/runtime's TEST_DEBT from 227 to 228 (TS18048), which the package's own typecheck cannot see because its tsconfig excludes **/*.test.ts. ⭐ Fixed at source, not by raising the entry. Raising a ratchet ceiling is gate-weakening and sits on the maintainer floor; taking the harder correct path when the easy one was one number away is the whole point of having the ratchet.

Cross-package consumer check done — the standing lesson from #8742's queue kick, applied before queueing: packages/qa/dogfood's authz-conformance greps this exact file for buildMcpBridge(deps, context) as a conformance key; call site untouched, suite 15/15.

#8328

⛔ Correctly not closed by this PR — that judgement is mine on the whole symptom, and the dev was told not to take it. When this merges I will close #8328 on the strength of the measured reproduction above, which is the criterion I set when I filed this card.

⛔ Not flipping ready — CI has not converged

Pre-registering: gate jobs success ⇒ ready + auto-merge. The 20 docs the drift bot flagged are the usual packages/runtime fan-out; this changes which layer one internal read consults and falsifies none of them. ⛔ Release-owned pages correctly untouched.

---

Generated by Claude Code

[qq9340100]

{
  "issue": 8726,
  "status": "done",
  "branch": "claude/issue-8726-http-mcp-bridge-merged-skill-read",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/8759",
  "premise_still_valid": true,
  "summary": "Premise confirmed on current main before touching anything: packages/runtime/src/domains/mcp.ts buildMcpBridge.listSkills read meta.list('skill') — the registry/loader listing, one layer below the sys_metadata overlay merge — with no diagnosed wrapper. It now reads the protocol layer's merged getMetaItems, resolved PER REQUEST on the same per-environment seam getMeta() uses; no fallback to the un-merged listing when the merged read throws; structural absence of a merged read keeps the old registry listing including the load-bearing `?? []`; and #6504's completeness verdict is ADDED (it was a gap here, not a contract to preserve), asked of listDiagnosed directly since getMetaItems swallows a MetadataService failure into its own catch. YOUR CENTRAL ASSUMPTION HOLDS, measured not assumed: a protocol service carrying getMetaItems IS reachable per request on that seam — getMeta is deps.resolveService(context,'metadata',envId) and mine is deps.resolveService(context,'protocol',envId), the identical function with identical scopeId scoping (defaultKernel.getServiceAsync(name,scopeId) first, then the request's own kernel). Nothing captured at boot. A DIFFERENT assumption was falsified — ruling 2's seam import; see open_questions 1. #8328's reproduction now PASSES end to end (evidence below), so that card is closeable on your judgement; I added no closing keyword for it.",
  "tests": "ALL AT FINAL HEAD 14bdae8a1, run AFTER the last commit, on a tree with origin/main (b27869580) already merged in. `pnpm --filter @objectstack/runtime test` → 157 files / 2385 tests passed. `pnpm --filter @objectstack/runtime typecheck` → pass. `pnpm check:type-check-debt --re-measure` → OK, 33 entries re-measured in 269.5s, 'none above its recorded number' (the @objectstack/lint -1 surplus is pre-existing and unrelated). THAT RATCHET CAUGHT A REAL REGRESSION rather than rubber-stamping: my new test file took @objectstack/runtime's TEST_DEBT from 227 to 228 (+1, TS18048 'res.response' is possibly undefined) — invisible to the package's own `pnpm typecheck`, whose tsconfig excludes **/*.test.ts. I reproduced the gate's generated project to isolate it, fixed it at source (read the optional dispatcher response with `?.`), and re-measured back to 227 with zero errors from my file. I did NOT raise the ledger entry — shrink-only, maintainer-only. GATE UNION all PASS: check:nul-bytes, check:cross-package-test-inputs (+ the direct script), check:route-envelope, check:test-source-alias, check:type-source-resolution, check:query-options-erasure, check:type-check-coverage, check:changeset-gate-self-tests, check:objectui-changeset, check-adr-0087-registration.mjs, check-changeset-no-major.mjs, check-empty-changeset.mjs. Re-derived against the ACTUAL diff via scripts/pm/dispatch-gates.mjs, which surfaced two families the dispatch did not name — check:route-envelope (matched via packages/runtime/src/domains) and the full changeset family — both run and green. CROSS-PACKAGE CONSUMER CHECK, prompted by your merge-queue warning: packages/qa/dogfood's authz-conformance greps THIS EXACT FILE for /buildMcpBridge\\(deps, context\\)/ as a conformance key; that call site is untouched and the suite passes 15/15. LIVE END-TO-END (#8328's own three steps, two fresh showcase boots, only the build differing): PUT /api/v1/meta/skill/repro_skill {active:true} → 200 on both; GET /api/v1/meta/skill (control) → serves the row on both; POST /api/v1/mcp prompts/list → PRE-FIX {\"prompts\":[]}, FIXED [{\"name\":\"repro_skill\",...}]. prompts/get returned the skill's instructions as the message body, and a follow-up {active:false} PUT removed the prompt again — the surface tracks the overlay BOTH ways, not merely non-empty once. The live ablation was a real rebuild: I mutated the source, rebuilt @objectstack/runtime, and PROVED the mutation reached dist (list?.(\"skill\") inline, readMergedSkillRows present but never called, no getMetaItems skill read) before booting; on restore I rebuilt again and confirmed the artifact flipped back, so no ablated dist is left in the worktree. Source restore proven byte-identical by git hash-object (80c7989…), not by a matching diffstat. REVERSE VERIFICATION, direction predicted BEFORE running: predicted 6 red / 4 green, MEASURED 8 red / 4 green — prediction WRONG, and usefully so. Two of the four greens were vacuous: one asserted only the ABSENCE of another environment's skill (an empty list satisfies it, so it passed with the fix ablated), the other only that nothing was logged (also true of a build with no verdict machinery at all). Both rewritten to assert what actually discriminates; RE-MEASURED 10 red / 2 green, the two greens being exactly the absent-host invariants that never take the merged-read branch. Both numbers are recorded in the test file header and the PR body.",
  "open_questions": [
    {
      "question": "Ruling 2 said to consume `McpMergedMetadataRead` from packages/mcp and ⛔ not re-derive it. That type is NOT REACHABLE from packages/runtime, measured — so I consumed the declared spec contract it duck-types instead. Flagging because it is a deviation from the ruling's letter, taken to serve its intent; it is a two-line change to redirect if you disagree.",
      "options": [
        "A (what shipped) — `type McpMergedMetadataRead = Pick< MetadataProtocol, 'getMetaItems'>` from @objectstack/spec/api. That is the contract `ObjectStackProtocolImplementation` declares `implements`, it is an EXISTING runtime dependency on an already-source-aliased subpath, and it is the same declared `{type, items}` shape the package's two other getMetaItems consumers read. A `Pick` cannot drift from the contract; a re-written signature could — so this serves 'one rule, one place' more strongly than importing a copy would.",
          "B — Make the packages/mcp type reachable: re-export `McpMergedMetadataRead` from packages/mcp/src/index.ts AND add @objectstack/mcp to packages/runtime's dependencies. Blocked twice over: packages/mcp is ⛔ explicitly outside this card's file surface, and packages/runtime deliberately carries NO @objectstack/mcp dependency — the MCP service is resolved by name and the bridge is duck-typed precisely so a host can mount the dispatcher without that package, the property @objectstack/rest's own comment relies on. B would add a package edge to import a type that merely describes something spec already declares.",
        "C — Hand-write a second `getMetaItems(...)` interface in packages/runtime. This is the option ruling 2 actually forbids, and I did not take it."
      ],
      "recommendation": "A, and it shipped. The measurement behind it: packages/mcp exports McpMergedMetadataRead from its MODULE but its package index re-exports only MCPServerRuntime + MCPServerRuntimeConfig, and its exports map exposes only '.', so there is no import path at all without editing packages/mcp. Note this does not weaken ruling 2 — it points both halves at the same upstream source instead of at a copy. If you would rather the two halves share one literal type, the follow-up is a packages/mcp card that re-points McpMergedMetadataRead at Pick< MetadataProtocol,'getMetaItems'> too; I did not file that, since it is a judgement about the other half's surface."
    },
    {
      "question": "#6504's completeness verdict: you said adding one is in scope but to say so explicitly if I concluded otherwise. I ADDED it — flagging only the one judgement inside that call, which is the logging RATE.",
      "options": [
        "A (what shipped) — warn per degraded request. Unlike the stdio half's boot-time snapshot this read runs per request, so a loader outage prints once per MCP call rather than once. I judged that the honest rate: each of those requests really did serve a short prompt list to a client that was told nothing, and the wording says the outage is CURRENT rather than pinned at boot — the one thing the stdio text could not say.",
        "B — Suppress repeats (once per process, or rate-limited). Quieter under a sustained outage, but it would under-report a per-request surface and needs state the bridge does not currently hold."
      ],
      "recommendation": "A. A degraded metadata loader is not a steady state, and AGENTS.md's 'Degradation log levels' puts this squarely at warn (functional: the prompt surface is visibly smaller than the environment declares; nothing claims to have persisted and did not). I also made the verdict probe non-fatal — if listDiagnosed itself throws, the items that already succeeded are still served and the line says completeness 'could not be determined', rather than a new failure mode bought with pure observability."
    }
  ],
  "out_of_scope_findings": [
    "filed as #8760: the runtime resolves the `protocol` service WITHOUT an environment scope at 22 call sites (9 in domains/meta.ts, 12 in domains/packages.ts, 1 in domains/ui.ts) while `metadata` is scoped by envId — the asymmetry I had to resolve to place my own call correctly. LATENT, not live, and filed saying so: metadata-protocol registers the slot unscoped (`ctx.registerService('protocol', …)`), so the scoped branch finds nothing and every call falls through to the request's own kernel. It would become a cross-tenant read the day `protocol` is registered as a scoped factory in shared-kernel mode. `finding` + `domain:cli`, unassigned, NO pm:queue, deduped by keyword and file path over open issues first.",
    "NOT filed, deliberately: examples/app-showcase ships no packaged `skill` — src/coverage.ts:178 defers them explicitly, with a stated reason. That is a recorded product decision, not a defect, so filing would just re-litigate it. It does mean #8328's repro step 1 ('boot a showcase with a packaged skill') is satisfied via the runtime write channel instead (`skill` is allowRuntimeCreate: true); noted in the PR body so nobody reads that substitution as a shortcut."
  ]
}

---

Generated by Claude Code