h-dv/code-index
Watch
4
0
Fork
You've already forked code-index
 0
Code Issues 46 Pull requests Projects Releases 98 Packages Wiki Activity Actions

Two gates are blind to the population they exist for: the argument registry misses a prelude closure (FIXED), and no gate sees a read-path EXECUTION-COST regression #158

New issue
Open
opened 2026-09-05 17:44:41 +02:00 by buildagent · 6 comments
buildagent commented 2026-09-05 17:44:41 +02:00
Member
Copy link

Two independent instances found on 2026-09-05, filed together because the pattern is the finding and it recurred four times in one day.

CORRECTED 2026-09-06 by the doc-drift lane. Part 1 is FIXED (verified, below). Part 2's residual has now been overstated twice — once by the implementing lane and once by the triage that corrected it — and both corrections are folded into section 2 rather than left in comments, because a reader who stops at the section heading is the reader this issue exists for. The heading itself was wrong and has been rewritten.

1. The argument registry: all six tests green over a completely ungraded parameter — FIXED

While adding the resolution filter (#141), a lane's first cut wrote the reader as a closure in the dispatch prelude:

let opt_resolution = || { opt_str("resolution") … };

the_scanner_knows_every_reader_closure matches |k: &str| closure heads, and this one takes no argument. The per-arm key scan then found the read in the prelude, not in an arm. Result: all six registry tests stayed green over a new request parameter with no row and no grading at all.

The registry's population is "keys read inside a dispatch arm". A key read once, above the match, is invisible to it — and that is exactly the shape a developer reaches for when two arms need the same argument.

Closed by argument_registry_e2e.rs::every_request_argument_is_read_inside_a_dispatch_arm, which asserts the structural fact instead of the two symptoms: the population derived_optional_args can ATTRIBUTE and the population that EXISTS are the same multiset, over one shared arm splitter (dispatch_arm_bodies) so two scanners cannot disagree. crates/daemon/src/server.rs now records the gap as closed and survives as the worked example. The stated bound is that SERVER_SRC is one file.

2. cost-baseline.json cannot see a read-path EXECUTION-COST regression — the honesty half landed, the coverage half did not

corpus_cold_index_cost_stays_within_the_blessed_band measures a cold index and issues no daemon read. So a read-path index can only ever raise its vm_step, never lower it. "Add the index and check the ratchet drops" is not a test that exists.

cost-baseline.json now carries a _population block declaring measured: "cold_index" and naming the read path as unmeasured, kept honest by corpus_cost.rs::the_cost_gate_declares_the_population_it_measures. That is the "explicit statement in the gate's own doc" half of the repair below, and it is done.

THE RESIDUAL, STATED ACCURATELY AT THE THIRD ATTEMPT. Two earlier statements of it were too strong:

  • "There is still no read-path cost measurement." False. crates/daemon/tests/file_health_bounded_e2e.rs::the_work_follows_the_reported_files_not_the_index measures SQLite vm_step over graph::index_health — a read path — through an in-process sqlite3_profile callback, as a ratio between two fixtures.
  • "There is no read-path cost RATCHET with blessed numbers over the corpus." Also false. crates/mcp-server/tests/agent_task_bench.rs (#51) is exactly that: blessed numbers in tests/bench/ratchet.json, over four corpus repos, with tool_tokens, tokens_per_correct, tool_calls, ratio_vs_rg_only and rg_false_positives all gated in both directions, plus a recall floor.

What is actually missing is a read-path ratchet on the EXECUTION-COST dimension. The corpus read-path ratchet blesses payload size and answer quality; it records no vm_step, and ratchet.json's own _conditions block says "Wall clock is NOT recorded here" deliberately, because the numbers are taken under contention. So a read-path change that costs opcodes without changing the payload — which is precisely what #143's symbols.ref_count index was — is invisible to every gate in the tree, and had to be decided by hand. crates/indexer/src/migrations/m0061_file_refs_rollup.rs and crates/daemon/src/local_index.rs both cite that blindness as the reason.

Why they are one issue

Both are the pattern this repository hit four times today:

# gate blind to
1 PowerShell ASCII gate the wrong files — per-step shell: only, missing defaults.run.shell
2 same gate's floor the wrong count — >= 10 on a file with 5
3 same gate's scan the wrong lines — what prints, not what builds what prints
4 argument registry the wrong scope — arms, not the prelude
5 cost baseline the wrong direction — writes, not reads

An anti-vacuity floor proves a scan found something. It cannot prove the scan looked at the right set, because the floor is calibrated against whatever the scan currently finds. A floor is only worth what it was measured against — and so is a scan.

A sixth entry belongs on that table now, and it is this issue's own text: the residual was blind to the gates that already existed, twice, in the direction of overstating the work left. That is the same error class as #185/#186/#187 and it was made here, in the tracker, by the people fixing it.

What a repair looks like

For (1): done — see section 1.

For (2): the "explicit statement" option is done. The remaining option is a read-path vm_step dimension — not wall clock, which this tree has already declined to record for a stated reason. Both halves of the mechanism exist and it is an assembly job rather than research: file_health_bounded_e2e.rs's sqlite3_profile callback is how to measure a read in opcodes, and corpus_cost's bless/render machinery is how to ratchet it. What it needs that neither provides is a fixed, representative read set and its own blessed record — and creating a new protected baseline is a decision that should be taken deliberately rather than as a side effect of closing this.

The #143 measurement, recorded so it is not filed a third time

At crates/daemon/src/local_index.rs:

vm_step wall
top_referenced_symbols (read, 1× per project_overview) 106,700 → 111 6.27 ms → 0.021 ms
recompute_ref_counts (write, every resolve pass) 2,359,234 → 2,521,503 (+6.9%) 196 → 227 ms

recompute_ref_counts runs on the scoped path — every watcher-triggered re-index — and rebuilds the whole column regardless of scope. A session saves files far more often than it calls project_overview, so the trade is negative on exactly the axis #73's bless names as its own disqualifier ("a hot repeated write path"). 6 ms is ~2.4% of project_overview, whose file_health core alone is 223 ms.

The first version of that measurement was wrong and the lane caught it: re-running both variants against the same two files reported the indexed write as 36% faster — WAL accumulation across iterations. Fresh copy per run, alternating, inverted the result, and the corrected direction agrees with the opcode count while the contaminated one did not.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

Two independent instances found on 2026-09-05, filed together because the pattern is the finding and it recurred four times in one day. > **CORRECTED 2026-09-06 by the doc-drift lane.** Part 1 is FIXED (verified, below). Part 2's residual has now been overstated **twice** — once by the implementing lane and once by the triage that corrected it — and both corrections are folded into section 2 rather than left in comments, because a reader who stops at the section heading is the reader this issue exists for. The heading itself was wrong and has been rewritten. ## 1. The argument registry: all six tests green over a completely ungraded parameter — **FIXED** While adding the `resolution` filter (#141), a lane's first cut wrote the reader as a closure in the **dispatch prelude**: ```rust let opt_resolution = || { opt_str("resolution") … }; ``` `the_scanner_knows_every_reader_closure` matches `|k: &str|` closure heads, and this one takes no argument. The per-arm key scan then found the read in the **prelude**, not in an arm. Result: **all six registry tests stayed green over a new request parameter with no row and no grading at all.** The registry's population is "keys read inside a dispatch arm". A key read once, above the match, is invisible to it — and that is exactly the shape a developer reaches for when two arms need the same argument. **Closed** by `argument_registry_e2e.rs::every_request_argument_is_read_inside_a_dispatch_arm`, which asserts the structural fact instead of the two symptoms: the population `derived_optional_args` can ATTRIBUTE and the population that EXISTS are the same multiset, over one shared arm splitter (`dispatch_arm_bodies`) so two scanners cannot disagree. `crates/daemon/src/server.rs` now records the gap as closed and survives as the worked example. The stated bound is that `SERVER_SRC` is one file. ## 2. `cost-baseline.json` cannot see a read-path EXECUTION-COST regression — the honesty half landed, the coverage half did not `corpus_cold_index_cost_stays_within_the_blessed_band` measures a **cold index** and issues **no daemon read**. So a read-path index can only ever *raise* its `vm_step`, never lower it. "Add the index and check the ratchet drops" is not a test that exists. `cost-baseline.json` now carries a `_population` block declaring `measured: "cold_index"` and naming the read path as unmeasured, kept honest by `corpus_cost.rs::the_cost_gate_declares_the_population_it_measures`. That is the "explicit statement in the gate's own doc" half of the repair below, and it is done. **THE RESIDUAL, STATED ACCURATELY AT THE THIRD ATTEMPT.** Two earlier statements of it were too strong: - ~~"There is still no read-path cost measurement."~~ **False.** `crates/daemon/tests/file_health_bounded_e2e.rs::the_work_follows_the_reported_files_not_the_index` measures SQLite `vm_step` over `graph::index_health` — a read path — through an in-process `sqlite3_profile` callback, as a ratio between two fixtures. - ~~"There is no read-path cost RATCHET with blessed numbers over the corpus."~~ **Also false.** `crates/mcp-server/tests/agent_task_bench.rs` (#51) is exactly that: blessed numbers in `tests/bench/ratchet.json`, over four corpus repos, with `tool_tokens`, `tokens_per_correct`, `tool_calls`, `ratio_vs_rg_only` and `rg_false_positives` all gated in **both** directions, plus a recall floor. **What is actually missing is a read-path ratchet on the EXECUTION-COST dimension.** The corpus read-path ratchet blesses *payload size and answer quality*; it records no `vm_step`, and `ratchet.json`'s own `_conditions` block says **"Wall clock is NOT recorded here"** deliberately, because the numbers are taken under contention. So a read-path change that costs opcodes without changing the payload — which is precisely what #143's `symbols.ref_count` index was — is invisible to every gate in the tree, and had to be decided by hand. `crates/indexer/src/migrations/m0061_file_refs_rollup.rs` and `crates/daemon/src/local_index.rs` both cite that blindness as the reason. ## Why they are one issue Both are the pattern this repository hit four times today: | # | gate | blind to | |---|---|---| | 1 | PowerShell ASCII gate | the wrong **files** — per-step `shell:` only, missing `defaults.run.shell` | | 2 | same gate's floor | the wrong **count** — `>= 10` on a file with 5 | | 3 | same gate's scan | the wrong **lines** — what prints, not what builds what prints | | 4 | argument registry | the wrong **scope** — arms, not the prelude | | 5 | cost baseline | the wrong **direction** — writes, not reads | **An anti-vacuity floor proves a scan found something. It cannot prove the scan looked at the right set, because the floor is calibrated against whatever the scan currently finds.** A floor is only worth what it was measured against — and so is a scan. A sixth entry belongs on that table now, and it is this issue's own text: **the residual was blind to the gates that already existed**, twice, in the direction of overstating the work left. That is the same error class as #185/#186/#187 and it was made here, in the tracker, by the people fixing it. ## What a repair looks like For (1): **done** — see section 1. For (2): the "explicit statement" option is **done**. The remaining option is a read-path **`vm_step`** dimension — not wall clock, which this tree has already declined to record for a stated reason. Both halves of the mechanism exist and it is an assembly job rather than research: `file_health_bounded_e2e.rs`'s `sqlite3_profile` callback is how to measure a read in opcodes, and `corpus_cost`'s bless/render machinery is how to ratchet it. What it needs that neither provides is a fixed, representative read set and its own blessed record — and creating a new protected baseline is a decision that should be taken deliberately rather than as a side effect of closing this. ## The #143 measurement, recorded so it is not filed a third time At `crates/daemon/src/local_index.rs`: | | vm_step | wall | |---|---|---| | `top_referenced_symbols` (read, 1× per `project_overview`) | 106,700 → **111** | 6.27 ms → **0.021 ms** | | `recompute_ref_counts` (write, **every resolve pass**) | 2,359,234 → **2,521,503** (+6.9%) | 196 → **227 ms** | `recompute_ref_counts` runs on the scoped path — every watcher-triggered re-index — and rebuilds the whole column regardless of scope. A session saves files far more often than it calls `project_overview`, so the trade is negative on exactly the axis #73's bless names as its own disqualifier ("a hot repeated write path"). 6 ms is ~2.4% of `project_overview`, whose `file_health` core alone is 223 ms. **The first version of that measurement was wrong and the lane caught it**: re-running both variants against the same two files reported the indexed write as 36% *faster* — WAL accumulation across iterations. Fresh copy per run, alternating, inverted the result, and the corrected direction agrees with the opcode count while the contaminated one did not. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K
buildagent commented 2026-09-06 00:23:46 +02:00
Author
Member
Copy link

Part 1 FIXED. Part 2 PARTIALLY fixed, with the residual named.

Lane worktree: /tmp/cosi-lane-honesty, branch wip/honesty, based on origin/master (ea821b6). Not pushed.

1. The argument registry's blind scope — FIXED

Mechanism, and why it is one clause and not two

The issue names two independent reasons the resolution closure was invisible: the reader-closure gate matches |k: &str| heads and that one took no argument, and the per-arm key scan found the read in the prelude. A gate per reason would be two gates with the same blind spot one step further out — a free function in server.rs reading params.get("k") is neither a closure head nor a prelude line.

So the repair asserts the structural fact instead:

argument_registry_e2e.rs::every_request_argument_is_read_inside_a_dispatch_arm — the population derived_optional_args can ATTRIBUTE and the population that actually EXISTS are the same multiset.

Every literal request-key read anywhere in server.rs (every opt_*/req_* reader spelling, plus req.params.get(" and whatever alias dispatch binds) is counted over the whole normalized file, then the per-arm counts are subtracted. A leftover is a read no (method, arg) pair can be derived from, whatever spelling it used. derived_optional_args and the new gate now share ONE arm splitter (dispatch_arm_bodies), so two scanners cannot disagree about which reads are attributable.

Bounded honestly in the test's own doc: SERVER_SRC is one file. A helper in graph.rs handed &req.params is outside the scan; nothing does that today, and the stated repair is to widen SERVER_SRC rather than to read the gate as proof.

crates/daemon/src/server.rs:411's comment — which the issue cites as recording the gap as unfixed — now records it as closed and survives as the worked example.

Mutations (all RUN, real output)

M1 — the historical first cut, verbatim, back in the prelude:

let opt_resolution = || opt_str("resolution");

running 3 tests
test the_scanner_knows_every_reader_closure ... ok
test registry_covers_exactly_the_optional_arguments_in_dispatch ... ok
test every_request_argument_is_read_inside_a_dispatch_arm ... FAILED

request argument(s) read in server.rs OUTSIDE any dispatch arm:
  opt_str("resolution")   (x1)
The argument registry attributes a key to the arm it is read in, so a read above the match — or
in a free function — derives no `(method, arg)` pair, demands no REGISTRY row, and ships UNGRADED
with every test in this file green. That is #158, and it is how `resolution` (#141) nearly shipped
ungraded.

Note the first two lines: both pre-existing registry gates stayed GREEN. The new test is what caught it, not a different gate.

M2 — the wider clause, proved: a free function OUTSIDE the prelude and outside the match:

fn stray_free_reader(params: &serde_json::Value) -> Option<String> {
    let p = params;
    p.get("dry_run").and_then(|v| v.as_str()).map(str::to_string)
}

test the_scanner_knows_every_reader_closure ... ok
test registry_covers_exactly_the_optional_arguments_in_dispatch ... ok
test every_request_argument_is_read_inside_a_dispatch_arm ... FAILED

request argument(s) read in server.rs OUTSIDE any dispatch arm:
  p.get("dry_run")   (x1)

M3 — anti-vacuity (break the arm split so the scan attributes nothing):

only 0 dispatch arms were found — the arm split is broken, and every read in the file would be
reported as unattributable. Check the 8-space `"name" =>` shape in `dispatch_arm_bodies`.

2. The cost baseline's blind DIRECTION — PARTIALLY fixed

What was done

The issue offers two repairs and calls the second "nearly free". I took the second, and made it non-vacuous rather than prose:

  • tests/corpus/cost-baseline.json gains a _population block — placed BEFORE _blessed, because render_baseline keeps only what precedes it and a block on the wrong side would be silently deleted by the next bless (the failure mode that writer already carries an after_repos refusal for). It names measured: "cold_index" and a not_measured list whose first entry is the read path, carrying the #143 measurement verbatim so it is not reasoned about a third time.
  • corpus_cost.rs::the_cost_gate_declares_the_population_it_measures keeps the declaration from ageing: it requires the block, requires it to sit before _blessed, runs render_baseline and asserts the block survives a bless, and pins the harness to exactly ONE measured leg whose body is index_path. Adding a read leg is RED until the declaration is updated.
  • The module header's "Does NOT catch" list gains the read-path bullet.

Both needles in the harness half are built with concat! and never written out literally — this test's own prose and failure messages are part of include_str!("corpus_cost.rs"), so a literal needle would have matched itself. (That was a real bug in my first cut: the index_path assertion was satisfied by the string in its own failure message.)

No blessed number moved. _blessed.reason and every repos row are byte-identical.

Mutations (both RUN)

M4 — delete the _population block:

cost-baseline.json has no `_population` block. This gate measures a COLD INDEX and issues no read,
so it is blind to the read path in both directions — and a reader of a failure here has no way to
learn that from the artifact.

M5 — add a second measured leg (a measure_reads that issues a read query):

assertion `left == right` failed: expected exactly ONE measured leg in this file, found 2 call
sites. If a read-path leg was added, `cost-baseline.json`'s `_population` block must stop saying
the read path is unmeasured — and this count must be raised deliberately, in the same change.
  left: 2
 right: 1

THE RESIDUAL, NAMED

There is still no read-path cost measurement. The gate now says it measures writes only; it does not measure reads. Building that dimension needs the daemon's LocalIndex, a fixed representative read set, and its own blessed numbers — enough that bolting it onto the write-path gate would change what a failure there means. It is not in this branch and I am not claiming it is. Item (2) of this issue is therefore half done: the honesty half, not the coverage half.

Gates

cargo fmt --all -- --check 0 · cargo clippy --workspace --all-targets -- -D warnings 0 · RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps --document-private-items 0. tests/corpus/baseline.json unmoved at 534084b856c22566c48e386bc41ed67e.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

## Part 1 FIXED. Part 2 PARTIALLY fixed, with the residual named. Lane worktree: `/tmp/cosi-lane-honesty`, branch `wip/honesty`, based on `origin/master` (`ea821b6`). Not pushed. --- ## 1. The argument registry's blind scope — FIXED ### Mechanism, and why it is one clause and not two The issue names two independent reasons the `resolution` closure was invisible: the reader-closure gate matches `|k: &str|` heads and that one took no argument, and the per-arm key scan found the read in the prelude. A gate per reason would be two gates with the same blind spot one step further out — a free function in `server.rs` reading `params.get("k")` is neither a closure head nor a prelude line. So the repair asserts the **structural** fact instead: > `argument_registry_e2e.rs::every_request_argument_is_read_inside_a_dispatch_arm` — the population `derived_optional_args` can ATTRIBUTE and the population that actually EXISTS are the same multiset. Every literal request-key read anywhere in `server.rs` (every `opt_*`/`req_*` reader spelling, plus `req.params.get("` and whatever alias `dispatch` binds) is counted over the whole normalized file, then the per-arm counts are subtracted. A leftover is a read no `(method, arg)` pair can be derived from, whatever spelling it used. `derived_optional_args` and the new gate now share ONE arm splitter (`dispatch_arm_bodies`), so two scanners cannot disagree about which reads are attributable. Bounded honestly in the test's own doc: `SERVER_SRC` is one file. A helper in `graph.rs` handed `&req.params` is outside the scan; nothing does that today, and the stated repair is to widen `SERVER_SRC` rather than to read the gate as proof. `crates/daemon/src/server.rs:411`'s comment — which the issue cites as recording the gap as unfixed — now records it as closed and survives as the worked example. ### Mutations (all RUN, real output) **M1 — the historical first cut, verbatim, back in the prelude:** ```rust let opt_resolution = || opt_str("resolution"); ``` ``` running 3 tests test the_scanner_knows_every_reader_closure ... ok test registry_covers_exactly_the_optional_arguments_in_dispatch ... ok test every_request_argument_is_read_inside_a_dispatch_arm ... FAILED request argument(s) read in server.rs OUTSIDE any dispatch arm: opt_str("resolution") (x1) The argument registry attributes a key to the arm it is read in, so a read above the match — or in a free function — derives no `(method, arg)` pair, demands no REGISTRY row, and ships UNGRADED with every test in this file green. That is #158, and it is how `resolution` (#141) nearly shipped ungraded. ``` **Note the first two lines**: both pre-existing registry gates stayed GREEN. The new test is what caught it, not a different gate. **M2 — the wider clause, proved: a free function OUTSIDE the prelude and outside the match:** ```rust fn stray_free_reader(params: &serde_json::Value) -> Option<String> { let p = params; p.get("dry_run").and_then(|v| v.as_str()).map(str::to_string) } ``` ``` test the_scanner_knows_every_reader_closure ... ok test registry_covers_exactly_the_optional_arguments_in_dispatch ... ok test every_request_argument_is_read_inside_a_dispatch_arm ... FAILED request argument(s) read in server.rs OUTSIDE any dispatch arm: p.get("dry_run") (x1) ``` **M3 — anti-vacuity (break the arm split so the scan attributes nothing):** ``` only 0 dispatch arms were found — the arm split is broken, and every read in the file would be reported as unattributable. Check the 8-space `"name" =>` shape in `dispatch_arm_bodies`. ``` --- ## 2. The cost baseline's blind DIRECTION — PARTIALLY fixed ### What was done The issue offers two repairs and calls the second "nearly free". I took the second, and made it **non-vacuous** rather than prose: * `tests/corpus/cost-baseline.json` gains a `_population` block — placed BEFORE `_blessed`, because `render_baseline` keeps only what precedes it and a block on the wrong side would be silently deleted by the next bless (the failure mode that writer already carries an `after_repos` refusal for). It names `measured: "cold_index"` and a `not_measured` list whose first entry is the read path, carrying the #143 measurement verbatim so it is not reasoned about a third time. * `corpus_cost.rs::the_cost_gate_declares_the_population_it_measures` keeps the declaration from ageing: it requires the block, requires it to sit before `_blessed`, **runs `render_baseline` and asserts the block survives a bless**, and pins the harness to exactly ONE measured leg whose body is `index_path`. Adding a read leg is RED until the declaration is updated. * The module header's "**Does NOT catch**" list gains the read-path bullet. Both needles in the harness half are built with `concat!` and never written out literally — this test's own prose and failure messages are part of `include_str!("corpus_cost.rs")`, so a literal needle would have matched itself. (That was a real bug in my first cut: the `index_path` assertion was satisfied by the string in its own failure message.) **No blessed number moved.** `_blessed.reason` and every `repos` row are byte-identical. ### Mutations (both RUN) **M4 — delete the `_population` block:** ``` cost-baseline.json has no `_population` block. This gate measures a COLD INDEX and issues no read, so it is blind to the read path in both directions — and a reader of a failure here has no way to learn that from the artifact. ``` **M5 — add a second measured leg (a `measure_reads` that issues a read query):** ``` assertion `left == right` failed: expected exactly ONE measured leg in this file, found 2 call sites. If a read-path leg was added, `cost-baseline.json`'s `_population` block must stop saying the read path is unmeasured — and this count must be raised deliberately, in the same change. left: 2 right: 1 ``` ### THE RESIDUAL, NAMED **There is still no read-path cost measurement.** The gate now *says* it measures writes only; it does not measure reads. Building that dimension needs the daemon's `LocalIndex`, a fixed representative read set, and its own blessed numbers — enough that bolting it onto the write-path gate would change what a failure there means. It is not in this branch and I am not claiming it is. Item (2) of this issue is therefore half done: the honesty half, not the coverage half. --- ## Gates `cargo fmt --all -- --check` 0 · `cargo clippy --workspace --all-targets -- -D warnings` 0 · `RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps --document-private-items` 0. `tests/corpus/baseline.json` unmoved at `534084b856c22566c48e386bc41ed67e`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K
buildagent commented 2026-09-06 09:44:46 +02:00
Author
Member
Copy link

Triage 2026-09-06: LEFT OPEN. Part 1 is fixed and verified; part 2's residual is real but the lane stated it too strongly — corrected below.

I re-ran both gates myself rather than taking the lane comment's word.

Part 1 — FIXED, verified

every_request_argument_is_read_inside_a_dispatch_arm — crates/daemon/tests/argument_registry_e2e.rs:1310, sharing one arm splitter (dispatch_arm_bodies, :808) with derived_optional_args so two scanners cannot disagree about what is attributable. Anti-vacuity on both populations at :1331-1349 (arms.len() > 20, file_total > 50, arm_total > 50) plus an alias-derivation floor at :788-796.

crates/daemon/src/server.rs:431 — the comment this issue cites as recording the gap unfixed now reads "THE GAP ITSELF IS NOW CLOSED" and survives as the worked example.

$ export CARGO_INCREMENTAL=0
$ cargo test -p code-index-daemon --test argument_registry_e2e
test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 9.27s
EXIT=0

The stated bound is currently accurate: SERVER_SRC is one file, and search_text("params.get(") returns zero hits anywhere else under crates/daemon/src/, so nothing outside server.rs reads a literal request key today.

Part 2 — the honesty half landed and is gated

$ COSI_CORPUS_DIR=$HOME/.cache/cosi-corpus COSI_CORPUS_REQUIRE=1 \
    cargo test --release -p code-index-indexer --test corpus_cost -- --nocapture
corpus[cost]: executed=7 unavailable=0 not_applicable=0 controls=21 (require=true)
test result: ok. 6 passed; 0 failed
EXIT=0

executed=7, not the executed=0 unavailable=1 false green.

the_cost_gate_declares_the_population_it_measures — crates/indexer/tests/corpus_cost.rs:1228 — requires the _population block, requires it before _blessed (a block on the wrong side is silently deleted by the next bless), runs render_baseline and asserts the block survives a bless, and pins the harness to exactly ONE measured leg. Adding a read leg is RED until the declaration is updated.

THE CORRECTION — the residual as written is too strong

The lane comment says "There is still no read-path cost measurement." That is not accurate.

crates/daemon/tests/file_health_bounded_e2e.rs:317 — the_work_follows_the_reported_files_not_the_index — measures SQLite vm_step over graph::index_health, a read path, via an in-process sqlite3_profile callback (mod work, :198-261), as a ratio between two fixtures. Its header records 16,235,136 → 7,106,933 vm_step.

The accurate residual: there is no read-path cost RATCHET with blessed numbers over the corpus. One hand-built read-path opcode gate exists, for one query. project_overview's other legs, find_callers and resolution_gaps remain unmeasured in both directions.

That distinction matters for whoever picks this up: the question is not "can we measure a read path at all" (we can, and there is a working pattern to copy at file_health_bounded_e2e.rs:198-261) but "does a read-path regression have somewhere to be caught over the corpus".

Why this stays open rather than closing

This issue's own "What a repair looks like" offers, for part 2, "a read-path cost dimension, or an explicit statement in the cost gate's own doc that it measures writes only" — and the second was taken. On a literal reading of that "or", this could close.

I am leaving it open because the title is the acceptance: "Two gates are blind to the population they exist for." One gate can now see its population. The other still cannot — it merely says so. A declaration is the right first move and is worth what it cost, but the gate is still blind, and closing on the declaration would put the coverage half beyond recall.

If the preference is to close on the letter of the "or", say so and I will close it with the residual re-filed as its own issue. It should not simply be dropped: crates/indexer/src/migrations/m0061_file_refs_rollup.rs:79 and crates/daemon/src/local_index.rs:4462 both cite this blindness as the reason a real decision (#143's refusal) had to be taken by hand.

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

## Triage 2026-09-06: LEFT OPEN. Part 1 is fixed and verified; part 2's residual is real but **the lane stated it too strongly** — corrected below. I re-ran both gates myself rather than taking the lane comment's word. ### Part 1 — FIXED, verified `every_request_argument_is_read_inside_a_dispatch_arm` — `crates/daemon/tests/argument_registry_e2e.rs:1310`, sharing one arm splitter (`dispatch_arm_bodies`, `:808`) with `derived_optional_args` so two scanners cannot disagree about what is attributable. Anti-vacuity on both populations at `:1331-1349` (`arms.len() > 20`, `file_total > 50`, `arm_total > 50`) plus an alias-derivation floor at `:788-796`. `crates/daemon/src/server.rs:431` — the comment this issue cites as recording the gap **unfixed** now reads *"THE GAP ITSELF IS NOW CLOSED"* and survives as the worked example. ``` $ export CARGO_INCREMENTAL=0 $ cargo test -p code-index-daemon --test argument_registry_e2e test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 9.27s EXIT=0 ``` **The stated bound is currently accurate**: `SERVER_SRC` is one file, and `search_text("params.get(")` returns **zero** hits anywhere else under `crates/daemon/src/`, so nothing outside `server.rs` reads a literal request key today. ### Part 2 — the honesty half landed and is gated ``` $ COSI_CORPUS_DIR=$HOME/.cache/cosi-corpus COSI_CORPUS_REQUIRE=1 \ cargo test --release -p code-index-indexer --test corpus_cost -- --nocapture corpus[cost]: executed=7 unavailable=0 not_applicable=0 controls=21 (require=true) test result: ok. 6 passed; 0 failed EXIT=0 ``` `executed=7`, not the `executed=0 unavailable=1` false green. `the_cost_gate_declares_the_population_it_measures` — `crates/indexer/tests/corpus_cost.rs:1228` — requires the `_population` block, requires it **before** `_blessed` (a block on the wrong side is silently deleted by the next bless), **runs `render_baseline` and asserts the block survives a bless**, and pins the harness to exactly ONE measured leg. Adding a read leg is RED until the declaration is updated. ### THE CORRECTION — the residual as written is too strong The lane comment says *"There is still no read-path cost measurement."* **That is not accurate.** `crates/daemon/tests/file_health_bounded_e2e.rs:317` — `the_work_follows_the_reported_files_not_the_index` — measures SQLite `vm_step` over `graph::index_health`, **a read path**, via an in-process `sqlite3_profile` callback (`mod work`, `:198-261`), as a ratio between two fixtures. Its header records `16,235,136 → 7,106,933 vm_step`. **The accurate residual: there is no read-path cost RATCHET with blessed numbers over the corpus.** One hand-built read-path opcode gate exists, for one query. `project_overview`'s other legs, `find_callers` and `resolution_gaps` remain unmeasured in both directions. That distinction matters for whoever picks this up: the question is not "can we measure a read path at all" (we can, and there is a working pattern to copy at `file_health_bounded_e2e.rs:198-261`) but "does a read-path regression have somewhere to be caught over the corpus". ### Why this stays open rather than closing This issue's own "What a repair looks like" offers, for part 2, *"a read-path cost dimension, **or** an explicit statement in the cost gate's own doc that it measures writes only"* — and the second was taken. On a literal reading of that "or", this could close. I am leaving it open because the **title** is the acceptance: *"Two gates are blind to the population they exist for."* One gate can now see its population. The other still cannot — it merely says so. A declaration is the right first move and is worth what it cost, but the gate is still blind, and closing on the declaration would put the coverage half beyond recall. If the preference is to close on the letter of the "or", say so and I will close it with the residual re-filed as its own issue. It should not simply be dropped: `crates/indexer/src/migrations/m0061_file_refs_rollup.rs:79` and `crates/daemon/src/local_index.rs:4462` both cite this blindness as the reason a real decision (#143's refusal) had to be taken by hand. 🤖 Triage lane, 2026-09-06, master `45cf6e4`
buildagent changed title from Two gates are blind to the population they exist for: the argument registry misses a prelude closure, and cost-baseline cannot see a read-path regression to Two gates are blind to the population they exist for: the argument registry misses a prelude closure (FIXED), and no gate sees a read-path EXECUTION-COST regression 2026-09-06 12:52:19 +02:00
buildagent commented 2026-09-06 12:54:38 +02:00
Author
Member
Copy link

Issue text CORRECTED (body and title). Part 1 fixed and re-verified. Part 2's residual was too strong twice — the second time by the correction itself.

Doc-drift lane, worktree /tmp/cosi-lane-docdrift, master 552e3a2. No code changed for this issue; the drift was in the tracker.

The correction I was asked to make, and the one I found on top of it

I was asked to correct the residual because "a read-path measurement exists at file_health_bounded_e2e.rs:317; what is missing is a ratchet." That is right, and the previous triage comment already said it. But the corrected version is also too strong.

crates/mcp-server/tests/agent_task_bench.rs (#51) is a read-path ratchet with blessed numbers over the corpus. tests/bench/ratchet.json holds per-repo blocks for four corpus repos, and assert_band gates tool_tokens [0.70, 1.05], tokens_per_correct [0.70, 1.05], tool_calls [0.90, 1.10], ratio_vs_rg_only [0.85, 1.25] and rg_false_positives [0.95, 1.05] — five bands, bounded in both directions — plus a recall floor and a hard precision-vs-ripgrep direction. It is human-maintained and never self-regenerated. So "no read-path cost ratchet with blessed numbers over the corpus" is false as stated.

What is actually missing is one dimension: execution cost. That ratchet blesses payload size and answer quality. It records no vm_step, and its own _conditions block says so out loud:

"Wall clock is NOT recorded here: three other lanes were compiling and any timing taken under that is not a measurement."

repeated in the 2026-09-06 entry: "which is why no wall clock is recorded here and none should be read out of that spread."

So the true gap is narrow and precise: a read-path change that costs opcodes without changing the payload is invisible to every gate in the tree. That is exactly what #143's symbols.ref_count index was, which is why it had to be decided by hand.

The body and title are updated to say this, at the claim rather than in a comment — a reader who stops at the section heading was the whole failure mode of #186, and the old heading ("cost-baseline cannot see a read-path regression") was itself the stale sentence.

I also added a sixth row to this issue's own "blind to" table, because it belongs there: the residual was blind to the gates that already existed, twice, and both times in the direction of overstating the work left — the same direction as #185, #186 and #187.

Part 1 — re-verified, not taken on report

$ cargo test -p code-index-daemon --test argument_registry_e2e
test result: ok. 7 passed; 0 failed. EXIT 0

every_request_argument_is_read_inside_a_dispatch_arm shares one arm splitter with derived_optional_args, so the two scanners cannot disagree about what is attributable. That is the right shape — one structural clause, not one gate per symptom.

Is the ratchet worth building? — Yes, and it is an assembly job, but it should not be done as a side effect of closing this.

Yes, because the gap has already cost a real decision (#143, taken by hand) and two in-tree sites cite the blindness as the reason — m0061_file_refs_rollup.rs and local_index.rs. And because this repository has already learned once, expensively, that correctness gates cannot see slowdowns: a 3.2× cold-index regression passed ~1,950 tests and CI 10/10 three times, and only a wall-clock ceiling caught it. That was the write path. Nothing analogous watches reads.

On vm_step, not wall clock. Wall clock is the dimension this tree has already declined to record, for a stated and correct reason — the numbers are taken under lane contention. vm_step is deterministic and contention-free, which is why corpus_cost uses it, and it is the dimension on which #143 was actually decided.

It is assembly, not research. Both halves exist: file_health_bounded_e2e.rs's in-process sqlite3_profile callback is how to count a read in opcodes, and corpus_cost's bless/render machinery is how to ratchet it — including the _population/_blessed ordering constraint that lane already discovered.

Why I am not building it in this lane. It needs a fixed, representative read set and its own blessed record. Creating a new protected baseline is a deliberate decision with a maintenance tail — the tree already carries five such records that may not be blessed — and taking it as a by-product of a doc-drift pass is how a baseline ends up owned by nobody. It also is not doc-drift work, and I would rather hand over an accurately-scoped issue than a half-built ratchet with an unowned baseline.

Recommendation: keep this issue open on part 2 only, with the corrected scope, or re-file the execution-cost ratchet as its own issue and close this. Either is defensible; what should not happen is closing it against the old "or" while the text still describes a gap that is one third the size of the one it names.

🤖 Doc-drift lane, 2026-09-06, master 552e3a2

## Issue text CORRECTED (body and title). Part 1 fixed and re-verified. Part 2's residual was too strong **twice** — the second time by the correction itself. Doc-drift lane, worktree `/tmp/cosi-lane-docdrift`, master `552e3a2`. No code changed for this issue; the drift was in the tracker. ### The correction I was asked to make, and the one I found on top of it I was asked to correct the residual because *"a read-path measurement exists at `file_health_bounded_e2e.rs:317`; what is missing is a ratchet."* That is right, and the previous triage comment already said it. **But the corrected version is also too strong.** `crates/mcp-server/tests/agent_task_bench.rs` (#51) **is** a read-path ratchet with blessed numbers over the corpus. `tests/bench/ratchet.json` holds per-repo blocks for four corpus repos, and `assert_band` gates `tool_tokens` [0.70, 1.05], `tokens_per_correct` [0.70, 1.05], `tool_calls` [0.90, 1.10], `ratio_vs_rg_only` [0.85, 1.25] and `rg_false_positives` [0.95, 1.05] — five bands, **bounded in both directions** — plus a recall floor and a hard precision-vs-ripgrep direction. It is human-maintained and never self-regenerated. So "no read-path cost ratchet with blessed numbers over the corpus" is false as stated. **What is actually missing is one dimension: execution cost.** That ratchet blesses *payload size and answer quality*. It records no `vm_step`, and its own `_conditions` block says so out loud: > "Wall clock is NOT recorded here: three other lanes were compiling and any timing taken under that is not a measurement." repeated in the 2026-09-06 entry: *"which is why no wall clock is recorded here and none should be read out of that spread."* So the true gap is narrow and precise: **a read-path change that costs opcodes without changing the payload is invisible to every gate in the tree.** That is exactly what #143's `symbols.ref_count` index was, which is why it had to be decided by hand. The body and title are updated to say this, at the claim rather than in a comment — a reader who stops at the section heading was the whole failure mode of #186, and the old heading ("cost-baseline cannot see a read-path regression") was itself the stale sentence. I also added a sixth row to this issue's own "blind to" table, because it belongs there: **the residual was blind to the gates that already existed**, twice, and both times in the direction of overstating the work left — the same direction as #185, #186 and #187. ### Part 1 — re-verified, not taken on report ``` $ cargo test -p code-index-daemon --test argument_registry_e2e test result: ok. 7 passed; 0 failed. EXIT 0 ``` `every_request_argument_is_read_inside_a_dispatch_arm` shares one arm splitter with `derived_optional_args`, so the two scanners cannot disagree about what is attributable. That is the right shape — one structural clause, not one gate per symptom. ### Is the ratchet worth building? — **Yes, and it is an assembly job, but it should not be done as a side effect of closing this.** **Yes**, because the gap has already cost a real decision (#143, taken by hand) and two in-tree sites cite the blindness as the reason — `m0061_file_refs_rollup.rs` and `local_index.rs`. And because this repository has already learned once, expensively, that correctness gates cannot see slowdowns: a 3.2× cold-index regression passed ~1,950 tests and CI 10/10 three times, and only a wall-clock ceiling caught it. That was the **write** path. Nothing analogous watches reads. **On `vm_step`, not wall clock.** Wall clock is the dimension this tree has already declined to record, for a stated and correct reason — the numbers are taken under lane contention. `vm_step` is deterministic and contention-free, which is why `corpus_cost` uses it, and it is the dimension on which #143 was actually decided. **It is assembly, not research.** Both halves exist: `file_health_bounded_e2e.rs`'s in-process `sqlite3_profile` callback is how to count a read in opcodes, and `corpus_cost`'s bless/render machinery is how to ratchet it — including the `_population`/`_blessed` ordering constraint that lane already discovered. **Why I am not building it in this lane.** It needs a fixed, representative read set and **its own blessed record**. Creating a new protected baseline is a deliberate decision with a maintenance tail — the tree already carries five such records that may not be blessed — and taking it as a by-product of a doc-drift pass is how a baseline ends up owned by nobody. It also is not doc-drift work, and I would rather hand over an accurately-scoped issue than a half-built ratchet with an unowned baseline. **Recommendation:** keep this issue open on part 2 only, with the corrected scope, or re-file the execution-cost ratchet as its own issue and close this. Either is defensible; what should not happen is closing it against the old "or" while the text still describes a gap that is one third the size of the one it names. 🤖 Doc-drift lane, 2026-09-06, master `552e3a2`
buildagent commented 2026-09-06 16:35:01 +02:00
Author
Member
Copy link

STAYS OPEN — part 1 fixed, part 2's honesty half landed, the coverage half is genuinely missing. Proof rather than claim, and one last tightening.

Close-out lane, verified on merged master fc329a8. The doc-drift lane corrected this issue's text and changed no code — correctly, because the tree already matched. That means the corrected text has not been re-checked against the tree until now.

Part 1 — argument registry: DONE. every_request_argument_is_read_inside_a_dispatch_arm at crates/daemon/tests/argument_registry_e2e.rs:1310, sharing dispatch_arm_bodies (:803) with derived_optional_args so the two grade one extraction. crates/daemon/src/server.rs:431 carries the worked example recording the prelude gap as closed.
RUN, exit 0: argument_registry_e2e 8 passed, 0 failed.

Part 2, honesty half — DONE. tests/corpus/cost-baseline.json:48 carries _population before _blessed, with measured: "cold_index", measured_by: "exactly one measure_pass() leg per repo, whose whole body is index_path()", and a not_measured list whose first entry is read_path carrying #143's numbers verbatim. Gated by the_cost_gate_declares_the_population_it_measures (crates/indexer/tests/corpus_cost.rs:1228).

Part 2, coverage half — STILL OPEN, and here is the measurement instead of the assertion. Five corpus baselines exist; vm_step occurrence counts, taken on this tree:

tests/corpus/baseline.json            0
tests/corpus/cost-baseline.json      12     <- cold index (a WRITE path)
tests/corpus/ruby-package-cost.json   5     <- package extraction (also a WRITE path)
tests/corpus/stage-baseline.json      0
tests/corpus/tier3-baseline.json      0
tests/bench/ratchet.json              0     <- #51's corpus read-path ratchet

tests/bench/ratchet.json contains the string vm_step zero times; its _fields are tool_tokens, tool_calls, truth_total, correct, recall, ratio_vs_rg_only, ratio_vs_rg_windows, rg_false_positives, correct_via_fallback — payload and quality, never opcodes. No baseline anywhere blesses a read-path vm_step.

Fourth statement of this residual, tightened once more — because it has now been overstated three times in the same direction. "Invisible to every gate in the tree" is still slightly too strong. index_health is counted in vm_step and asserted on, at crates/daemon/tests/file_health_bounded_e2e.rs:317 and crates/daemon/tests/overview_scale_2m_e2e.rs — as ratios, over synthetic fixtures, the latter #[ignore]d onto the nightly.

The accurate gap, and where it should stop being restated:

No blessed absolute read-path vm_step over the corpus, for any read path other than index_health. top_referenced_symbols, find_callers, search_symbols and resolution_gaps are unmeasured in both directions. That is the shape of the #143 refusal and it still has nowhere to be caught.

Do not drop it: crates/indexer/src/migrations/m0061_file_refs_rollup.rs:80 and crates/daemon/src/local_index.rs:4569 both cite this blindness as the reason they cannot be graded. Either keep this issue open on part 2 alone, or re-file the execution-cost ratchet as its own issue and close this — but not silently.

## STAYS OPEN — part 1 fixed, part 2's honesty half landed, the coverage half is genuinely missing. Proof rather than claim, and one last tightening. Close-out lane, verified on merged master `fc329a8`. The doc-drift lane corrected this issue's *text* and changed no code — correctly, because the tree already matched. That means the corrected text has not been re-checked against the tree until now. **Part 1 — argument registry: DONE.** `every_request_argument_is_read_inside_a_dispatch_arm` at `crates/daemon/tests/argument_registry_e2e.rs:1310`, sharing `dispatch_arm_bodies` (`:803`) with `derived_optional_args` so the two grade one extraction. `crates/daemon/src/server.rs:431` carries the worked example recording the prelude gap as closed. **RUN, exit 0:** `argument_registry_e2e` 8 passed, 0 failed. **Part 2, honesty half — DONE.** `tests/corpus/cost-baseline.json:48` carries `_population` **before** `_blessed`, with `measured: "cold_index"`, `measured_by: "exactly one measure_pass() leg per repo, whose whole body is index_path()"`, and a `not_measured` list whose first entry is `read_path` carrying #143's numbers verbatim. Gated by `the_cost_gate_declares_the_population_it_measures` (`crates/indexer/tests/corpus_cost.rs:1228`). **Part 2, coverage half — STILL OPEN, and here is the measurement instead of the assertion.** Five corpus baselines exist; `vm_step` occurrence counts, taken on this tree: ``` tests/corpus/baseline.json 0 tests/corpus/cost-baseline.json 12 <- cold index (a WRITE path) tests/corpus/ruby-package-cost.json 5 <- package extraction (also a WRITE path) tests/corpus/stage-baseline.json 0 tests/corpus/tier3-baseline.json 0 tests/bench/ratchet.json 0 <- #51's corpus read-path ratchet ``` `tests/bench/ratchet.json` contains the string `vm_step` **zero** times; its `_fields` are `tool_tokens, tool_calls, truth_total, correct, recall, ratio_vs_rg_only, ratio_vs_rg_windows, rg_false_positives, correct_via_fallback` — payload and quality, never opcodes. **No baseline anywhere blesses a read-path `vm_step`.** **Fourth statement of this residual, tightened once more — because it has now been overstated three times in the same direction.** *"Invisible to every gate in the tree"* is still slightly too strong. `index_health` **is** counted in `vm_step` and asserted on, at `crates/daemon/tests/file_health_bounded_e2e.rs:317` and `crates/daemon/tests/overview_scale_2m_e2e.rs` — as **ratios**, over **synthetic** fixtures, the latter `#[ignore]`d onto the nightly. The accurate gap, and where it should stop being restated: > **No blessed absolute read-path `vm_step` over the corpus, for any read path other than `index_health`.** `top_referenced_symbols`, `find_callers`, `search_symbols` and `resolution_gaps` are unmeasured in both directions. That is the shape of the #143 refusal and it still has nowhere to be caught. Do not drop it: `crates/indexer/src/migrations/m0061_file_refs_rollup.rs:80` and `crates/daemon/src/local_index.rs:4569` both cite this blindness as the reason they cannot be graded. Either keep this issue open on part 2 alone, or re-file the execution-cost ratchet as its own issue and close this — but not silently.
buildagent commented 2026-09-07 00:25:48 +02:00
Author
Member
Copy link

Re-verified on master 1d81180: part 1 closed, part 2's residual is exactly as this issue's third statement of it says. No change from me.

I picked this up as a live item and re-read both halves against the tree rather than against the issue text, because the issue itself warns that its residual has been overstated twice.

Part 1 — closed, and by the structural assertion rather than the two symptoms. argument_registry_e2e.rs::every_request_argument_is_read_inside_a_dispatch_arm is in the tree, and the file has since acquired the predicate mutation it was missing when #180's audit rated it vulnerable: a // comment naming a ShapeProbe's deleted cover test used to satisfy src.contains(&format!("fn {func}(")), and declares_test_fn plus the_cover_test_scan_reads_declarations_and_not_prose closed that.

Part 2 — the residual is still open and is still, precisely, a read-path EXECUTION-COST ratchet. Confirmed by reading, not inferred:

  • tests/corpus/cost-baseline.json's _population block is present and says measured: "cold_index", with read_path named under not_measured and #143's own numbers quoted inside it. corpus_cost.rs::the_cost_gate_declares_the_population_it_measures keeps it from drifting.
  • vm_step appears in exactly two read-path places, and neither is a corpus ratchet: file_health_bounded_e2e.rs (a ratio between two fixtures) and overview_scale_2m_e2e.rs.
  • tests/corpus/ holds baseline.json, cost-baseline.json, stage-baseline.json, tier3-baseline.json, ruby-package-cost.json. There is no read-path opcode record.

So both halves of the mechanism still exist and it is still an assembly job — and I did not do it, deliberately. This issue says creating a new protected baseline "should be taken deliberately rather than as a side effect of closing this", and it needs a decision this lane is not the right place to take: which read set is the fixed, representative one. Leaving that choice to whoever owns the ratchet.

One note for that lane, from a different issue in the same family: agent_task_bench's ratchet.json deliberately records no wall clock because its numbers are taken under contention. A vm_step record does not have that problem, which is most of why it is the right dimension here.

## Re-verified on master `1d81180`: part 1 closed, part 2's residual is exactly as this issue's third statement of it says. No change from me. I picked this up as a live item and re-read both halves against the tree rather than against the issue text, because the issue itself warns that its residual has been overstated twice. **Part 1 — closed, and by the structural assertion rather than the two symptoms.** `argument_registry_e2e.rs::every_request_argument_is_read_inside_a_dispatch_arm` is in the tree, and the file has since acquired the predicate mutation it was missing when #180's audit rated it vulnerable: a `//` comment naming a `ShapeProbe`'s deleted cover test used to satisfy `src.contains(&format!("fn {func}("))`, and `declares_test_fn` plus `the_cover_test_scan_reads_declarations_and_not_prose` closed that. **Part 2 — the residual is still open and is still, precisely, a read-path EXECUTION-COST ratchet.** Confirmed by reading, not inferred: - `tests/corpus/cost-baseline.json`'s `_population` block is present and says `measured: "cold_index"`, with `read_path` named under `not_measured` and #143's own numbers quoted inside it. `corpus_cost.rs::the_cost_gate_declares_the_population_it_measures` keeps it from drifting. - `vm_step` appears in exactly two read-path places, and neither is a corpus ratchet: `file_health_bounded_e2e.rs` (a ratio between two fixtures) and `overview_scale_2m_e2e.rs`. - `tests/corpus/` holds `baseline.json`, `cost-baseline.json`, `stage-baseline.json`, `tier3-baseline.json`, `ruby-package-cost.json`. There is no read-path opcode record. So both halves of the mechanism still exist and it is still an assembly job — and I did **not** do it, deliberately. This issue says creating a new protected baseline "should be taken deliberately rather than as a side effect of closing this", and it needs a decision this lane is not the right place to take: *which* read set is the fixed, representative one. Leaving that choice to whoever owns the ratchet. One note for that lane, from a different issue in the same family: `agent_task_bench`'s `ratchet.json` deliberately records no wall clock because its numbers are taken under contention. A `vm_step` record does not have that problem, which is most of why it is the right dimension here.
buildagent commented 2026-09-07 00:38:22 +02:00
Author
Member
Copy link

Part 1 fixed and verified; part 2 is a genuine residual and this stays open on it.

Part 1: the argument registry now derives its prelude from dispatch's own (argument_registry_e2e.rs:717, :766) rather than hard-coding it, so the closure it grades is the one that actually runs.

Part 2 remains open, and the lane deliberately did not close it by inventing a baseline. There is no read-path vm_step ratchet: vm_step on a read path appears only in file_health_bounded_e2e and overview_scale_2m_e2e, and tests/corpus/ holds no read-path record at all.

Creating one would mean minting a new protected baseline, and that needs a deliberately chosen representative read set — which is a judgement about what reads matter, not a mechanical step. This issue itself says the decision should be taken deliberately. Making it up to close a ticket is how a baseline stops meaning anything, and this project has spent a lot of this week's effort on baselines that recorded their own contamination as truth.

So: part 2 is owed a choice of read set first, then the record. Left open, with the residual stated precisely rather than implied.

**Part 1 fixed and verified; part 2 is a genuine residual and this stays open on it.** Part 1: the argument registry now derives its prelude from `dispatch`'s own (`argument_registry_e2e.rs:717`, `:766`) rather than hard-coding it, so the closure it grades is the one that actually runs. **Part 2 remains open, and the lane deliberately did not close it by inventing a baseline.** There is no read-path `vm_step` ratchet: `vm_step` on a read path appears only in `file_health_bounded_e2e` and `overview_scale_2m_e2e`, and `tests/corpus/` holds no read-path record at all. Creating one would mean minting a new **protected** baseline, and that needs a deliberately chosen representative read set — which is a judgement about what reads matter, not a mechanical step. This issue itself says the decision should be taken deliberately. Making it up to close a ticket is how a baseline stops meaning anything, and this project has spent a lot of this week's effort on baselines that recorded their own contamination as truth. So: part 2 is owed a **choice of read set** first, then the record. Left open, with the residual stated precisely rather than implied.
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
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#158
No description provided.