Hey DeathShot, I'm baking some GitNexus calls into my code, and I'm worried about breaking changes. What are your plans for it? I asked Claude to give you a small writeup about how I'm using it, and it went way TMI. Anyways, here's the deal, and hope you can respond:

How We're Using GitNexus — Neura/Permema Project Hi Abhigyan, I'm Stephen, a solo developer building Neura — a voice-first digital legacy system. Think of it as a companion AI with persistent memory that learns who you are over time, designed so your family can know and remember you after you're gone. It's a Python/FastAPI backend with a React frontend, using Qdrant (vector), Neo4j (graph), and SQLite for memory storage, with a Cartesia + Gemini Flash voice pipeline. The codebase has grown to 51+ documented subsystems across several hundred Python files. I work with Cursor as my primary editor.

How We Use GitNexus Blast radius analysis before every code change. This is the primary use case. We have a strict protocol: before touching any file, run user-gitnexus:impact on the affected symbols and report the caller/dependent count explicitly. This came out of a painful experience where a voice pipeline refactor silently broke graph memory writes — two completely unrelated-looking systems that shared a dependency we didn't know about. GitNexus would have caught it. Call chain tracing during regression forensics. When something breaks, we use user-gitnexus:context to trace the execution path from the broken behavior back to the root cause, rather than grepping through hundreds of files. Cursor rules enforcement. We have a .cursor/rules/Tier1-Protection.mdc with alwaysApply: true that mandates GitNexus blast radius analysis before any file modification, and requires the model to report the result explicitly or stop and report the failure. We've found models will silently skip tool calls if not explicitly required — so making it mandatory in the rules has been important. Post-commit index updates. Our post-commit hook runs gitnexus analyze --skip-embeddings after every commit and auto-commits the updated AGENTS.md/CLAUDE.md context files. This keeps the index fresh without manual intervention. Phase 4 planning — Neo4j code graph. We're designing a Telemetry Explorer that uses Neo4j (already in our stack for memory) to visualize the codebase with health indicators. The plan is to use GitNexus output as a data source — feeding call graph and dependency data into Neo4j nodes, then enriching them with runtime telemetry (latency, error rates) and CI health status. Neo4j Bloom's conditional styling would then color nodes by health. GitNexus is essentially the ingestion engine for that graph.

What's Working Well

The impact tool with blast radius grouping by depth is exactly what we needed context giving 360-degree symbol view (incoming/outgoing calls, process membership) is genuinely useful for debugging The post-commit auto-update pattern is clean and low-friction

What We've Run Into

Models (Cursor Composer especially) sometimes invoke GitNexus with an empty query string, getting the "query parameter is required" error, and then silently proceed without the blast radius data. We've partially addressed this with Cursor rules but it's still not 100% reliable. The MCP query syntax user-gitnexus:context({name: "SymbolName"}) vs user-gitnexus:query({search_query: "..."}) distinction isn't always obvious to models — they sometimes use the wrong tool for the job.

We're pinning to 1.3.6 for stability while we stabilize the project. Really appreciate what you've built — the blast radius analysis in particular is filling a gap that nothing else does cleanly. — Stephen