internal_resolution_pct ships without its denominator: it is computed over 50 of 709 files and looks identical on a 50k-file repo #149

New issue

Closed

opened 2026-09-05 12:54:23 +02:00 by buildagent · 4 comments

buildagent commented 2026-09-05 12:54:23 +02:00

Member

Copy link

Found by a production-readiness review.

The number

internal_resolution_pct: 42.3 sits at the top level of project_overview, next to repo-wide refs/refs_resolved (21.9%). It has:

• no semantics string,
• no mention in the tool description,
• no stated population.

It is computed over file_health — 50 of 709 files (7.1%), covering 38% of refs, and deliberately the highest-ref files. So it is a biased sample presented beside an unbiased one, with nothing distinguishing them.

On a 50k-file repo the same LIMIT 50 covers ~0.1% of files and the number looks exactly the same. It silently becomes less meaningful as the repo grows, which is the opposite of what a reader will assume.

The sibling

resolution_gaps.dynamic_influence is the only block in that response with no semantics, is absent from the tool description entirely, and its counts (134,278) sum against an unstated population — unresolved, non-binding, non-reclassified refs — rather than the 226,714 the same response implies.

Ask

Every ratio in a payload carries its denominator, or it is not a ratio. This project already has the mechanism (count_basis, counts_scope, the *_unmeasured family); these two fields just never got it. One clause, both fields — not a fix per field.

Related

• #93, #98 (payload honesty family)
• The count_basis work that established the pattern

🤖 Generated with Claude Code

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

Found by a production-readiness review. ## The number `internal_resolution_pct: 42.3` sits at the **top level** of `project_overview`, next to repo-wide `refs`/`refs_resolved` (21.9%). It has: - no `semantics` string, - no mention in the tool description, - no stated population. It is computed over `file_health` — **50 of 709 files (7.1%), covering 38% of refs**, and deliberately the *highest-ref* files. So it is a biased sample presented beside an unbiased one, with nothing distinguishing them. On a 50k-file repo the same `LIMIT 50` covers ~0.1% of files and **the number looks exactly the same**. It silently becomes less meaningful as the repo grows, which is the opposite of what a reader will assume. ## The sibling `resolution_gaps.dynamic_influence` is the **only** block in that response with no `semantics`, is absent from the tool description entirely, and its counts (134,278) sum against an unstated population — unresolved, non-`binding`, non-reclassified refs — rather than the 226,714 the same response implies. ## Ask Every ratio in a payload carries its denominator, or it is not a ratio. This project already has the mechanism (`count_basis`, `counts_scope`, the `*_unmeasured` family); these two fields just never got it. One clause, both fields — not a fix per field. ## Related - #93, #98 (payload honesty family) - The `count_basis` work that established the pattern 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

buildagent referenced this issue 2026-09-05 12:56:17 +02:00

perf: project_overview needs generation-scoped O(1) aggregates, not repeated refs scans #73

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:46:32 +02:00

Author

Member

Copy link

Triage 2026-09-06: LEFT OPEN — one field substantially fixed with a caveat, the named sibling untouched. Reported as fixed; it is half.

internal_resolution_pct / file_health — substantially fixed

The cut is disclosed by fields, in the entry_points_total/entry_points_truncated shape, three-state:

• The probe is FILE_HEALTH_CAP + 1, so truncation is measured, not inferred — crates/mcp-server/src/server.rs:9148.
• file_health_truncated :9153, file_health_total :9154, declared :9384, emitted :9522.
• .ok() rather than unwrap_or_default keeps "the daemon could not answer" apart from "nothing was cut" — :9142-9148.
• bounding_site_registry.rs:340-355 re-classifies FILE_HEALTH_CAP from Intentional to Field("file_health_total + file_health_truncated"), and ENTRY_POINTS_CAP likewise at :358-372. That re-classification is the durable part: a cap that claims to be intentional is exempt from disclosure, and these no longer are.

THE CAVEAT — the literal ask is still not met

file_health_total is emitted only when the cut did not bite: .filter(|h| h.len() <= FILE_HEALTH_CAP), server.rs:9154-9157.

So in the exact case this issue's title names — 50 of 709 — file_health_total is absent, and only file_health_truncated: true ships. The reader learns "this is a sample of unknown size", not "50 of 709".

That is defensible: fabricating a population the call never measured would be worse, and "unknown size" is at least not a lie. But it is a different guarantee from "every ratio in a payload carries its denominator", and this issue should be closed on the honest version of the claim, not the literal one — or the code should emit the real total.

No wire test — worth knowing before trusting the fields

file_health_total occurs in exactly four places tree-wide: three in server.rs, one as a registry string at bounding_site_registry.rs:354. No test asserts either field's value on a real project_overview payload.

overview_payload_budget_e2e.rs already builds a saturated fixture with 120 ref-carrying files — 2.4× the cap (:511, :988) — which is exactly where that assertion belongs, and it checks only the row count. A wrong file_health_total would ship green.

resolution_gaps.dynamic_influence — NOT FIXED

This issue named it as the sibling and asked for "one clause, both fields — not a fix per field." The second field did not move:

• No semantics on the wire. graph::DynamicInfluence (crates/daemon/src/graph.rs:1429) carries builtin_only, dynamic_endpoint, dynamic_influenced, not_reported — and no population string. Its sibling GapScope has pub semantics: String at :1470, which is the shape this one is missing.
• Absent from the tool description. resolution_gaps' #[tool(description = …)] at server.rs:13834 names resolver_degradation and scope and never mentions dynamic_influence.
• For the record: not_reported is not this issue's work — git log -S puts it in 79108fb feat: computed resolution influence (#77 step 7).

cargo test -p code-index-mcp --test disclosure_derivation_registry → 10 passed, EXIT 0
cargo test -p code-index-mcp --test bounding_site_registry         → 17 passed, EXIT 0

What closing needs

1. Decide whether file_health_total should ship the real total when the cut bites, or whether "sample of unknown size" is the accepted answer — and if the latter, amend this issue's title, which currently promises the denominator.
2. Assert both fields on the existing saturated fixture in overview_payload_budget_e2e.rs.
3. Give dynamic_influence its semantics, from the same clause — this issue's own instruction.

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

## Triage 2026-09-06: LEFT OPEN — **one field substantially fixed with a caveat, the named sibling untouched.** Reported as fixed; it is half. ### `internal_resolution_pct` / `file_health` — substantially fixed The cut is disclosed by **fields**, in the `entry_points_total`/`entry_points_truncated` shape, three-state: - The probe is `FILE_HEALTH_CAP + 1`, so truncation is **measured**, not inferred — `crates/mcp-server/src/server.rs:9148`. - `file_health_truncated` `:9153`, `file_health_total` `:9154`, declared `:9384`, emitted `:9522`. - `.ok()` rather than `unwrap_or_default` keeps "the daemon could not answer" apart from "nothing was cut" — `:9142-9148`. - `bounding_site_registry.rs:340-355` re-classifies `FILE_HEALTH_CAP` from `Intentional` to `Field("file_health_total + file_health_truncated")`, and `ENTRY_POINTS_CAP` likewise at `:358-372`. That re-classification is the durable part: a cap that claims to be intentional is exempt from disclosure, and these no longer are. ### THE CAVEAT — the literal ask is still not met `file_health_total` is emitted **only when the cut did not bite**: `.filter(|h| h.len() <= FILE_HEALTH_CAP)`, `server.rs:9154-9157`. So in **the exact case this issue's title names — 50 of 709** — `file_health_total` is **absent**, and only `file_health_truncated: true` ships. The reader learns *"this is a sample of unknown size"*, not *"50 of 709"*. That is defensible: fabricating a population the call never measured would be worse, and "unknown size" is at least not a lie. But it is a **different guarantee** from *"every ratio in a payload carries its denominator"*, and this issue should be closed on the honest version of the claim, not the literal one — or the code should emit the real total. ### No wire test — worth knowing before trusting the fields `file_health_total` occurs in exactly **four** places tree-wide: three in `server.rs`, one as a **registry string** at `bounding_site_registry.rs:354`. **No test asserts either field's value on a real `project_overview` payload.** `overview_payload_budget_e2e.rs` already builds a saturated fixture with 120 ref-carrying files — 2.4× the cap (`:511`, `:988`) — which is exactly where that assertion belongs, and it checks only the row count. **A wrong `file_health_total` would ship green.** ### `resolution_gaps.dynamic_influence` — NOT FIXED This issue named it as the sibling and asked for *"one clause, both fields — not a fix per field."* The second field did not move: - **No `semantics` on the wire.** `graph::DynamicInfluence` (`crates/daemon/src/graph.rs:1429`) carries `builtin_only`, `dynamic_endpoint`, `dynamic_influenced`, `not_reported` — and no population string. Its sibling `GapScope` has `pub semantics: String` at `:1470`, which is the shape this one is missing. - **Absent from the tool description.** `resolution_gaps`' `#[tool(description = …)]` at `server.rs:13834` names `resolver_degradation` and `scope` and never mentions `dynamic_influence`. - For the record: `not_reported` is **not** this issue's work — `git log -S` puts it in `79108fb feat: computed resolution influence (#77 step 7)`. ``` cargo test -p code-index-mcp --test disclosure_derivation_registry → 10 passed, EXIT 0 cargo test -p code-index-mcp --test bounding_site_registry → 17 passed, EXIT 0 ``` ### What closing needs 1. Decide whether `file_health_total` should ship the real total when the cut bites, or whether "sample of unknown size" is the accepted answer — and if the latter, amend this issue's title, which currently promises the denominator. 2. Assert both fields on the existing saturated fixture in `overview_payload_budget_e2e.rs`. 3. Give `dynamic_influence` its `semantics`, from the same clause — this issue's own instruction. 🤖 Triage lane, 2026-09-06, master `45cf6e4`

buildagent referenced this issue 2026-09-06 14:00:25 +02:00

overview_payload_budget_e2e has under 1% headroom against a load-dependent disclosure, so a correctness gate turns on machine load #98

buildagent commented 2026-09-06 14:01:09 +02:00

Author

Member

Copy link

FIXED — both fields, from one clause: every ratio in these payloads now carries its denominator, and the wire tests the triage said were missing exist.

Lane worktree /tmp/cosi-lane-budget, rebased onto origin/master (87a3fc8). Not pushed.

1. internal_resolution_pct — the literal ask, met

The triage recorded the caveat honestly: file_health_total ships only when the cut did not bite, so in the exact case this issue's title names — 50 of 709 — the reader learned "a sample of unknown size", not "50 of 709". That is a different guarantee from "every ratio carries its denominator".

The resolution is that the rate's denominator was never the file count. internal_resolution_pct is resolved / (resolved + internal_missed) — a ref ratio taken over the sample. So the two sums it divided now ride beside the quotient:

"internal_resolution_pct": 42.3,
"internal_resolution_resolved": 4711,
"internal_resolution_refs": 11137,
"file_health_truncated": true

The ratio now literally carries its denominator, exactly, with no new query and no fabricated population. file_health_total/file_health_truncated keep saying what the sample was — and file_health_total still stays absent when the cut bit, because the probe reads FILE_HEALTH_CAP + 1 rows and therefore never measures the population it cut from. A number there would be a fabricated denominator, which is worse than an absent one. That is now asserted, in both directions, rather than argued.

Cost: ~17 wire tokens on project_overview. FIELDS, not prose, in the entry_points_total/entry_points_truncated shape this response already uses — a semantics paragraph would have been ~75 tokens on the first call an agent makes, against a content ceiling with 44 tokens of headroom (see #98).

Three-state throughout: both basis fields are absent exactly when the rate is, and that is asserted.

2. resolution_gaps.dynamic_influence — the sibling, from the same clause

It now carries semantics, the shape GapScope beside it already had, written from the SQL predicate rather than from memory:

Counts every ref this call's filters selected that is UNRESOLVED (target_id IS NULL), is not a binding row, and was not reclassified — the same population the reason codes beside them describe, and NOT the refs/refs_resolved totals a project_overview reports. The four sum to that population exactly. not_reported is refs the index left unclassified (influence NULL), held apart from builtin_only because folding them in would claim the index looked when it did not.

That names the three ways 134,278 differs from the 226,714 the same response implies.

Deliberately NOT added to the tool description. This project's standing rule is that a disclosure belongs in the payload and description prose is unread and expensive — and resolution_gaps' description is already 1,427 characters on a startup payload that failed on Windows CI at 87a3fc8 (16,558 of 16,555; see #160). The semantics string travels with the block it qualifies, which is where a reader meets it.

3. The wire tests the triage said were missing

file_health_total occurs in exactly four places tree-wide … No test asserts either field's value on a real project_overview payload. … A wrong file_health_total would ship green.

It would not now. overview_payload_budget_e2e.rs, on the fixture the triage identified — 120 ref-carrying files against a cap of 50 — asserts, both directions:

• saturated: file_health_truncated == true, and file_health_total absent, with the reason in the message;
• small: file_health_truncated == false, and file_health_total == the rows actually served — "where the cut did not bite the sample IS the population, and that is the one case the total can be stated";
• both fixtures: the published internal_resolution_pct reproduces from the two published sums, or the pair is decoration.

MUTATIONS (RUN)

• internal_resolution_basis returning (resolved, resolved) — a denominator echoing its numerator → RED in server.rs's unit gate on resolved/(resolved+internal_missed); the e2e's quotient check is the wire-side half of the same predicate.
• The unit gate also pins that the denominator excludes no_candidate (5 of 9 refs in the fixture), which is the whole reframing and the reason the bare percentage beside repo-wide refs was unreadable.

One thing this change had to be registered for, and it is a good gate

resolution_percentage_stance::every_percentage_site_in_the_tree_is_registered went RED on the new e2e assertion — "computes or names a resolution percentage and has NO row in SITES". Registered as FixtureAsserted, with the reason: the assertion is an internal-consistency check in which the value cancels, so a tree that resolved nothing or everything passes identically and the only way to redden it is to publish a denominator that does not reproduce the published quotient — which is the defect this issue was filed about. #45 criterion 7 is untouched: no stance permits gating on a real tree.

For the record

not_reported is correctly not this issue's work — git log -S puts it in 79108fb. Untouched.

Gates

cargo fmt --all -- --check 0 · cargo clippy --workspace --all-targets -- -D warnings 0 · RUSTDOCFLAGS="-D warnings" cargo doc … 0 · cargo test --workspace --no-fail-fast 0 · COSI_E2E_LEG=daemon on the overview suite 0 · corpus ratchet executed=7, baselines untouched.

🤖 Payload-budget lane, 2026-09-06

## FIXED — **both** fields, from one clause: every ratio in these payloads now carries its denominator, and the wire tests the triage said were missing exist. Lane worktree `/tmp/cosi-lane-budget`, rebased onto `origin/master` (`87a3fc8`). Not pushed. ### 1. `internal_resolution_pct` — the literal ask, met The triage recorded the caveat honestly: `file_health_total` ships **only when the cut did not bite**, so in the exact case this issue's title names — **50 of 709** — the reader learned *"a sample of unknown size"*, not *"50 of 709"*. That is a different guarantee from *"every ratio carries its denominator"*. The resolution is that **the rate's denominator was never the file count**. `internal_resolution_pct` is `resolved / (resolved + internal_missed)` — a *ref* ratio taken over the sample. So the two sums it divided now ride beside the quotient: ```json "internal_resolution_pct": 42.3, "internal_resolution_resolved": 4711, "internal_resolution_refs": 11137, "file_health_truncated": true ``` The ratio now literally carries its denominator, exactly, with **no new query** and no fabricated population. `file_health_total`/`file_health_truncated` keep saying what the *sample* was — and `file_health_total` still stays absent when the cut bit, because the probe reads `FILE_HEALTH_CAP + 1` rows and therefore never measures the population it cut from. **A number there would be a fabricated denominator, which is worse than an absent one.** That is now asserted, in both directions, rather than argued. **Cost: ~17 wire tokens** on `project_overview`. FIELDS, not prose, in the `entry_points_total`/`entry_points_truncated` shape this response already uses — a `semantics` paragraph would have been ~75 tokens on the first call an agent makes, against a content ceiling with 44 tokens of headroom (see #98). Three-state throughout: both basis fields are absent exactly when the rate is, and that is asserted. ### 2. `resolution_gaps.dynamic_influence` — the sibling, from the same clause It now carries `semantics`, the shape `GapScope` beside it already had, written **from the SQL predicate rather than from memory**: > Counts every ref this call's filters selected that is UNRESOLVED (`target_id IS NULL`), is not a `binding` row, and was not reclassified — the same population the reason codes beside them describe, and NOT the `refs`/`refs_resolved` totals a project_overview reports. The four sum to that population exactly. `not_reported` is refs the index left unclassified (`influence` NULL), held apart from `builtin_only` because folding them in would claim the index looked when it did not. That names the three ways 134,278 differs from the 226,714 the same response implies. **Deliberately NOT added to the tool description.** This project's standing rule is that a disclosure belongs in the payload and description prose is unread and expensive — and `resolution_gaps`' description is already 1,427 characters on a startup payload that **failed on Windows CI at `87a3fc8`** (16,558 of 16,555; see #160). The `semantics` string travels with the block it qualifies, which is where a reader meets it. ### 3. The wire tests the triage said were missing > `file_health_total` occurs in exactly four places tree-wide … **No test asserts either field's value on a real `project_overview` payload.** … **A wrong `file_health_total` would ship green.** It would not now. `overview_payload_budget_e2e.rs`, on the fixture the triage identified — 120 ref-carrying files against a cap of 50 — asserts, both directions: - saturated: `file_health_truncated == true`, and `file_health_total` **absent**, with the reason in the message; - small: `file_health_truncated == false`, and `file_health_total ==` the rows actually served — *"where the cut did not bite the sample IS the population, and that is the one case the total can be stated"*; - **both** fixtures: the published `internal_resolution_pct` **reproduces from the two published sums**, or the pair is decoration. ### MUTATIONS (RUN) - `internal_resolution_basis` returning `(resolved, resolved)` — a denominator echoing its numerator → RED in `server.rs`'s unit gate on `resolved/(resolved+internal_missed)`; the e2e's quotient check is the wire-side half of the same predicate. - The unit gate also pins that the denominator **excludes `no_candidate`** (5 of 9 refs in the fixture), which is the whole reframing and the reason the bare percentage beside repo-wide `refs` was unreadable. ### One thing this change had to be registered for, and it is a good gate `resolution_percentage_stance::every_percentage_site_in_the_tree_is_registered` went RED on the new e2e assertion — *"computes or names a resolution percentage and has NO row in SITES"*. Registered as `FixtureAsserted`, with the reason: the assertion is an internal-consistency check **in which the value cancels**, so a tree that resolved nothing or everything passes identically and the only way to redden it is to publish a denominator that does not reproduce the published quotient — which is the defect this issue was filed about. #45 criterion 7 is untouched: no stance permits gating on a real tree. ### For the record `not_reported` is correctly not this issue's work — `git log -S` puts it in `79108fb`. Untouched. ### Gates `cargo fmt --all -- --check` 0 · `cargo clippy --workspace --all-targets -- -D warnings` 0 · `RUSTDOCFLAGS="-D warnings" cargo doc …` 0 · `cargo test --workspace --no-fail-fast` 0 · `COSI_E2E_LEG=daemon` on the overview suite 0 · corpus ratchet `executed=7`, baselines untouched. 🤖 Payload-budget lane, 2026-09-06

dhoyer referenced this issue from a commit 2026-09-06 14:52:28 +02:00

feat: the payload budgets stop being one number that means two things

buildagent commented 2026-09-06 16:33:06 +02:00

Author

Member

Copy link

STAYS OPEN — narrowed to one missing gate. Both fields shipped; one of them is ungraded.

Close-out lane, verified on merged master fc329a8.

Half 1 — the rate now carries its basis, and it is graded. internal_resolution_resolved / internal_resolution_refs are declared on the reply struct at crates/mcp-server/src/server.rs:9429-9441 and populated at :9563-9564 from internal_resolution_basis() (:4906). The reframing is the honest one: the denominator was never the file count — it is a ref ratio over the sample, and the two sums it divides now ride beside the quotient. The sample's own size and truncation ship too (file_health_total / file_health_truncated, :9179-9188), with file_health_total deliberately absent when the cut bit, because the call never measures the population it cut from.

Graded by internal_resolution_ships_the_two_sums_it_divided (:19950) — pins (3, 4) on a fixture with 9 refs of which 5 are no_candidate, so it pins that the denominator excludes them; the (resolved, resolved) mutation is RED — and on a real payload by overview_payload_budget_e2e.rs:1193, in both the saturated and small directions.

RUN, exit 0: internal_resolution_ships_the_two_sums_it_divided ... ok · COSI_E2E_LEG=daemon overview_payload_budget_e2e 3 passed · influence_disclosure_e2e 4 passed.

Half 2 — the sibling got the field but not the gate, and that is the residual.

resolution_gaps.dynamic_influence.semantics exists (crates/daemon/src/graph.rs:1446-1462 declared, :2165-2176 populated, written from the SQL predicate directly above it) and does reach the wire through rpc_index.rs:984 → typed(...) and server.rs:13905 → ok_json(&resp).

Nothing asserts it. The field is built with ..Default::default() under #[serde(default, skip_serializing_if = "String::is_empty")], so deleting the semantics: initializer at graph.rs:2165 compiles, silently drops the disclosure from the payload, and every suite stays green. Its distinctive fragments — "The four sum to", "is not a `binding` row", "folding them in would claim" — occur nowhere outside graph.rs. The one wire test over this block, influence_disclosure_e2e.rs:196 resolution_gaps_splits_its_own_population_by_influence, asserts the four counts sum to the reason-code population and never touches semantics. disclosure_surface_registry.rs:417-427 checks only that the producer call exists, and its own header (:62-69) says so.

This is the same "a wrong value would ship green" finding the 2026-09-06 triage made about file_health_total — fixed on one half of the pair, still standing on the other. The issue asked for "one clause, both fields — not a fix per field", and one field's clause has no test under it.

Close this when resolution_gaps_splits_its_own_population_by_influence (or a sibling) asserts dynamic_influence.semantics is present and non-empty on the wire, with the deletion of the initializer recorded as a mutation that was RUN to red.

## STAYS OPEN — narrowed to one missing gate. Both fields shipped; one of them is ungraded. Close-out lane, verified on merged master `fc329a8`. **Half 1 — the rate now carries its basis, and it is graded.** `internal_resolution_resolved` / `internal_resolution_refs` are declared on the reply struct at `crates/mcp-server/src/server.rs:9429-9441` and populated at `:9563-9564` from `internal_resolution_basis()` (`:4906`). The reframing is the honest one: the denominator was never the file count — it is a ref ratio over the sample, and the two sums it divides now ride beside the quotient. The sample's own size and truncation ship too (`file_health_total` / `file_health_truncated`, `:9179-9188`), with `file_health_total` deliberately **absent** when the cut bit, because the call never measures the population it cut from. Graded by `internal_resolution_ships_the_two_sums_it_divided` (`:19950`) — pins `(3, 4)` on a fixture with 9 refs of which 5 are `no_candidate`, so it pins that the denominator *excludes* them; the `(resolved, resolved)` mutation is RED — and on a real payload by `overview_payload_budget_e2e.rs:1193`, in both the saturated and small directions. **RUN, exit 0:** `internal_resolution_ships_the_two_sums_it_divided ... ok` · `COSI_E2E_LEG=daemon overview_payload_budget_e2e` 3 passed · `influence_disclosure_e2e` 4 passed. **Half 2 — the sibling got the field but not the gate, and that is the residual.** `resolution_gaps.dynamic_influence.semantics` exists (`crates/daemon/src/graph.rs:1446-1462` declared, `:2165-2176` populated, written from the SQL predicate directly above it) and does reach the wire through `rpc_index.rs:984 → typed(...)` and `server.rs:13905 → ok_json(&resp)`. **Nothing asserts it.** The field is built with `..Default::default()` under `#[serde(default, skip_serializing_if = "String::is_empty")]`, so **deleting the `semantics:` initializer at `graph.rs:2165` compiles, silently drops the disclosure from the payload, and every suite stays green.** Its distinctive fragments — `"The four sum to"`, ``"is not a `binding` row"``, `"folding them in would claim"` — occur nowhere outside `graph.rs`. The one wire test over this block, `influence_disclosure_e2e.rs:196 resolution_gaps_splits_its_own_population_by_influence`, asserts the four counts sum to the reason-code population and never touches `semantics`. `disclosure_surface_registry.rs:417-427` checks only that the *producer call* exists, and its own header (`:62-69`) says so. This is the same "a wrong value would ship green" finding the 2026-09-06 triage made about `file_health_total` — fixed on one half of the pair, still standing on the other. The issue asked for *"one clause, both fields — not a fix per field"*, and one field's clause has no test under it. **Close this when** `resolution_gaps_splits_its_own_population_by_influence` (or a sibling) asserts `dynamic_influence.semantics` is present and non-empty **on the wire**, with the deletion of the initializer recorded as a mutation that was RUN to red.

buildagent referenced this issue 2026-09-06 16:36:14 +02:00

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

buildagent referenced this issue 2026-09-06 16:38:01 +02:00

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

dhoyer referenced this issue from a commit 2026-09-07 01:22:23 +02:00

fix: four payloads that named a place the reader could not find (#202, #201, #149)

dhoyer referenced this issue from a commit 2026-09-07 01:22:23 +02:00

merge lane/payload-honesty: four payloads that named a place the reader could not find (#202 #201 #149)

buildagent commented 2026-09-09 12:36:31 +02:00

Author

Member

Copy link

Fixed and released in v0.27.0 — both halves. This issue was never closed.

The rate now carries its denominator

internal_resolution_pct ships beside internal_resolution_resolved and internal_resolution_refs, and the gate requires the quotient to reproduce from them (crates/mcp-server/tests/overview_payload_budget_e2e.rs:1436-1466), on BOTH the small and the saturated overview:

assert!(
    (pct - 100.0 * resolved as f64 / refs as f64).abs() < 0.05,
    "the {which} overview publishes internal_resolution_pct {pct} but a basis of \
     {resolved}/{refs} = {}. A denominator that does not reproduce the published \
     quotient is worse than none.",

That last sentence is the part worth keeping. A denominator that merely exists would satisfy a field-presence check while still being decoration; requiring it to reproduce the published number is what makes it a measurement. The missing-denominator arm quotes this issue verbatim in its panic message, so a regression names #149 rather than a field name.

The two-overview loop is what closes the "looks identical on a 50k-file repo" complaint: the saturated case is where the LIMIT 50 bites, and it must ship a basis showing that it bit.

The sibling

resolution_gaps.dynamic_influence.semantics was the residual, fixed in 730bf15. It is worth recording how it was vacuous, because it is a reusable trap: the field was built with ..Default::default() behind skip_serializing_if = "String::is_empty", so deleting the initializer compiled, dropped the disclosure from the wire, and left every suite green. It is now asserted on the wire against the terms of the SQL predicate it describes, so a placeholder string cannot satisfy it either.

Mutation M6 (delete dynamic_influence.semantics's initializer) → RED.

harness_settle_barrier's leg-routed population went 36 → 37 with the arrival NAMED, per that gate's own standing rule — so the new e2e could not have been added silently.

Closing: every ratio in the payload now carries its denominator, which was the ask.

Fixed and released in **v0.27.0** — both halves. This issue was never closed. ## The rate now carries its denominator `internal_resolution_pct` ships beside `internal_resolution_resolved` and `internal_resolution_refs`, and the gate requires the **quotient to reproduce from them** (`crates/mcp-server/tests/overview_payload_budget_e2e.rs:1436-1466`), on BOTH the small and the saturated overview: ```rust assert!( (pct - 100.0 * resolved as f64 / refs as f64).abs() < 0.05, "the {which} overview publishes internal_resolution_pct {pct} but a basis of \ {resolved}/{refs} = {}. A denominator that does not reproduce the published \ quotient is worse than none.", ``` That last sentence is the part worth keeping. A denominator that merely *exists* would satisfy a field-presence check while still being decoration; requiring it to reproduce the published number is what makes it a measurement. The missing-denominator arm quotes this issue verbatim in its panic message, so a regression names #149 rather than a field name. The two-overview loop is what closes the "looks identical on a 50k-file repo" complaint: the saturated case is where the `LIMIT 50` bites, and it must ship a basis showing that it bit. ## The sibling `resolution_gaps.dynamic_influence.semantics` was the residual, fixed in `730bf15`. It is worth recording *how* it was vacuous, because it is a reusable trap: the field was built with `..Default::default()` behind `skip_serializing_if = "String::is_empty"`, so **deleting the initializer compiled, dropped the disclosure from the wire, and left every suite green.** It is now asserted on the wire against the terms of the SQL predicate it describes, so a placeholder string cannot satisfy it either. Mutation M6 (delete `dynamic_influence.semantics`'s initializer) → RED. `harness_settle_barrier`'s leg-routed population went 36 → 37 with the arrival NAMED, per that gate's own standing rule — so the new e2e could not have been added silently. Closing: every ratio in the payload now carries its denominator, which was the ask.

buildagent closed this issue 2026-09-09 12:36:35 +02:00

buildagent referenced this issue 2026-09-09 12:45:22 +02:00

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

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

p1-integration

p0-integration

release/v0.32.2

release/v0.32.1

epic-i072-release-032

windows-installer

i269b-registry-truth

probe-win-baseline

fix/246-shadowed-imports

release/0.28.1

fix/review-followthrough-20260911

iwin-msvc-archive

v0.32.2

v0.32.1

v0.32.0

v0.31.2

v0.31.1

v0.31.0

v0.30.1

v0.30.0

v0.29.0

v0.28.3

v0.28.2

v0.28.1

v0.28.0

v0.27.1

v0.27.0

v0.26.1

v0.26.0

v0.25.0

v0.24.1

v0.24.0

v0.23.1

v0.23.0

v0.22.3

v0.22.2

v0.22.1

v0.22.0

v0.21.0

v0.20.3

v0.20.2

v0.20.1

v0.20.0

v0.19.5

v0.19.4

v0.19.3

v0.19.2

v0.19.1

v0.19.0

v0.18.1

v0.18.0

v0.17.0

v0.16.0

v0.15.3

v0.14.0

v0.13.3

v0.13.2

v0.13.1

v0.13.0

v0.12.0

v0.11.7

v0.11.6

v0.11.5

v0.11.4

v0.11.3

v0.11.2

v0.11.1

v0.11.0

v0.10.2

v0.10.1

v0.10.0

v0.9.0

v0.8.7

v0.8.6

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.1

v0.7.0

v0.6.1

v0.6.0

v0.5.21

v0.5.20

v0.5.19

v0.5.18

v0.5.17

v0.5.16

v0.5.15

v0.5.14

v0.5.13

v0.5.12

v0.5.11

v0.5.10

v0.5.9

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.2

v0.4.1

v0.4.0

v0.3.3

v0.3.2

v0.3.1

v0.3.0

v0.2.0

Labels

Clear labels   

code-review

  

correctness

  

dos

  

performance

  

security

  

severity/high

  

severity/low

  

severity/medium

  

tech-debt

  

Kind/Breaking

Breaking change that won't be backward compatible

  

Kind/Bug

Something is not working

  

Kind/Documentation

Documentation changes

  

Kind/Enhancement

Improve existing functionality

  

Kind/Feature

New functionality

  

Kind/Security

This is security issue

  

Kind/Testing

Issue or pull request related to testing

  

Priority

Critical

The priority is critical

  

Priority

High

The priority is high

  

Priority

Low

The priority is low

  

Priority

Medium

The priority is medium

  

Reviewed

Confirmed

Issue has been confirmed

  

Reviewed

Duplicate

This issue or pull request already exists

  

Reviewed

Invalid

Invalid issue

  

Reviewed

Won't Fix

This issue won't be fixed

  

Status

Abandoned

Somebody has started to work on this but abandoned work

  

Status

Blocked

Something is blocking this issue or pull request

  

Status

Need More Info

Feedback is required to reproduce issue or to continue work

No labels

code-review

correctness

dos

performance

security

severity/high

severity/low

severity/medium

tech-debt

Kind/Breaking

Kind/Bug

Kind/Documentation

Kind/Enhancement

Kind/Feature

Kind/Security

Kind/Testing

Priority

Critical

Priority

High

Priority

Low

Priority

Medium

Reviewed

Confirmed

Reviewed

Duplicate

Reviewed

Invalid

Reviewed

Won't Fix

Status

Abandoned

Status

Blocked

Status

Need More Info

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

h-dv/code-index#149

No description provided.