diff --git a/.claude/hooks/track-moves.sh b/.claude/hooks/track-moves.sh new file mode 100644 index 00000000..1487ef22 --- /dev/null +++ b/.claude/hooks/track-moves.sh @@ -0,0 +1,93 @@ +#!/usr/bin/env bash +# track-moves.sh — PostToolUse hook for Bash tool calls +# Detects mv/git mv/cp commands and logs all affected paths +# (both source and destination) to .claude/session-edits.log so that +# guard-git.sh can validate commits that include moved/copied files. +# Always exits 0 (informational only, never blocks). + +set -euo pipefail + +INPUT=$(cat) + +# Extract the command from tool_input JSON +COMMAND=$(echo "$INPUT" | node -e " + let d=''; + process.stdin.on('data',c=>d+=c); + process.stdin.on('end',()=>{ + const p=JSON.parse(d).tool_input?.command||''; + if(p)process.stdout.write(p); + }); +" 2>/dev/null) || true + +if [ -z "$COMMAND" ]; then + exit 0 +fi + +# Only care about mv / git mv / cp commands +if ! echo "$COMMAND" | grep -qE '(^|\s|&&\s*)(mv|git\s+mv|cp)\s+'; then + exit 0 +fi + +PROJECT_DIR="${CLAUDE_PROJECT_DIR:-.}" +LOG_FILE="$PROJECT_DIR/.claude/session-edits.log" + +# Use node to parse the command and extract all file paths involved +PATHS=$(echo "$COMMAND" | node -e " + const path = require('path'); + let d = ''; + process.stdin.on('data', c => d += c); + process.stdin.on('end', () => { + const base = path.resolve(process.argv[1]); + const results = new Set(); + + // Split on && or ; to handle chained commands + const parts = d.split(/\s*(?:&&|;)\s*/); + + for (const part of parts) { + // Match: mv / cp / git mv followed by arguments + const m = part.match(/(?:git\s+mv|mv|cp)\s+(.+)/); + if (!m) continue; + + // Simple arg splitting that respects quotes + const raw = m[1]; + const args = []; + let cur = ''; + let q = null; + for (let i = 0; i < raw.length; i++) { + const c = raw[i]; + if (q) { if (c === q) q = null; else cur += c; } + else if (c === '\"' || c === \"'\") { q = c; } + else if (c === ' ' || c === '\\t') { if (cur) { args.push(cur); cur = ''; } } + else { cur += c; } + } + if (cur) args.push(cur); + + // Filter out flags (-f, -v, --force, etc.) + const paths = args.filter(a => !a.startsWith('-')); + + // Resolve each path relative to project root + for (const p of paths) { + const abs = path.resolve(p); + const rel = path.relative(base, abs).split(path.sep).join('/'); + if (!rel.startsWith('..')) results.add(rel); + } + } + + process.stdout.write([...results].join('\\n')); + }); +" "$PROJECT_DIR" 2>/dev/null) || true + +if [ -z "$PATHS" ]; then + exit 0 +fi + +# Append timestamped entries for every affected path +mkdir -p "$(dirname "$LOG_FILE")" +TS=$(date -u +%Y-%m-%dT%H:%M:%SZ) +while IFS= read -r rel_path; do + if [ -n "$rel_path" ]; then + echo "$TS $rel_path" >> "$LOG_FILE" + fi +done <<< "$PATHS" + +exit 0 diff --git a/.claude/settings.json b/.claude/settings.json index 8962b4f5..e9699759 100644 --- a/.claude/settings.json +++ b/.claude/settings.json @@ -62,6 +62,16 @@ "timeout": 5 } ] + }, + { + "matcher": "Bash", + "hooks": [ + { + "type": "command", + "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/track-moves.sh\"", + "timeout": 5 + } + ] } ] } diff --git a/roadmap/BACKLOG.md b/roadmap/BACKLOG.md new file mode 100644 index 00000000..5098e4c0 --- /dev/null +++ b/roadmap/BACKLOG.md @@ -0,0 +1,69 @@ +# Codegraph Feature Backlog + +**Last updated:** 2026-02-23 +**Source:** Features derived from [COMPETITIVE_ANALYSIS.md](../generated/COMPETITIVE_ANALYSIS.md) and internal roadmap discussions. + +--- + +## How to Read This Backlog + +Each item has a short title, description, category, expected benefit, and four assessment columns left blank for prioritization review: + +| Column | Meaning | +|--------|---------| +| **Zero-dep** | Can this feature be implemented without adding new runtime dependencies to the project? A checkmark means it builds entirely on what we already ship (tree-sitter, SQLite, existing AST). Blank means it needs evaluation. Features that require new deps raise the install footprint and maintenance burden — they need stronger justification. | +| **Foundation-aligned** | Does this feature align with the [FOUNDATION.md](../FOUNDATION.md) core principles? Specifically: does it keep the graph always-current (P1), maintain zero-cost core with optional LLM enhancement (P4), respect embeddable-first design (P5), and stay honest about what we are — a code intelligence engine, not an application (P8)? A checkmark means full alignment. An X means it conflicts with at least one principle and needs a deliberate exception. | +| **Problem-fit (1-5)** | How directly does this feature address the core problem from our README: *AI coding assistants waste tokens re-orienting themselves in large codebases, hallucinate dependencies, and miss blast radius.* A 5 means it directly reduces token waste, prevents hallucinated deps, or catches breakage. A 1 means it's tangential — nice to have but doesn't solve the stated problem. | +| **Breaking** | Is this a breaking change? `Yes` means existing CLI output, API signatures, DB schema, or MCP tool contracts change in incompatible ways. `No` means it's purely additive. Breaking changes require a major version bump. | + +--- + +## Backlog + +| ID | Title | Description | Category | Benefit | Zero-dep | Foundation-aligned | Problem-fit (1-5) | Breaking | +|----|-------|-------------|----------|---------|----------|-------------------|-------------------|----------| +| 1 | Dead code detection | Find symbols with zero incoming edges (excluding entry points and exports). Agents constantly ask "is this used?" — the graph already has the data, we just need to surface it. Inspired by narsil-mcp, axon, codexray, CKB. | Analysis | Agents stop wasting tokens investigating dead code; developers get actionable cleanup lists without external tools | | | | | +| 2 | Shortest path A→B | BFS/Dijkstra on the existing edges table to find how symbol A reaches symbol B. We have `fn` for single-node chains but no A→B pathfinding. Inspired by codexray, arbor. | Navigation | Agents can answer "how does this function reach that one?" in one call instead of manually tracing chains | | | | | +| 3 | Token counting on responses | Add tiktoken-based token counts to CLI and MCP responses so agents know how much context budget each query consumed. Inspired by glimpse, arbor. | Developer Experience | Agents and users can budget context windows; enables smarter multi-query strategies without blowing context limits | | | | | +| 4 | Node classification | Auto-tag symbols as Entry Point / Core / Utility / Adapter based on in-degree/out-degree patterns. High fan-in + low fan-out = Core. Zero fan-in + non-export = Dead. Inspired by arbor. | Intelligence | Agents immediately understand architectural role of any symbol without reading surrounding code — fewer orientation tokens | | | | | +| 5 | TF-IDF lightweight search | SQLite FTS5 + TF-IDF as a middle tier (~50MB) between "no search" and full transformer embeddings (~500MB). Provides decent keyword search with near-zero overhead. Inspired by codexray. | Search | Users get useful search without the 500MB embedding model download; faster startup for small projects | | | | | +| 6 | Formal code health metrics | Cyclomatic complexity, Maintainability Index, and Halstead metrics per function — we already parse the AST, the data is there. Inspired by code-health-meter (published in ACM TOSEM 2025). | Analysis | Agents can prioritize refactoring targets; `hotspots` becomes richer with quantitative health scores per function | | | | | +| 7 | OWASP/CWE pattern detection | Security pattern scanning on the existing AST — hardcoded secrets, SQL injection patterns, eval usage, XSS sinks. Lightweight static rules, not full taint analysis. Inspired by narsil-mcp, CKB. | Security | Catches low-hanging security issues during `diff-impact`; agents can flag risky patterns before they're committed | | | | | +| 8 | Optional LLM provider integration | Bring-your-own provider (OpenAI, Anthropic, Ollama, etc.) for richer embeddings and AI-powered search. Enhancement layer only — core graph never depends on it. Inspired by code-graph-rag, autodev-codebase. | Search | Semantic search quality jumps significantly with provider embeddings; users who already pay for an LLM get better results at no extra cost | | | | | +| 9 | Git change coupling | Analyze git history for files/functions that always change together. Surfaces hidden dependencies that the static graph can't see. Enhances `diff-impact` with historical co-change data. Inspired by axon. | Analysis | `diff-impact` catches more breakage by including historically coupled files; agents get a more complete blast radius picture | | | | | +| 10 | Interactive HTML visualization | `codegraph viz` opens an interactive force-directed graph in the browser (vis.js or Cytoscape.js). Zoom, pan, filter by module, click to inspect. Inspired by autodev-codebase, CodeVisualizer. | Visualization | Developers and teams can visually explore architecture; useful for onboarding, code reviews, and spotting structural problems | | | | | +| 11 | Community detection | Leiden/Louvain algorithm to discover natural module boundaries vs actual file organization. Reveals which symbols are tightly coupled and whether the directory structure matches. Inspired by axon, GitNexus, CodeGraphMCPServer. | Intelligence | Surfaces architectural drift — when directory structure no longer matches actual dependency clusters; guides refactoring | | | | | +| 12 | Execution flow tracing | Framework-aware entry point detection (Express routes, CLI commands, event handlers) + BFS flow tracing from entry to leaf. Inspired by axon, GitNexus, code-context-mcp. | Navigation | Agents can answer "what happens when a user hits POST /login?" by tracing the full execution path in one query | | | | | +| 13 | Architecture boundary rules | User-defined rules for allowed/forbidden dependencies between modules (e.g., "controllers must not import from other controllers"). Violations flagged in `diff-impact` and CI. Inspired by codegraph-rust, stratify. | Architecture | Prevents architectural decay in CI; agents are warned before introducing forbidden cross-module dependencies | | | | | +| 14 | Dataflow analysis | Define/use chains and flows_to/returns/mutates edge types. Tracks how data moves through functions, not just call relationships. Major analysis depth increase. Inspired by codegraph-rust. | Analysis | Enables taint-like analysis, more precise impact analysis, and answers "where does this value end up?" | | | | | +| 15 | Hybrid BM25 + semantic search | Combine BM25 keyword matching with embedding-based semantic search using Reciprocal Rank Fusion. Better recall than either approach alone. Inspired by GitNexus, claude-context-local. | Search | Search results improve dramatically — keyword matches catch exact names, embeddings catch conceptual matches, RRF merges both | | | | | +| 16 | Branch structural diff | Compare code structure between two branches using git worktrees. Show added/removed/changed symbols and their impact. Inspired by axon. | Analysis | Teams can review structural impact of feature branches before merge; agents get branch-aware context | | | | | +| 17 | Multi-file coordinated rename | Rename a symbol across all call sites, validated against the graph structure. Inspired by GitNexus. | Refactoring | Safe renames without relying on LSP or IDE — works in CI, agent loops, and headless environments | | | | | +| 18 | CODEOWNERS integration | Map graph nodes to CODEOWNERS entries. Show who owns each function, surface ownership boundaries in `diff-impact`. Inspired by CKB. | Developer Experience | `diff-impact` tells agents which teams to notify; ownership-aware impact analysis reduces missed reviews | | | | | +| 19 | Auto-generated context files | Generate structural summaries (AGENTS.md, CLAUDE.md sections) from the graph — module descriptions, key entry points, architecture overview. Inspired by GitNexus. | Intelligence | New contributors and AI agents get an always-current project overview without manual documentation effort | | | | | +| 20 | Streaming / chunked results | Support streaming output for large query results so MCP clients and programmatic consumers can process incrementally. | Embeddability | Large codebases don't blow up agent context windows; consumers process results as they arrive instead of waiting for the full payload | | | | | + +--- + +## Scoring Guide + +When filling in the assessment columns during a prioritization session: + +**Zero-dep checklist:** +- Does it use only tree-sitter AST data we already extract? → likely zero-dep +- Does it need a new npm package at runtime? → not zero-dep +- Does it need git CLI access? → acceptable (git is already assumed) +- Does it need a new WASM module or native addon? → not zero-dep + +**Foundation alignment red flags:** +- Adds a cloud API call to the core pipeline → violates P1 and P4 +- Requires Docker, external DB, or non-npm toolchain → violates zero-infrastructure goal +- Generates code, edits files, or makes decisions → violates P8 (we're not an agent) +- Breaks programmatic API contract → check against P5 (embeddable-first) + +**Problem-fit rubric:** +- **5** — Directly reduces token waste, prevents hallucinated dependencies, or catches blast-radius breakage +- **4** — Improves agent accuracy or reduces round-trips for common tasks +- **3** — Useful for developers and agents but doesn't address the core "lost AI" problem +- **2** — Nice-to-have; improves the tool but tangential to the stated problem +- **1** — Cool feature, but doesn't help AI agents navigate codebases better diff --git a/ROADMAP.md b/roadmap/ROADMAP.md similarity index 100% rename from ROADMAP.md rename to roadmap/ROADMAP.md diff --git a/docs/llm-integration.md b/roadmap/llm-integration.md similarity index 100% rename from docs/llm-integration.md rename to roadmap/llm-integration.md