h-dv/code-index

Watch

Fork 0

honesty: disclose symbol-blind and plugin-unavailable coverage by extension #81

New issue

Closed

opened 2026-08-26 12:34:26 +02:00 by buildagent · 1 comment

buildagent commented

2026-08-26 12:34:26 +02:00

Member

Relates to #75, but independently filable and fixable today. Customer-driven, and it is the I063 shape again: a hardcoded enumeration standing in for a measurement.

Part 1 — the enumerated list has already drifted, and the shipped copy is the wrong one

There is no named constant. The "a ref_count of 0 can be vacuous" claim is duplicated as prose in three places, and they disagree:

copy	location	causes named	`get` measurement	consts
tool description	`crates/mcp-server/src/server.rs:5287`	2 ("alias-qualified calls, Rust consts")	—	—
MCP resource `docs/ref-kinds`	`crates/mcp-server/src/server.rs:11514-11543`	3	11 / 846	325
rustdoc on the field	`crates/daemon/src/local_index.rs:73-122`	3	11 / 834	326

Verified by grep. Same claims, different numbers — and the copy an agent actually pays tokens to read (the shipped resource) is the one disagreeing with the internal doc.

This is exactly what producer_coverage_matrix.rs:295-302 refuses to commit: three copies of one closed set, free to rot. And it fails the customer case concretely — a C#/WPF user checks a two-item list, matches neither, and reasonably concludes their 0 is tight.

Part 2 — the thing that would have warned them is not measured

Verified: .xaml, .axaml, .xsd are in EXTRA_TEXT_EXTENSIONS (crates/indexer/src/text_only.rs:30-52) → kind='text', searchable, zero symbols. *.Designer.cs — where typed-DataSet members are generated — is refused by the C# plugin itself (crates/plugins/src/csharp.rs:48).

So for that codebase a large share of the real reference graph is structurally invisible, and nothing in any payload says so.

The fix, and the design constraint that makes it work

Do not report a bare percentage. This repo is 254 code / 113 text files — 31% text-kind — and that number is noise here because it's md and toml. The same number is a klaxon there. What makes it readable is not aggregating away the extensions:

here:  md 86, toml 18, json 4, yml 3, sh 1, csproj 1   → docs and config, move on
there: xaml N, xsd M, resx K, config J                 → that is the UI and data layer

No framework knowledge anywhere; the reader judges, we decline to hide the evidence.

Cost is nil and it comes free with correctness. languages is already SELECT lang, COUNT(*) FROM files GROUP BY lang (crates/daemon/src/local_index.rs:816) and GROUP BY kind measures at 2 ms. Add kind to that grouping and both lists fall out of one pass — which also guarantees they cannot contradict each other, the property WholeWordWindow.semantics exists to enforce (server.rs:3876-3918).

Scope

project_overview.symbol_blind_extensions — extension + count for every kind='text' file. A new field, not a change to languages: that is Vec<(String, u64)> and widening the tuple is an arity break on shipped wire.
Delete the enumeration. Replace all three copies with one payload-resident, derived count_basis / count_basis_semantics. This doesn't merely stop the list rotting — it deletes two copies and makes the third computable. One definition, per the ineligible_code pattern (server.rs:3470-3484).
Point at the tool that can answer. safe_delete's FTS channel already covers text-kind files — all 113 here are in files_fts, no kind filter in the query — so "is this DataSet member actually used?" already has an honest answer today and nothing points at it.
Skew: additive field, both directions, non-empty payloads, per the I062 discipline.

Test shape

Registry gate: a fixture with code files, reference-bearing text files (.xaml, .erb, .vue), inert text (.md), and a refused .Designer.cs. Assert each text extension is named with the right count; that an md-only project reads as unremarkable while a xaml-heavy one is visibly dominated; and — anti-vacuity — that a project with no text files omits the block rather than reporting an empty one.

Mutation it must catch: aggregating the extensions into a single total. That version is useless, and a test that still passes on it is grading the wrong axis.

What to tell the customer

Their 36% is better than this repo's own Rust (24.5%) and is not the thing to worry about — unresolved LINQ/BCL extension methods are correctly unresolved because the targets aren't in the project; the figure largely measures stdlib surface. The XAML/DataSet half is the real issue, and it is more consequential than "carries no symbols" sounds, because XAML holds genuine edges (Click=, x:Name, {Binding}) that no count in any payload currently reflects.

Runtime-plugin architecture extension

With #75, kind='text' is no longer the whole symbol-blind population. Coverage must be derived against the project’s active generation and requested package state.

project_overview must distinguish, by extension/count:

text-only and intentionally symbol-blind under the active generation;
claimed by an active plugin and structurally indexed;
requested plugin not installed;
installed but ABI/capability/conformance rejected;
quarantined or failed activation while the prior generation remains active;
plugin-excluded/generated source such as Designer.cs;
permanently unclaimed.

Do not subtract an extension from symbol_blind merely because a package manifest claims it. Only active contributions with a successful generation count as structural coverage.

The block carries active generation identity and unavailable semantics for older daemons. Counts must come from the same project-scoped query/snapshot as the language/plugin coverage block in #80 so the disclosures cannot contradict each other.

#81 remains independently shippable now: its initial implementation can report current text/excluded extensions. The schema should be additive so #80 can refine each extension into the states above without changing the meaning of the original count.

Relates to #75, but **independently filable and fixable today**. Customer-driven, and it is the I063 shape again: a hardcoded enumeration standing in for a measurement. ## Part 1 — the enumerated list has already drifted, and the shipped copy is the wrong one There is **no named constant**. The "a `ref_count` of 0 can be vacuous" claim is duplicated as prose in **three** places, and they disagree: | copy | location | causes named | `get` measurement | consts | |---|---|---|---|---| | tool description | `crates/mcp-server/src/server.rs:5287` | **2** ("alias-qualified calls, Rust consts") | — | — | | MCP resource `docs/ref-kinds` | `crates/mcp-server/src/server.rs:11514-11543` | 3 | 11 / **846** | **325** | | rustdoc on the field | `crates/daemon/src/local_index.rs:73-122` | 3 | 11 / **834** | **326** | Verified by grep. Same claims, different numbers — and the copy an agent actually pays tokens to read (the shipped resource) is the one disagreeing with the internal doc. This is exactly what `producer_coverage_matrix.rs:295-302` refuses to commit: three copies of one closed set, free to rot. And it fails the customer case concretely — a C#/WPF user checks a two-item list, matches neither, and reasonably concludes their `0` is tight. ## Part 2 — the thing that *would* have warned them is not measured Verified: `.xaml`, `.axaml`, `.xsd` are in `EXTRA_TEXT_EXTENSIONS` (`crates/indexer/src/text_only.rs:30-52`) → `kind='text'`, searchable, **zero symbols**. `*.Designer.cs` — where typed-DataSet members are generated — is refused by the C# plugin itself (`crates/plugins/src/csharp.rs:48`). So for that codebase a large share of the real reference graph is structurally invisible, and nothing in any payload says so. ## The fix, and the design constraint that makes it work **Do not report a bare percentage.** This repo is 254 code / 113 text files — 31% text-kind — and that number is *noise* here because it's `md` and `toml`. The same number is a klaxon there. What makes it readable is **not aggregating away the extensions**: ``` here: md 86, toml 18, json 4, yml 3, sh 1, csproj 1 → docs and config, move on there: xaml N, xsd M, resx K, config J → that is the UI and data layer ``` No framework knowledge anywhere; the reader judges, we decline to hide the evidence. **Cost is nil and it comes free with correctness.** `languages` is already `SELECT lang, COUNT(*) FROM files GROUP BY lang` (`crates/daemon/src/local_index.rs:816`) and `GROUP BY kind` measures at **2 ms**. Add `kind` to that grouping and both lists fall out of **one pass** — which also guarantees they cannot contradict each other, the property `WholeWordWindow.semantics` exists to enforce (`server.rs:3876-3918`). ## Scope 1. **`project_overview.symbol_blind_extensions`** — extension + count for every `kind='text'` file. A **new field**, not a change to `languages`: that is `Vec<(String, u64)>` and widening the tuple is an arity break on shipped wire. 2. **Delete the enumeration.** Replace all three copies with one payload-resident, derived `count_basis` / `count_basis_semantics`. This doesn't merely stop the list rotting — it **deletes two copies and makes the third computable**. One definition, per the `ineligible_code` pattern (`server.rs:3470-3484`). 3. **Point at the tool that can answer.** `safe_delete`'s FTS channel **already covers text-kind files** — all 113 here are in `files_fts`, no kind filter in the query — so "is this DataSet member actually used?" already has an honest answer today and nothing points at it. 4. **Skew:** additive field, both directions, non-empty payloads, per the I062 discipline. ## Test shape Registry gate: a fixture with code files, reference-bearing text files (`.xaml`, `.erb`, `.vue`), inert text (`.md`), and a refused `.Designer.cs`. Assert each text extension is named with the right count; that an `md`-only project reads as unremarkable while a `xaml`-heavy one is visibly dominated; and — **anti-vacuity** — that a project with **no** text files omits the block rather than reporting an empty one. **Mutation it must catch:** aggregating the extensions into a single total. That version is useless, and a test that still passes on it is grading the wrong axis. ## What to tell the customer Their 36% is **better than this repo's own Rust (24.5%)** and is not the thing to worry about — unresolved LINQ/BCL extension methods are correctly unresolved because the targets aren't in the project; the figure largely measures stdlib surface. The XAML/DataSet half is the real issue, and it is *more* consequential than "carries no symbols" sounds, because XAML holds genuine edges (`Click=`, `x:Name`, `{Binding}`) that no count in any payload currently reflects. ## Runtime-plugin architecture extension With #75, kind='text' is no longer the whole symbol-blind population. Coverage must be derived against the project’s active generation and requested package state. project_overview must distinguish, by extension/count: - text-only and intentionally symbol-blind under the active generation; - claimed by an active plugin and structurally indexed; - requested plugin not installed; - installed but ABI/capability/conformance rejected; - quarantined or failed activation while the prior generation remains active; - plugin-excluded/generated source such as Designer.cs; - permanently unclaimed. Do not subtract an extension from symbol_blind merely because a package manifest claims it. Only active contributions with a successful generation count as structural coverage. The block carries active generation identity and unavailable semantics for older daemons. Counts must come from the same project-scoped query/snapshot as the language/plugin coverage block in #80 so the disclosures cannot contradict each other. #81 remains independently shippable now: its initial implementation can report current text/excluded extensions. The schema should be additive so #80 can refine each extension into the states above without changing the meaning of the original count.

buildagent referenced this issue

2026-08-26 12:35:00 +02:00

epic: runtime plugin architecture — dynamic grammar, extraction and resolution packages #75

buildagent added the

labels

2026-08-26 12:35:27 +02:00

buildagent referenced this issue

2026-08-26 13:33:38 +02:00

gate: plugin conformance, hostile-runtime containment and production disclosure #80

buildagent changed title from ~~honesty: the vacuous-zero story — three drifted copies of one list, and no measure of the symbol-blind surface~~ to honesty: disclose symbol-blind and plugin-unavailable coverage by extension

2026-08-26 13:39:08 +02:00

buildagent referenced this issue

2026-08-26 13:39:49 +02:00

investigate: honest internal-resolution spread across builtin and plugin languages #46

buildagent added

and removed

labels

2026-08-26 13:42:32 +02:00

buildagent added a new dependency

2026-08-26 13:43:10 +02:00

#80 gate: plugin conformance, hostile-runtime containment and production disclosure

buildagent added a new dependency

2026-08-26 13:43:54 +02:00

#47 feat: provenance-aware gap miner for builtin and plugin evidence

buildagent added a new dependency

2026-08-26 13:44:00 +02:00

#46 investigate: honest internal-resolution spread across builtin and plugin languages

buildagent added a new dependency

2026-08-26 13:44:36 +02:00

#24 feat: provenance-aware dead/test-only candidates, never deletion authority