h-dv/code-index

Watch

Fork 0

Two parse-error channels, one census: doctor and project_overview report 0 errors for a file index_coverage correctly reports as broken, and file_outline says nothing is wrong #148

New issue

Closed

opened 2026-09-05 12:54:15 +02:00 by buildagent · 1 comment

buildagent commented

2026-09-05 12:54:15 +02:00

Member

Found by a production-readiness review, on tests/packages/xaml/fixtures/Broken.xaml — exactly the XAML customer's file class.

Three surfaces, three different answers about the same file

surface	says
`index_coverage`	`extraction_diagnostics: ["extract.parse_error"]` ✅ correct
`project_overview`	`parse_errors: 0` ❌
`code-index doctor`	`[ OK ] parse error rate 0/709` ❌
`file_outline`	"File is indexed but declares no symbols (e.g. comment-only, re-export-only, or a text/data file)" ❌

Cause

files.parse_error (the builtin path) and file_contributions.diagnostics (packaged extractors) are different columns, and only the first is counted. So a packaged extractor's parse failures are invisible to every census.

This is #112's shape — a packaged language invisible to a host table — in the health surface rather than the resolver.

The `file_outline` note is worse than a missing count

server.rs:12495 returns a &'static str, unconditional, whose own comment asserts "nothing is wrong". For Broken.xaml all three named causes are false: the extractor stopped at line 1 of 4. A user reading that note concludes the file is fine.

An unconditional string that explains an observation it never checked is not a disclosure — it is a guess rendered as a measurement.

Note for the in-flight `partial_sources` work

It adds a repo-wide denominator here, but it matches by exact path string against the payload, so it will structurally miss the empty-outline case — which has no path in its body. Worth handling in the same change rather than discovering it later.

#112 (host tables keyed on builtin language ids)
#105 (derived_names cost only visible by grepping files.parse_error) — same column, same blind spot

🤖 Generated with Claude Code

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

Found by a production-readiness review, on `tests/packages/xaml/fixtures/Broken.xaml` — **exactly the XAML customer's file class**. ## Three surfaces, three different answers about the same file | surface | says | |---|---| | `index_coverage` | `extraction_diagnostics: ["extract.parse_error"]` ✅ correct | | `project_overview` | `parse_errors: 0` ❌ | | `code-index doctor` | `[ OK ] parse error rate 0/709` ❌ | | `file_outline` | *"File is indexed but declares no symbols (e.g. comment-only, re-export-only, or a text/data file)"* ❌ | ## Cause `files.parse_error` (the builtin path) and `file_contributions.diagnostics` (packaged extractors) are **different columns, and only the first is counted**. So a packaged extractor's parse failures are invisible to every census. This is #112's shape — a packaged language invisible to a host table — in the health surface rather than the resolver. ## The `file_outline` note is worse than a missing count `server.rs:12495` returns a `&'static str`, **unconditional**, whose own comment asserts "nothing is wrong". For `Broken.xaml` all three named causes are false: the extractor stopped at line 1 of 4. A user reading that note concludes the file is fine. An unconditional string that explains an observation it never checked is not a disclosure — it is a guess rendered as a measurement. ## Note for the in-flight `partial_sources` work It adds a repo-wide denominator here, but it matches by **exact path string against the payload**, so it will structurally miss the empty-outline case — which has no path in its body. Worth handling in the same change rather than discovering it later. ## Related - #112 (host tables keyed on builtin language ids) - #105 (`derived_names` cost only visible by grepping `files.parse_error`) — same column, same blind spot 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

buildagent referenced this issue

2026-09-05 12:54:34 +02:00

code-index doctor is blind to staleness, watcher health and resolve state, and check_disk_free only fires at literally zero bytes #150

dhoyer referenced this issue from a commit

2026-09-05 18:43:40 +02:00

fix: a disclosure field is honest per DERIVATION, not per site

buildagent commented

2026-09-06 09:41:35 +02:00

Author

Member

Triage 2026-09-06: CLOSING. All four surfaces the issue tabulated now agree, off one derivation with two readers.

Verified against master; landed in 6cc5b4f.

The four surfaces

surface	site
`project_overview`	`crates/mcp-server/src/server.rs:9251`
`doctor`	`crates/cli/src/doctor.rs:91`, `:661`, `:680`
`file_outline`	`crates/mcp-server/src/server.rs:13965-14003`
one derivation, two readers	`crates/daemon/src/local_index.rs:1213`, `:2649`

The file_outline change is the one that answers this issue's sharpest complaint. The unconditional &'static str — "nothing is wrong" — is gone, replaced by EmptyOutlineResp whose note is, in its own words, "composed from the columns the probe returned, never a constant". A constant cannot be wrong about a broken file because it was never looking; a composed note can be, which is what makes it worth reading.

The generalisation that made it stick

6cc5b4f's framing is worth keeping: every registry in this tree keys on a site — a surface, a cap, a stage, a reason code. None keys on a derivation. That is why a field can be correct at one site and wrong at another, and the mechanical cause is visible in the type: Surface::producer is &'static str, singular, so a surface running four renderers can name one while nothing proves the unnamed three exist. disclosure_derivation_registry keys on (field, surface) instead.

The forward-looking note in the issue is handled too

EmptyOutlineResp now emits the routed relative path in the body, specifically so partial_sources' exact-path matcher can annotate the empty-outline case that structurally had no path to match on — server.rs:13982-14000.

Runs (all exit 0)

cargo test -p code-index-daemon --test diagnostic_census      → 6 passed
    incl. the_diagnostic_census_has_one_derivation_and_two_readers
cargo test -p code-index-mcp    --test diagnostic_census_e2e  → 3 passed
    incl. an_empty_outline_says_what_was_observed_and_names_itself
cargo test -p code-index-cli    --test diagnostic_census_cli  → 2 passed
    incl. doctor_reports_the_packaged_extractor_channel_beside_the_parse_error_ratio

Three surfaces, three suites, one derivation — which is the arrangement that makes a future fifth surface hard to get wrong.

Residual

None.

🤖 Triage lane, 2026-09-06, master 45cf6e4

## Triage 2026-09-06: CLOSING. All four surfaces the issue tabulated now agree, off **one derivation with two readers**. Verified against master; landed in `6cc5b4f`. ### The four surfaces | surface | site | |---|---| | `project_overview` | `crates/mcp-server/src/server.rs:9251` | | `doctor` | `crates/cli/src/doctor.rs:91`, `:661`, `:680` | | `file_outline` | `crates/mcp-server/src/server.rs:13965-14003` | | one derivation, two readers | `crates/daemon/src/local_index.rs:1213`, `:2649` | The `file_outline` change is the one that answers this issue's sharpest complaint. The unconditional `&'static str` — *"nothing is wrong"* — is **gone**, replaced by `EmptyOutlineResp` whose note is, in its own words, *"composed from the columns the probe returned, never a constant"*. A constant cannot be wrong about a broken file because it was never looking; a composed note can be, which is what makes it worth reading. ### The generalisation that made it stick `6cc5b4f`'s framing is worth keeping: *every registry in this tree keys on a **site** — a surface, a cap, a stage, a reason code. None keys on a **derivation**.* That is why a field can be correct at one site and wrong at another, and the mechanical cause is visible in the type: `Surface::producer` is `&'static str`, **singular**, so a surface running four renderers can name one while nothing proves the unnamed three exist. `disclosure_derivation_registry` keys on `(field, surface)` instead. ### The forward-looking note in the issue is handled too `EmptyOutlineResp` now emits the routed relative `path` **in the body**, specifically so `partial_sources`' exact-path matcher can annotate the empty-outline case that structurally had no path to match on — `server.rs:13982-14000`. ### Runs (all exit 0) ``` cargo test -p code-index-daemon --test diagnostic_census → 6 passed incl. the_diagnostic_census_has_one_derivation_and_two_readers cargo test -p code-index-mcp --test diagnostic_census_e2e → 3 passed incl. an_empty_outline_says_what_was_observed_and_names_itself cargo test -p code-index-cli --test diagnostic_census_cli → 2 passed incl. doctor_reports_the_packaged_extractor_channel_beside_the_parse_error_ratio ``` Three surfaces, three suites, one derivation — which is the arrangement that makes a future fifth surface hard to get wrong. ### Residual None. 🤖 Triage lane, 2026-09-06, master `45cf6e4`

buildagent closed this issue

2026-09-06 09:41:37 +02:00

buildagent referenced this issue

2026-09-07 18:38:06 +02:00

evidence_gaps.semantics tells the reader to consult partial_sources, and no tool ever emits that field #216

buildagent referenced this issue

2026-09-07 21:22:12 +02:00

evidence_gaps.semantics tells the reader to consult partial_sources, and no tool ever emits that field #216

buildagent referenced this issue

2026-09-09 13:57:02 +02:00

evidence_gaps warns on every reply that the answer may be short, and gives no way to find out which file — index_coverage(path) needs the path you are trying to learn #241