Mode upgrade silently keeps weaker graph: incremental routing ignores stored index capability level

[astandrik]

Version

main @ 97ce23f (0.9.x line)

Platform

macOS (Apple Silicon) — the routing logic is platform-independent C, so all platforms are affected; verified on macOS.

Install channel

Built from source

Binary variant

standard

What happened, and what did you expect?

Indexing a repository with a weaker mode and then re-running with a stronger mode on an unchanged repo silently keeps the weaker graph. The incremental router compares stored file hashes and the discovered-file threshold, but never the capability level of the stored index, so a fast-built graph is treated as valid for moderate/full requests.

Expected: when the requested mode requires capabilities missing from the stored index (e.g. full builds SIMILAR_TO / SEMANTICALLY_RELATED edges that fast never produces), the run forces a full rebuild. Conversely, re-running with a weaker requested mode (as the failure hint on large repos suggests, cf. #563) should not tear down stronger capabilities already present in the graph.

Reproduction

1. Clone any small public repo, e.g. colinhacks/zod, to /tmp/zod.
2. codebase-memory-mcp cli index_repository '{"repo_path":"/tmp/zod","mode":"fast"}' → completes with pipeline.route path=full; graph contains no full-mode-only edges.
3. Re-run unchanged: codebase-memory-mcp cli index_repository '{"repo_path":"/tmp/zod","mode":"moderate"}'.

Actual: the log shows the incremental no-op path; the graph never gains the capabilities moderate/full are supposed to add, and nothing signals that the stored index is weaker than requested.

Expected: the router detects the capability gap and forces a full rebuild.

Symmetric downgrade case: after a full index, re-run with "mode":"fast" on a repo with changed files. Before the fix this rebuilt from scratch at the weaker mode, permanently discarding the stronger capabilities; expected is a run that keeps the full graph and only narrows the requested view.

Logs

level=info msg=pipeline.route path=incremental
# ^ after fast → moderate on an unchanged repo; should have been a forced full rebuild

Project scale (if relevant)

Reproduces on repos of any size (observed in the wild on a ~124k-file repo, see #563).

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a public OSS repository), not proprietary code.

[DeusData]

Thanks for checking both upgrade and downgrade directions.

The current main route is still file-count based: try_incremental_or_delete_db compares discovered files with stored hash count and takes incremental when the threshold fits (src/pipeline/pipeline.c:1170-1182). The existing mode_change_reindex log at 1184-1187 is only the opposite file-count branch; it does not read stored index_mode capability metadata. So the log name does not invalidate this report.

PR #1263 is linked and queued for review. The issue remains a priority/high 0.9.1 correctness bug; triage is not pre-approving the implementation. Thank you for catching the misleading existing log label too.