Context
Competitor analysis (e.g. codebase-memory-mcp) shows code-structure graphs are built by static analysis / tree-sitter: nodes are Function/File/Module/Type, edges are CALLS/IMPORTS/DEFINES. It's deterministic and cheap — no embedding model needed — which is why those graphs are large and "easy."
Engram graphs something different and harder: the decision/conversation history (which needs embeddings, because meaning isn't explicit in syntax). The two are complementary, not competing.
The opportunity (genuinely novel)
Add an optional code-structure graph via tree-sitter, then do the thing neither camp does: link a decision memory to the code node it's about. We already capture file-writes with their paths — connect "decision about auth" → the auth.rs File node. Result: "here's your code structure AND the reasoning behind each part."
Tasks
- Add
tree-sitter + grammars (Rust, TS/JS, Python to start) behind a feature/mode so the core stays lean.
- Parse a repo into Function/File/Import/Call nodes (deterministic, no model).
- Reuse the existing file paths in
file_write chunks to draw edges from decisions/fixes → code nodes.
- Surface it as a toggle in the graph view (structure layer on/off) over the existing decision graph.
Acceptance
- For an indexed repo, the graph can show code structure and decision memories together, with edges linking decisions to the files they touched.
Notes
- Keep it optional/lazy — must not slow the core passive-capture path or require a model.
Context
Competitor analysis (e.g. codebase-memory-mcp) shows code-structure graphs are built by static analysis / tree-sitter: nodes are Function/File/Module/Type, edges are CALLS/IMPORTS/DEFINES. It's deterministic and cheap — no embedding model needed — which is why those graphs are large and "easy."
Engram graphs something different and harder: the decision/conversation history (which needs embeddings, because meaning isn't explicit in syntax). The two are complementary, not competing.
The opportunity (genuinely novel)
Add an optional code-structure graph via tree-sitter, then do the thing neither camp does: link a decision memory to the code node it's about. We already capture file-writes with their paths — connect "decision about auth" → the
auth.rsFile node. Result: "here's your code structure AND the reasoning behind each part."Tasks
tree-sitter+ grammars (Rust, TS/JS, Python to start) behind a feature/mode so the core stays lean.file_writechunks to draw edges from decisions/fixes → code nodes.Acceptance
Notes