Repository navigation
Feature request: Execution flow / process abstraction for high-level code comprehension #597
Description
Context
I am evaluating codebase-memory-mcp as a replacement for GitNexus for a large Go codebase (~52k symbols, ~165k relationships). The project currently relies heavily on GitNexus' "execution flow" / "process" abstraction: pre-computed, entry-point-to-leaf paths that group related symbols into business-logic flows (e.g., "LoginFlow", "TokenRefresh").
What exists today
Looking at the 14 MCP tools and the README, codebase-memory-mcp already provides excellent low-level graph capabilities:
- trace_path / trace_call_path: BFS call-chain traversal (inbound/outbound/both), depth 1-5
- get_architecture: overview with Louvain clusters, hotspots, entry points, routes
- detect_changes: git-diff -> affected symbols + risk classification
- query_graph: Cypher-like queries over nodes and edges
What is missing
There is no equivalent of GitNexus' process / execution flow abstraction:
- No tool returns "which business processes a symbol participates in and at which step".
- No resource exposes a step-by-step execution trace as a first-class entity (like gitnexus://repo/{name}/process/{name}).
- detect_changes maps changes to affected symbols, but not to affected processes.
- There is no process-grouped search; a natural-language query returns symbols/edges, not flows.
Why it matters
For large codebases, trace_path is useful but insufficient:
- Developers think in flows ("how does payment processing work?") more often than in raw call chains.
- Pre-computed flows reduce token usage and reasoning errors for AI agents; asking the LLM to reconstruct a flow from many trace_path calls is expensive and brittle.
- Impact analysis and rename planning are safer when we know which high-level flows are touched, not just which symbols.
Request
- Is an execution-flow / process abstraction on the roadmap?
- If so, is the planned approach:
- detecting entry points (HTTP routes, CLI handlers, event listeners) and pre-computing end-to-end paths, or
- deriving flows from Louvain clusters + trace_path, or
- something else?
- Would the project accept design contributions or benchmarks for this feature?
I would be happy to provide real-world test data or help evaluate prototypes.
Thanks for the excellent work on the engine -- the performance and Hybrid LSP results are impressive.
Activity
DeusData commentedon Jun 24, 2026
Hey, thanks for the request. With regards to Gitnexus: They build a great tool, and I am happy for their success. Emulating their exact features would be a bit tricky, as I obviously don't want to copy them. But I can try to find ways to basically do it "our way" which might also enable a better thing downstream. Will think about it. Might take a bit of time, but not too much. And yes we are interested in benchmarks and test data. Will follow up once work starts on this one
DeusData commentedon Jun 29, 2026
Thanks. I’ve triaged this under #398 as an architecture/feature request. The process/execution-flow abstraction is broader than
trace_path; the right next step is a small design note defining how flows are derived, stored, invalidated, and exposed without turning every traversal into a precomputed artifact.kaecer68 commentedon Jun 30, 2026
DeusData commentedon Oct 19, 2026
Thank you again for the execution-flow use case and encouragement. The questions about deriving, invalidating, and exposing flows remain a design decision; I have no new implementation or timeline to announce. No new benchmark run is being requested from you in this follow-up.
DeusData commentedon Oct 25, 2026
Thank you for your patience. Sorry for the delay. The derivation, invalidation and API scope for execution flows still need a maintainer decision. I’ll follow up soon.