Repository navigation
mcpx: Phase 2 of #2386 — relevance-ranked local completion (exact → prefix → substring tiers; upstream order untouched) #2388
Description
Phase 2 of design #2386 (mcpx completion, finished). Design doc: files/designs/code-mcpx-completion-rate-limit-ranking.md in the keep-the-four-repos-healthy goal workspace. The decision is recorded on #2386. Independent of Phase 1.
Scope
Relevance ranking inside localCompletion (pkgs/mcpx/internal/daemon/ops.go:402) — the cached-names fallback used when an upstream never declared completions. Today it returns hasPrefixFold prefix matches over the pool's name-sorted cache (internal/pool/pool.go:915): alphabetical, prefix-only.
Ranking (deterministic), applied to prompt names for ref/prompt and template URIs for ref/resource:
- Exact case-folded match first
- Prefix matches next — shorter name first, alphabetical tiebreak
- Substring (non-prefix) matches last — by first-match position, then alphabetical (the spec's "fuzzy matching where appropriate" slice; a value typed mid-name currently finds nothing)
The completion.maxValues cap (spec max 100) applies after ranking; total/hasMore keep their current meaning.
Upstream answers are not touched: when the upstream declares completions, its values pass through in its order with its total — the upstream ranks with knowledge mcpx does not have.
Acceptance
-
localCompletiontests demonstrate the three tiers in order for both ref types, including a mid-name substring hit that previously returned nothing - Cap is applied after ranking (the best matches survive truncation, not the alphabetically first)
-
total/hasMoreunchanged in meaning; thesource: "cache"/becauseresponse fields are unchanged - A test pins that an upstream-declared server's answer order is passed through unranked
- Tests run via CI per fleet policy (no builds on the sandbox)
Out of scope: rate limiting (Phase 1), register changes (Phase 3), changing what the fallback can complete (still only cached prompt names / template URIs — mcpx cannot invent argument values).
Activity
developing-today commentedon Oct 29, 2026
CODE-1215
dezren39 commentedon Oct 29, 2026
🤖 Agent note · filed by design architect
dezren39 commentedon Oct 29, 2026
Intake review
Related: #2386 (design), #2387 (Phase 1, independent), #2389 (Phase 3 register truth-up)
Notes: Phase 2 of the #2386 design: relevance-ranked local completion (exact → prefix → substring) in
localCompletion, upstream answers untouched. The body carries a full## Acceptancechecklist with file:line scope (ops.go:402, pool.go:915), so this pass is labels-only.Risks: Ranking must apply before the completion.maxValues cap or the best matches get truncated away; upstream-order passthrough is the regression to pin hardest.
Suggested approach: Implement the three tiers in localCompletion with the tier-order tests for both ref types, plus the upstream-passthrough pin; verify via CI per fleet policy.
🤖 Agent note · filed
meta/enrichedapplied; acceptance criteria appended to the body only where no acceptance section existed (original body preserved verbatim above it). Still-live check this pass: no merged PR or fix commit explicitly resolving this issue was found in this pass's search.25 remaining items
dezren39 commentedon Oct 30, 2026
Resumed by repo queue worker (lane E) as queue task 3974 — picking up from the
awaiting_cicheckpoint on PR #2857: fresh check of PR checks and Codex findings, merge if green and dispositioned.Merge pull request #2857 from developing-today/queue/3974-2388-ranked…
dezren39 commentedon Oct 30, 2026
Done — PR #2857 merged (merge commit de59b34). Resumed from the
awaiting_cicheckpoint: all checks green on head 00a88b7 (lint, plugin tests, docs build, stress PR-changed-tests, CI budget) and the Codex review completed with zero findings, so the merge gate was clear.