Feature request: Execution flow / process abstraction for high-level code comprehension

[kaecer68]

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:

1. No tool returns "which business processes a symbol participates in and at which step".
2. No resource exposes a step-by-step execution trace as a first-class entity (like gitnexus://repo/{name}/process/{name}).
3. detect_changes maps changes to affected symbols, but not to affected processes.
4. 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

1. Is an execution-flow / process abstraction on the roadmap?
2. 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?
3. 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.

[DeusData]

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