Files
Dragan Spiridonov 26e724b24e fix(code-intelligence): warn on unsupported langs, prune incremental stale edges, fix MCP code_index counts (#511)
Addresses the gaps a devil's-advocate audit surfaced in the #511 fixes:

1. Fail-loud warning (issue request #2): `index` now records how many files
   were indexed under a language with no dependency extractor and returns them
   as `IndexResult.warnings` (logged + printed by the CLI), so a downstream
   0-edge `deps` result is explained rather than silently misleading.

2. Incremental stale state: `indexFile(..., incremental)` now calls
   removeFileFromGraph() to delete a file's prior node/entity/outgoing-edge
   keys before re-indexing, so `index --incremental` prunes removed imports and
   renamed entities instead of leaving phantom dependencies. (Note: within a
   single long-lived process the FileReader content cache can still serve stale
   text; the CLI re-indexes in a fresh process so this is not user-visible.)

3. MCP parity: the `index-code` task handler emitted `nodesCreated`/`edgesCreated`
   but the MCP result mapper reads `symbolsExtracted`/`relationsFound`, so
   `code_index` always reported 0/0. Map the KG counts to those fields and pass
   `warnings` through. Verified via a real MCP protocol call: filesIndexed 2,
   symbolsExtracted 5, relationsFound 4 (was 0/0).

Adds regression tests: unsupported-language warning, incremental stale-edge
removal (fresh-instance, mirroring the CLI), and the MCP field mapping.

Known limitation (documented, not changed here): CLI persists the graph under
the 'qe-kernel' namespace and MCP under 'mcp-tools', so a graph indexed by one
tool is not read by the other. MCP exposes only `code_index` (no deps/search),
so this has no MCP-internal reader; reconciling the namespaces is entangled with
contradictory init/test-generation expectations and needs its own change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-03 08:47:57 +00:00
..