# 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).