index_status reports a whole-file parse-error range (src/cli/cli.c as 1-13047), which is not actionable #1984

Version

Built from source at ae5de7fe (main), release line v0.10.8

Platform

macOS (Apple Silicon)

Install channel

Built from source

Binary variant

standard

What happened, and what did you expect?

index_status reports a parse-error range covering an entire file when only a small part
of it failed to parse. On this repository it reported src/cli/cli.c as one error range
of 1-13047 — the whole file. The file indexed fine; the report was wrong.

A range that names the whole file is not actionable. "Grep 13,000 lines for the problem"
is the same as no signal at all, and it makes the coverage report look far worse than the
indexing actually is.

I expected the reported range to name the region that actually failed, so it points at
something a person can open and read.

Reproduction

1. Index this repository itself:
   codebase-memory-mcp cli index_repository '{"repo_path":"<path to this repo>"}'
2. Call check_index_coverage (or index_status) and read the reported error ranges.
3. Result: src/cli/cli.c is reported as a single error range 1-13047, the full file.
   Expected: a range naming the region that failed to parse.

This is the parent defect of the coverage-report work tracked in #963, which is closed.
The two narrower faults — a duplicate range, and a range ending one line past the end of
the file — are already tracked separately as #1965 and #1966. This issue is the remaining
one: the range itself is far too wide.

Logs

index_status: src/cli/cli.c  error range 1-13047

Diagnostics trajectory (memory / performance / leak issues)

Not applicable — a reporting-accuracy issue, not memory or performance.

Project scale (if relevant)

Reproduces on this repository (roughly 649 hand-written C/H files).

Confirmations

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