I'm building scheduled audit routines that query the knowledge graph to assemble file clusters for targeted code audits. Currently, FILE_CHANGES_WITH edges tell me which files co-change, but not how frequently or how recently. File nodes have no temporal metadata either.
This means my audit routines treat a file modified yesterday the same as one untouched for 3 months. For regression detection, recently-changed files are far more likely to have introduced issues and should be prioritized in the audit cluster.
What I'd Like
On FILE_CHANGES_WITH edges:
commit_count (int) — number of commits where both files changed together
last_co_change (RFC 3339 timestamp) — when the most recent co-change occurred
On File nodes:
last_modified (RFC 3339 timestamp) — last git commit that touched this file
change_count (int) — total number of commits that modified this file
Why This Belongs in the Graph
The git watcher infrastructure already reads git history for change detection. Capturing these properties during indexing would make them queryable via search_graph and Cypher, enabling use cases like:
"Give me files that changed in the last 7 days" (audit recency)
"Give me the most frequently changed files" (hot path detection)
"Give me co-change clusters sorted by recent activity" (regression risk ranking)
Currently I'm shelling out to git log at runtime as a workaround, which duplicates work the indexer already does and isn't queryable through the graph API.
Environment
Version: v0.6.0 (compiled binary, Linux x86_64)
Using as a remote MCP server for scheduled Claude Code routines
I'm building scheduled audit routines that query the knowledge graph to assemble file clusters for targeted code audits. Currently, FILE_CHANGES_WITH edges tell me which files co-change, but not how frequently or how recently. File nodes have no temporal metadata either.
This means my audit routines treat a file modified yesterday the same as one untouched for 3 months. For regression detection, recently-changed files are far more likely to have introduced issues and should be prioritized in the audit cluster.
What I'd Like
On FILE_CHANGES_WITH edges:
commit_count (int) — number of commits where both files changed together
last_co_change (RFC 3339 timestamp) — when the most recent co-change occurred
On File nodes:
last_modified (RFC 3339 timestamp) — last git commit that touched this file
change_count (int) — total number of commits that modified this file
Why This Belongs in the Graph
The git watcher infrastructure already reads git history for change detection. Capturing these properties during indexing would make them queryable via search_graph and Cypher, enabling use cases like:
"Give me files that changed in the last 7 days" (audit recency)
"Give me the most frequently changed files" (hot path detection)
"Give me co-change clusters sorted by recent activity" (regression risk ranking)
Currently I'm shelling out to git log at runtime as a workaround, which duplicates work the indexer already does and isn't queryable through the graph API.
Environment
Version: v0.6.0 (compiled binary, Linux x86_64)
Using as a remote MCP server for scheduled Claude Code routines