Problem
PRs #130 (phase 1) and #132 (phase 2) introduced the ServerContext class and migrated all 9 tool registrations to accept it as a parameter. However, several internal helper modules still reach into process-global singletons directly rather than receiving context through parameters. Specifically, the format-query-result response formatter, the URL generator built-in registration helpers (url-builtins), and the guided-query orchestration helper read from src/core/server/url-registry.ts and src/core/server/suggestion-flow.ts globals, bypassing the ServerContext instance that tool handlers already hold. This leaves the refactor incomplete: tools are context-aware but their internal call chains still couple to module-level state.
Acceptance Criteria
Implementation Notes
Key files to modify: the response formatting helper (likely src/core/server/tool-response.ts or a format-query-result module), src/alliance/tools/guided-query.ts, and any URL built-in registration utility under src/alliance/. Follow the pattern established in PR #132 where tool handlers receive ctx: ServerContext and access ctx.urlRegistry, ctx.suggestionFlow, etc. This is a mechanical threading exercise — each helper's signature gains a context parameter, and callers (already context-aware from phase 2) pass it through. Watch for circular dependency: if guided-query imports from src/core/server/ helpers that also import from alliance, extract a shared interface. Depends on phases 1 and 2 being merged (both are).
References
- Eval finding: Tests 12 (Resource Management), 14 (Ownership Clarity), 15 (Mutability Discipline) — all survived; compound dynamic "Dual-Path Mutation Race" (Tests 5, 13, 14, 35)
- Related files:
src/core/server/url-registry.ts, src/core/server/suggestion-flow.ts, src/alliance/tools/guided-query.ts, src/core/server/tool-response.ts, src/core/setup.ts
Problem
PRs #130 (phase 1) and #132 (phase 2) introduced the
ServerContextclass and migrated all 9 tool registrations to accept it as a parameter. However, several internal helper modules still reach into process-global singletons directly rather than receiving context through parameters. Specifically, theformat-query-resultresponse formatter, the URL generator built-in registration helpers (url-builtins), and theguided-queryorchestration helper read fromsrc/core/server/url-registry.tsandsrc/core/server/suggestion-flow.tsglobals, bypassing theServerContextinstance that tool handlers already hold. This leaves the refactor incomplete: tools are context-aware but their internal call chains still couple to module-level state.Acceptance Criteria
format-query-resulthelper acceptsServerContext(or a narrowed interface) instead of importinggetUrlGenerators()directlyguided-queryorchestration logic receivesServerContextand delegates to its owned suggestion-flow map rather than the globalstateByNamespaceurlGeneratorsmapImplementation Notes
Key files to modify: the response formatting helper (likely
src/core/server/tool-response.tsor aformat-query-resultmodule),src/alliance/tools/guided-query.ts, and any URL built-in registration utility undersrc/alliance/. Follow the pattern established in PR #132 where tool handlers receivectx: ServerContextand accessctx.urlRegistry,ctx.suggestionFlow, etc. This is a mechanical threading exercise — each helper's signature gains a context parameter, and callers (already context-aware from phase 2) pass it through. Watch for circular dependency: ifguided-queryimports fromsrc/core/server/helpers that also import from alliance, extract a shared interface. Depends on phases 1 and 2 being merged (both are).References
src/core/server/url-registry.ts,src/core/server/suggestion-flow.ts,src/alliance/tools/guided-query.ts,src/core/server/tool-response.ts,src/core/setup.ts