boocode/codecontext/openspec/codesight-merge.md

codecontext — codesight feature merge

Port codesight's highest-value analysis capabilities into codecontext as 4 new MCP tools. All work in /opt/forks/codecontext (Go). BooCode wrapper tools in a follow-up batch.

New tools

1. get_blast_radius (Tier 1)

Input: file_path (required), target_dir (optional) Output: markdown listing all files, routes, and symbols that depend (transitively) on the given file.

Algorithm: build a reverse adjacency map from s.graph.Edges (filter by type == "imports"), then BFS outward from the target file's node. Report each affected file with its symbol count and distance from the source.

Codesight reference: detectors/blast-radius.ts (128 lines). The Go port is simpler — codecontext already has the edge graph; codesight had to build its own.

~50 lines of Go (handler + BFS).

2. get_hot_files (Tier 1)

Input: target_dir (optional), limit (optional, default 20) Output: ranked list of most-imported files with import count.

Algorithm: count incoming "imports" edges per file node. Sort descending. Return top N.

Codesight reference: detectors/graph.ts hot-files metric. codecontext's identifyHotspotFiles() at relationships.go:286 already computes this — the tool just needs to expose it.

~30 lines of Go (handler + sort).

3. get_routes (Tier 2)

Input: target_dir (optional), framework (optional filter — "fastify", "express", etc.) Output: structured list of HTTP routes with method, path, file, line number, middleware, tags.

Algorithm: for each TypeScript/JavaScript file in the graph, re-parse the AST via gb.parser.ParseFile() and walk the tree for call expressions matching framework-specific patterns:

Fastify patterns (primary — Sam's stack):

• app.get('/path', handler) / app.post(...) / etc.
• app.route({ method: 'GET', url: '/path', handler }) (object form)
• app.register(plugin) (plugin registration — note but don't trace into)

Express patterns (secondary — common in analyzed projects):

• router.get('/path', ...middleware, handler)
• app.use('/prefix', router)

Tag inference: scan handler body for common patterns (SQL queries → db tag, auth checks → auth tag, cache reads → cache tag). Simplified version of codesight's 30-framework tagger — only Fastify + Express for now.

Codesight reference: detectors/routes.ts (1969 lines) + ast/extract-routes.ts (14690 lines). The Go port is ~200 lines targeting only 2 frameworks.

4. get_middleware (Tier 2)

Input: target_dir (optional) Output: list of detected middleware with type (auth, cors, rate-limit, validation, error-handler, logging), file, line.

Algorithm: for each file, scan for common middleware registration patterns:

• app.register(fastifyCors, ...) → CORS
• app.addHook('preHandler', authCheck) → auth
• app.setErrorHandler(...) → error-handler
• Import-name heuristics: @fastify/cors → CORS, @fastify/rate-limit → rate-limit

Codesight reference: detectors/middleware.ts (217 lines). Go port: ~80 lines, Fastify-focused.

Architecture

All 4 tools register in internal/mcp/server.go:registerTools() following the existing pattern (mcp.AddTool).

Tools 1-2 (blast radius, hot files) operate on the existing CodeGraph — no re-parsing needed. They read s.graph.Edges and s.graph.Files under s.graphMu.RLock().

Tools 3-4 (routes, middleware) need AST access. The current pipeline discards ASTs after symbol extraction. Two options:

• (a) Re-parse on demand: when get_routes is called, iterate TypeScript files in s.graph.Files, call s.analyzer.parser.ParseFile() for each, walk the AST. Slower but no structural change.
• (b) Cache route/middleware data during analysis: modify processFile() in graph_analysis.go to extract routes alongside symbols, store in a new FileNode.Routes field. Faster on repeated calls but requires graph-builder changes.

Recommendation: (a) for this batch. Re-parse is acceptable because route extraction runs on human timescale (one tool call, not per-token), and most projects have <50 route files. Optimize to (b) later if needed.

New Go files:

• internal/mcp/blast_radius.go — handler + BFS
• internal/mcp/hot_files.go — handler + sort
• internal/mcp/routes.go — handler + AST route extraction for Fastify + Express
• internal/mcp/middleware.go — handler + middleware pattern detection

Hard rules

• Go code. Tree-sitter for AST parsing (already in the project).
• No new Go deps (tree-sitter + MCP SDK already present).
• go build ./... clean. go test ./... passing.
• Test coverage: at least one test per new tool exercising the happy path.
• Don't modify existing tool behavior.

Estimate

~400 lines of Go across 4 new files + registration in server.go. Blast radius and hot files are trivial (graph queries). Routes and middleware are the bulk (AST walking + pattern matching).