indifferentketchup
ec48066a80
codecontext Dockerfile and docker-compose adjustments for sidecar build. MCP example config cleanup (remove deprecated entries). pnpm-lock.yaml updated for new dependencies.
91 lines
4.9 KiB
Markdown
91 lines
4.9 KiB
Markdown
# 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).
|