finding: the runtime dispatcher's `capabilities.search` is still presence-gated, so it over-promises the moment the slot is filled

[os-zhuang]

What this is

A finding, filed as a latent declared-≠-enforced gap rather than a live user-facing defect. Surfaced while reviewing #7541 / PR #7577; the third-producer half was named in that PR's "deliberately left alone" section, and this card exists so it does not evaporate when that PR merges.

Observed

There are two producers of capabilities.search, and #7541 only moved one of them.

producer	predicate	file
getDiscovery() — the REST/protocol face	typeof this.searchAll === 'function', ANDed with api.enableSearch	packages/metadata-protocol/src/protocol.ts, packages/rest/src/rest-server.ts (both fixed by #7541)
getDiscoveryInfo() — the runtime dispatcher face	hasSearch = !!searchSvc, i.e. bare service-slot presence	packages/runtime/src/http-dispatcher.ts (~L1111, emitted ~L1372)

Today this is not a live defect, and that is the only reason it is a finding rather than a bug. Nothing in either repository registers the search slot (CORE_SERVICE_PROVIDER records 'search': null, verified across both repos, ADR-0115 Evidence 5), so hasSearch is false on every host that exists. And the dispatcher mounts no /search route at all — there is no search entry in route-ledger.ts and no handler in http-dispatcher.ts — so false is the honest answer for that host. Declared and served agree, by coincidence of an empty slot.

The gap is what happens when the slot is filled. Register any ISearchService on a dispatcher-served host — precisely what the slot exists for, per CoreServiceName's "Search Engine (Elastic/Meili)" — and that producer flips capabilities.search.enabled to true while the host still serves no /search route. A conforming client reads the document, calls the endpoint, and gets the router's 404. That is Prime Directive #10 in its ordinary direction — an advertised endpoint that 404s — and it is the same defect class #7541 just closed on the other producer, merely waiting on a precondition nobody has met yet.

Why it was correctly left out of #7541

Two reasons, both worth keeping:

• The card's seam was the REST/protocol pair. Discovery advertises capabilities.search = {enabled:false} while GET /api/v1/search serves 200 with real hits #7541 was measured against a live GET /api/v1/search answering 200 while the document said false — a symptom this producer cannot exhibit, since it serves no such route.
• Touching it would have broken a green pin for no measured gain. packages/runtime/src/discovery-schema-conformance.test.ts:245 asserts info.capabilities.search.enabled === false, and that assertion is correct for that producer today. Changing the predicate without deciding what the dispatcher's honest answer is would have turned a true pin red.

What a fix would have to decide

Not obvious enough to prescribe here — the point of the card is that someone decides deliberately rather than discovering it from a 404:

1. Serveability, like its sibling. The dispatcher's own doctrine already says this: the comment at http-dispatcher.ts ~L1111 states that every service whose HTTP surface is a dispatcher domain mirrors that domain's own guard (isServiceServeable), "same predicate ⇒ same answer" (plugin-dev 的 analytics dev stub 仍会填满槽位，dispatcher 不检查 handlerReady —— #3891 退役 shim 后同形状的最后一处残留（dev-only） #4000 / dispatcher 其余服务域仍只判槽位占用、不读 handlerReady —— #4000 在 analytics 一域落地后剩下的类推面 #4058). search is not currently a dispatcher domain, which is exactly why it was never brought onto that rule — so the honest answer may simply be a hardcoded false with a comment, until the dispatcher serves search.
2. Or mount the domain, at which point the guard applies and the question answers itself.

Option 1 is the smaller change and is consistent with websockets immediately below it, which is pinned false with the reasoning stated inline (ADR-0076 D12, #2462).

Also worth folding into whatever lands: #5672's Ruling A closed the capability vocabulary and requires every key from every producer, answered from that producer's own facts. Two producers answering one key by two unrelated predicates is legal under that ruling only while both answers happen to be honest — which is the situation this card is about.

Filed unassigned and without a domain:* label so routing stays the triage seat's call.

Related: #7541 (the same defect on the REST/protocol producer, fixed), #5672 (the vocabulary ruling and the serveability rule), #4000 / #4058 (the dispatcher's own same-predicate doctrine), #2462 / ADR-0076 D12 (websockets pinned false with reasoning).

[os-zhuang]

Findings triage — route repair only: +domain:cli. The finding grade is unchanged and no ownership is taken.

Landing site (read, not guessed). All three anchors verified verbatim on origin/main @ 2c1988c: packages/runtime/src/http-dispatcher.ts:1111 (const hasSearch = !!searchSvc;), :1372 (search: { enabled: hasSearch }), plus a third read at :1533 (hasSearch ? svcAvailable(...) : svcUnavailable('search')) the card did not name — worth including in any fix's sweep. packages/runtime ⇒ domain:cli per the domain table. (Either disposition — hardcode false with reasoning like websockets, or mount the domain — lands in the same file, so the routing is not two-sided.)

Grade check. The finding grade is correct as filed: CORE_SERVICE_PROVIDER records the search slot as null on every existing host, so declared and served agree today; the over-promise fires only when someone registers an ISearchService on a dispatcher-served host. Latent declared-≠-enforced, held.

Dedup. #7541 (the REST/protocol producer pair) is the fixed sibling, correctly scoped apart; no open card covers the dispatcher producer.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Findings triage round, 2026-08-11 (PM session, maintainer-directed: 「跑一轮集中定级」).

Graded: promote. #7541 fixed two of the three capabilities.search producers; the dispatcher face still presence-gates and will over-promise the moment the slot is filled. Completing an already-ruled invariant restoration (declared = enforced across all producers) is the named non-escalation class. S.

finding → pm:queue (domain:cli).

---

Generated by Claude Code

[hotlong]

Claim: PM loop round 6 — domain:cli seat.

• Session: session_01B3Kurx8qufrDzNjk4rag7V (account hotlong)
• Branch: claude/issue-7602-dispatcher-search-capability
• Worktree: dedicated (cloud container)
• Domain: domain:cli
• File surface: packages/runtime/src/http-dispatcher.ts (the getDiscoveryInfo() capability block, ~L1111 / emitted ~L1372) + packages/runtime/src/discovery-schema-conformance.test.ts. Stop on breach; explain in the report.
• Container & model: M, mode:cloud, model: claude-opus-5.
• Serial constraints cleared: in flight are mcp-http-surface (b): the stock showcase cannot serve MCP at all — capability resolver substring-matches the outbound MCP client connector #7652 (packages/cli/src/commands/serve.ts) and REST: the UNIQUE_VIOLATION 409 message is hard-coded English and carries no field — and it is less informative than the bulk path's own message for the same constraint #7821/PR fix(rest): name the conflicting field in the UNIQUE_VIOLATION 409 body (#7821) #7930 (packages/rest/src/rest-server.ts mapDataError region). Neither touches packages/runtime. Disjoint.

裁决:选项 1 —— 诚实的 false + 写明理由,⛔ 不挂 domain

Take the card's option 1: the dispatcher's capabilities.search answers a hardcoded false with the reasoning stated inline, exactly as websockets does immediately below it (ADR-0076 D12 / #2462).

Why this and not option 2 (mount a /search domain): the dispatcher serves no /search route — no route-ledger.ts entry, no handler. Mounting one is building a capability nobody asked for, on a slot that no host in either repo registers. Under measured-pull and scope discipline that is a clear defer. Option 1 is also what the dispatcher's own doctrine already says: the comment at ~L1111 states that a service whose HTTP surface is a dispatcher domain mirrors that domain's guard — "same predicate ⇒ same answer" — and search is not a dispatcher domain, which is precisely why bare slot-presence was never the right predicate for it.

The bug is not that the answer is wrong today — it is that the answer is right by accident. hasSearch = !!searchSvc is false only because nothing registers the slot (CORE_SERVICE_PROVIDER records 'search': null). Register any ISearchService — which is what the slot exists for — and the document flips to true while the host still 404s the endpoint. This replaces a coincidence with a reason.

⛔ The existing pin must stay green and keep its meaning

discovery-schema-conformance.test.ts:245 already asserts info.capabilities.search.enabled === false, and that assertion is correct today — the card is explicit that #7541 left this alone rather than turn a true pin red. So:

• ⛔ Do not delete or weaken it.
• ⚠️ But note it currently passes for the accidental reason. Strengthen the coverage so it would fail if the predicate regressed to slot-presence: assert false with a search service registered. That is the whole difference between "right today" and "right on purpose", and without it this change is untestable.

Premise to verify first

On current origin/main: the dispatcher still mounts no /search route (no route-ledger.ts entry, no handler), and getDiscoveryInfo() still derives search from bare slot presence. Line numbers WILL have drifted — find by text. If a /search domain has since been mounted, the ruling's basis is gone: report needs_decision rather than hardcoding false over a route that now exists.

Also fold in #5672's Ruling A where it applies: every key from every producer, answered from that producer's own facts. Two producers answering one key by two unrelated predicates is legal only while both happen to be honest — which is exactly the state this card ends.

---

Generated by Claude Code