Five registries were CONFIRMED blind by mutation and four have no tracker: pool_capability, resource_grading, exec_copy and shipped_binary are still green under the mutations that should redden them #178

New issue

Closed

opened 2026-09-06 02:41:28 +02:00 by buildagent · 3 comments

buildagent commented 2026-09-06 02:41:28 +02:00

Member

Copy link

This is the sharpest finding of the #45.6 round and it is not tied to any one tool defect. Filed on its own so the class is on record and the audit it implies can be scheduled.

What happened

bless_registry exists to check that every registered bless switch routes through the shared projection::bless_verdict, so that all six of #45's refusals apply to all six artifacts rather than to one.

Its routing check asked:

src.contains("bless_verdict")

Every compliant owner defines a local wrapper of exactly that name — deliberately, so that each suite's unit arms read as assertions about its gate:

fn bless_verdict(claim: &BlessClaim<'_>) -> Result<BlessProof, String> {
    verdict(SWITCH, claim)
}

So the string was present whether or not the body delegated. The check was satisfied by the wrapper it was supposed to look through.

Measured, not argued

I replaced corpus_tier3_ratchet's wrapper body with a weaker inline bar (any non-empty reason) that reached the shared verdict only with a claim it fabricated:

bless_registry          test result: ok. 4 passed; 0 failed
corpus_tier3_ratchet    test result: ok. 3 passed; 0 failed        # exit 0

The whole tree stayed green. COSI_TIER3_BLESS would have accepted a one-character reason, an empty categorised diff, no controls, a shrunken universe and a degraded resolver, and nothing in the workspace would have said so.

That is the worst shape a gate can have: it is not merely weak, it reports compliance for the exact state it was built to catch, and it does so more confidently the more idiomatic the offending code looks.

Why the ordinary defences did not help

• The registry had its own anti-vacuity check that it scanned a plausible number of files — and it did. The population was right; the predicate was satisfied by the wrong thing.
• Its declared mutations were run and were RED. They mutated the registry data (add an unregistered switch, delete a registered one), not the routing predicate. A mutation set that never perturbs the predicate cannot discover that the predicate is vacuous.
• Every one of the four suites was green, and four green suites reading one shared verdict is exactly the evidence you would cite for "the mechanism is shared".

The fix, and why it needed two halves

1. delegates_to_the_shared_verdict(src) — strips // comments, then requires a reference to the shared item (projection::bless_verdict, or its use … as alias). A local definition cannot produce either. Graded in both directions by a new the_delegation_detector_can_fail; making it return true; reddens with "a file that only SPELLS the name was read as delegating, which is the vacuity this predicate exists to remove".
2. A behavioural arm in corpus_tier3_ratchet — a blessable claim, then one field varied per refusal, asserting COSI_TIER3_BLESS is the switch named in the refusal. Because a lexical gate structurally cannot see whether a body calls what its file imported. Belt and brace, and the module note that previously argued against repeating the arms is amended to record why that argument was wrong.

After both, weakening a shared refusal reddens all four suites.

The open work, which is why this is an issue and not a commit message

No other registry in this tree was audited for the same shape. The tree has at least: bounding_site_registry, completeness_gate, production_caller_gate, retired_tier_gate, signature_gate, disclosure_derivation_registry, disclosure_surface_registry, reason_code_registry, ref_kind_stance_registry, refusal_stage_registry, resource_grading_registry, shipped_binary_registry, kind_table_guard, lockfile_forge_registry, generation_policy_registry, pool_capability_registry, exec_copy_registry, inline_cargo_build_registry, symbol_id_args_registry, and now resolution_percentage_stance.

The question to ask of each is not "does it scan the right files" — that is the check they all already have. It is:

Is there a way for the offending code to satisfy this predicate? In particular: does the predicate match a name that compliant code and non-compliant code both spell?

Any registry whose predicate is contains(<some identifier>) is a candidate, and the idiom that defeated this one — a thin local wrapper with the same name as the shared item, which is good style — is common in this codebase.

What must NOT be done

• Do not ban local wrappers. They are why each suite's failures name its own switch, and removing them to make a lexical check work would trade real diagnostic quality for a gate's convenience.
• Do not settle for the lexical fix alone. It cannot see a body that imports the shared item and then does not call it. That is what the behavioural arm is for, and any registry with the same shape needs the same pairing.
• Do not treat "its declared mutations were RED" as coverage. All of them were, and the predicate was still vacuous. The mutation that matters for a registry is one that makes non-compliant code look compliant, and it has to be written deliberately because it is not the mutation anyone reaches for.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

This is the sharpest finding of the #45.6 round and it is **not tied to any one tool defect**. Filed on its own so the class is on record and the audit it implies can be scheduled. ## What happened `bless_registry` exists to check that every registered bless switch **routes through the shared `projection::bless_verdict`**, so that all six of #45's refusals apply to all six artifacts rather than to one. Its routing check asked: ```rust src.contains("bless_verdict") ``` **Every compliant owner defines a *local* wrapper of exactly that name** — deliberately, so that each suite's unit arms read as assertions about *its* gate: ```rust fn bless_verdict(claim: &BlessClaim<'_>) -> Result<BlessProof, String> { verdict(SWITCH, claim) } ``` So the string was present whether or not the body delegated. The check was satisfied by the wrapper it was supposed to look through. ## Measured, not argued I replaced `corpus_tier3_ratchet`'s wrapper body with a weaker inline bar (any non-empty reason) that reached the shared verdict only with a claim it fabricated: ``` bless_registry test result: ok. 4 passed; 0 failed corpus_tier3_ratchet test result: ok. 3 passed; 0 failed # exit 0 ``` **The whole tree stayed green.** `COSI_TIER3_BLESS` would have accepted a one-character reason, an empty categorised diff, no controls, a shrunken universe and a degraded resolver, and nothing in the workspace would have said so. That is the worst shape a gate can have: it is not merely weak, it *reports compliance* for the exact state it was built to catch, and it does so more confidently the more idiomatic the offending code looks. ## Why the ordinary defences did not help - The registry had its own anti-vacuity check that it scanned a plausible number of files — and it did. The **population** was right; the **predicate** was satisfied by the wrong thing. - Its declared mutations were run and were RED. They mutated the *registry data* (add an unregistered switch, delete a registered one), not the *routing predicate*. A mutation set that never perturbs the predicate cannot discover that the predicate is vacuous. - Every one of the four suites was green, and four green suites reading one shared verdict is exactly the evidence you would cite for "the mechanism is shared". ## The fix, and why it needed two halves 1. **`delegates_to_the_shared_verdict(src)`** — strips `//` comments, then requires a reference to the **shared item** (`projection::bless_verdict`, or its `use … as` alias). A local definition cannot produce either. Graded in both directions by a new `the_delegation_detector_can_fail`; making it `return true;` reddens with *"a file that only SPELLS the name was read as delegating, which is the vacuity this predicate exists to remove"*. 2. **A behavioural arm in `corpus_tier3_ratchet`** — a blessable claim, then one field varied per refusal, asserting `COSI_TIER3_BLESS` is the switch named in the refusal. Because a lexical gate structurally **cannot** see whether a body calls what its file imported. Belt and brace, and the module note that previously argued against repeating the arms is amended to record why that argument was wrong. After both, weakening a shared refusal reddens all four suites. ## The open work, which is why this is an issue and not a commit message **No other registry in this tree was audited for the same shape.** The tree has at least: `bounding_site_registry`, `completeness_gate`, `production_caller_gate`, `retired_tier_gate`, `signature_gate`, `disclosure_derivation_registry`, `disclosure_surface_registry`, `reason_code_registry`, `ref_kind_stance_registry`, `refusal_stage_registry`, `resource_grading_registry`, `shipped_binary_registry`, `kind_table_guard`, `lockfile_forge_registry`, `generation_policy_registry`, `pool_capability_registry`, `exec_copy_registry`, `inline_cargo_build_registry`, `symbol_id_args_registry`, and now `resolution_percentage_stance`. The question to ask of each is not "does it scan the right files" — that is the check they all already have. It is: > **Is there a way for the offending code to satisfy this predicate?** In particular: does the predicate match a *name* that compliant code and non-compliant code both spell? Any registry whose predicate is `contains(<some identifier>)` is a candidate, and the idiom that defeated this one — a thin local wrapper with the same name as the shared item, which is *good style* — is common in this codebase. ## What must NOT be done - **Do not ban local wrappers.** They are why each suite's failures name its own switch, and removing them to make a lexical check work would trade real diagnostic quality for a gate's convenience. - **Do not settle for the lexical fix alone.** It cannot see a body that imports the shared item and then does not call it. That is what the behavioural arm is for, and any registry with the same shape needs the same pairing. - **Do not treat "its declared mutations were RED" as coverage.** All of them were, and the predicate was still vacuous. The mutation that matters for a registry is one that makes **non-compliant code look compliant**, and it has to be written deliberately because it is not the mutation anyone reaches for. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

buildagent commented 2026-09-06 08:18:41 +02:00

Author

Member

Copy link

The audit this issue asks for: 22 registry/population gates read, 11 rated vulnerable, 5 predicate mutations RUN — 5 confirmed, 0 refuted

Done in a detached worktree at f6a878a. The five measured mutations were each written to make non-compliant code look compliant, per this issue's instruction; none of them is the mutation the gate's own author would have reached for, and each was applied against a paired control that proves the blindness is caused by the thing named and not by the edit being a no-op.

MEASURED — all five stayed GREEN with the invariant violated

gate	the predicate mutation	result
daemon/tests/lockfile_forge_registry.rs	Added a real hand-rolled daemon-payload forge (let payload = format!("root = \"{}\"\n…", root.display())) to mcp-server/src/main.rs's #[cfg(test)] module	1 passed; 0 failed — GREEN
indexer/tests/pool_capability_registry.rs	Deleted {admit_same_file} from symbol_buckets' INSERT and its padmit.join(...) argument, then added one // comment naming both tokens	17 passed; 0 failed — GREEN
mcp-server/tests/resource_grading_registry.rs	Copy-pasted evidence_gaps_for's 74-line body as a second implementation called from grade_resource_body, plus a comment holding the token count at 2	5 passed; 0 failed — GREEN
test-support/tests/exec_copy_registry.rs	Local shadow fn install_executable doing a bare fs::copy, call-site text unchanged	7 passed; 0 failed — GREEN
mcp-server/tests/shipped_binary_registry.rs	Removed the standalone code-index entry from all 12 INSTALL= lines in release.yml	5 passed; 0 failed — GREEN

lockfile_forge_registry is blind today, in its own motivating file. Its exemption hand_escaped = body.contains(r#"replace('\\'"#) is computed over the whole file inside a per-line loop, so one occurrence anywhere blanket-clears every line. crates/mcp-server/src/main.rs:1235 carries that token in a doc comment — the paragraph explaining the original defect — and main.rs is the very file the gate's anti-vacuity assertion singles out to prove the scan reaches src/. The scan reaches it; the predicate then exempts all of it, and 40 files under crates/ are in the same state. Control run (same forge, doc-comment token neutered): RED, naming main.rs:1354. So the doc comment is provably the sole cause.

pool_capability_registry has its own fix sitting one directory away. Its production_source applies only strip_cfg_test; the sibling generation_policy_registry.rs:825 applies strip_line_comments(&strip_cfg_test(&src)) and its doc says so. Same crate, same directory, same helper name, different behaviour — the asymmetry that exposed the original bless defect, again.

resource_grading_registry is the one no runtime arm can ever back up. Two variants were run. Replacing the call with a default value was caught — by behavioural siblings, which saw the changed behaviour, not the duplicated implementation. A faithful copy-paste (the defect #107 forbids: "Not a second implementation") shipped the whole file green. Behavioural arms only fire once a duplicate has drifted; they cannot see the duplication that causes the drift.

The structural signal, which is more useful than any individual finding

The declared-mutation profile predicts vulnerability better than reading the predicates does. Every gate rated vulnerable-and-unbraced declares mutations touching only registry DATA or production SUBJECT. Every gate that survived scrutiny declares at least one mutation of its own predicate. That single question separates the two populations. Suggest making it the review question for any new registry.

Second pattern: negative corpora here are polarity-skewed. Where detector tests exist, their negatives are almost always false-positive controls ("this must NOT be flagged"). The polarity bless_registry added — a corpus holding the non-compliant shape that was measured green — appears in only three files (bless_registry, reason_code_registry, generation_policy_registry).

Third: comment-stripping is applied inconsistently between sibling files and the split is not principled. generation_policy_registry / reason_code_registry strip; pool_capability_registry / disclosure_surface_registry / disclosure_derivation_registry / resource_grading_registry do not.

Source-level (NOT executed) — ranked, each with the concrete mutation

6. production_caller_gate.rs — body.contains("build::build("). Its doc reasons carefully about the false-red direction and never about false-green. Mutation: a nested mod _pipeline_notes { pub mod build { pub fn build() {} } }, or one-line const _WHY: &str = "cmd_enable calls build::build( here"; — a string literal, which strip_line_comments does not touch.
7. argument_registry_e2e.rs — src.contains(&format!("fn {func}(")), no #[test] check. ShapeProbe rows are skipped by the behavioural sweep, so this predicate is all that stands behind them. Mutation: delete the test body, leave /// Superseded. See the notes on fn wire_vintage_probe( in the design record. The file declares no MUTATION (RUN) block anywhere.
8. ref_kind_stance_registry.rs — polarity blindness, not spelling. kinds_named does strip comments (correcting one sub-finding), but code.contains("'binding'") cannot distinguish IN (...) from NOT IN (...). Mutation: delete the word NOT at daemon/src/graph.rs:1237 — every assertion passes while the population has inverted to exactly the kinds the row declares excluded. Six sibling sites take the same one-token edit.
9. disclosure_surface_registry.rs — six rows carry producer: "lang", a 4-character bare substring matching language, lang_id, by_lang, or any comment. Mutation: delete a real disclosure, leave // no language disclosure here.
10. disclosure_derivation_registry.rs — membership itself is decided by region.contains("ACTIVATION_UNAVAILABLE") over an un-stripped corpus. Caught by an e2e for render_count_basis; the same edit in render_link_package_set (one of ~8) is green in both files.
11. doc_citation_gate.rs — the comment filter is //-only. A single /* fn the_shipped_host_cannot_compile_wasm */ at file scope makes the gate's own motivating phantom resolve as a declared item. The string-literal hole is disclosed and priced; this one is not mentioned anywhere.

Also: bounding_site_registry (vulnerable on field_ident_exists, but honestly disclosed, best negative-corpus suite in the tree, and two of its declared mutations genuinely mutate the predicate); inline_cargo_build_registry (vulnerable by shape — .try_exists(), or an early return — but declares and runs a real predicate mutation); refusal_stage_registry (name-based item_is_declared, leans on cargo fmt to hold starts_with("return ") up, but 2 of its 12 mutations are predicate mutations); resolution_percentage_stance (vulnerable only to rebinding, self-disclosed in the failure message, and already carries the full cure).

NOT vulnerable — and these are the models to copy

reason_code_registry (comment/cfg(test)/enum/as_str/const all stripped before matching, word-boundary contains_word, the_scan_itself_can_fail with 2 positives + 4 negatives, three declared scanner-predicate mutations plus a recorded survivor) · plugin_command_registry (text predicate braced by a test that runs the real CLI per row) · symbol_id_args_registry, completeness_gate, retired_tier_gate, signature_gate, tier3_origin_gate, prose_spacing_gate (behavioural) · kind_table_guard, which counts module.imports() on the compiled module and says why: "a text scan for (import would pass on a module whose import arrived some other way." That is this issue's lesson, written down before this issue existed.

Two findings on the fixed exemplar itself

1. bless_registry's own declared mutation is now stale. every_registered_switch_routes_through_the_shared_verdict still says "add bless_verdict to a waivered owner → RED". That wording was written for the OLD src.contains predicate (865e3a7) and survived the fix (b059146) unchanged. Under delegates_to_the_shared_verdict, adding the bare name to ruby_package_cost.rs leaves routes == false and the STALE WAIVER arm green. The mutation as written no longer produces the stated result.
2. must_not_delegate has no string-literal row. The predicate strips // but not string literals, so a refusal message containing projection::bless_verdict would satisfy it. The negative corpus covers local wrapper, //, ///, and empty — not a string.

What I did in this lane, and what I did not

I did not fix the eleven. Each needs its own the_detector_can_fail arm with its own predicate mutation, and bundling them into a workflow-and-bless lane would produce a diff nobody can review. They are recorded above with the exact edit that reproduces each.

I did apply the lesson to the new gate this lane added (ci_cadence::no_grading_step_is_masked_by_an_earlier_one, #169), and the result is worth recording here because it reproduces this issue inside a fresh file: weakening runs_even_after_a_failure to accept any non-empty guard left the scan-over-real-workflows test GREEN — a compliant tree never exercises a weakened predicate — and only the synthetic the_masking_detector_can_fail went red. A scan over real inputs structurally cannot discover that its own predicate has gone vacuous. That is the argument for the paired detector, measured rather than asserted.

Priority if only three are fixed: lockfile_forge_registry (failing now), pool_capability_registry (fix already written in the adjacent file), resource_grading_registry (the only invariant here no runtime arm can ever back up, guarded by a contains whose own comment claims a discriminating property it does not have).

🤖 Generated with Claude Code

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

## The audit this issue asks for: 22 registry/population gates read, 11 rated vulnerable, **5 predicate mutations RUN — 5 confirmed, 0 refuted** Done in a detached worktree at `f6a878a`. The five measured mutations were each written to make **non-compliant code look compliant**, per this issue's instruction; none of them is the mutation the gate's own author would have reached for, and each was applied against a paired *control* that proves the blindness is caused by the thing named and not by the edit being a no-op. ### MEASURED — all five stayed GREEN with the invariant violated | gate | the predicate mutation | result | |---|---|---| | `daemon/tests/lockfile_forge_registry.rs` | Added a real hand-rolled daemon-payload forge (`let payload = format!("root = \"{}\"\n…", root.display())`) to `mcp-server/src/main.rs`'s `#[cfg(test)]` module | `1 passed; 0 failed` — **GREEN** | | `indexer/tests/pool_capability_registry.rs` | Deleted `{admit_same_file}` from `symbol_buckets`' INSERT **and** its `padmit.join(...)` argument, then added one `//` comment naming both tokens | `17 passed; 0 failed` — **GREEN** | | `mcp-server/tests/resource_grading_registry.rs` | Copy-pasted `evidence_gaps_for`'s 74-line body as a second implementation called from `grade_resource_body`, plus a comment holding the token count at 2 | `5 passed; 0 failed` — **GREEN** | | `test-support/tests/exec_copy_registry.rs` | Local shadow `fn install_executable` doing a bare `fs::copy`, call-site text unchanged | `7 passed; 0 failed` — **GREEN** | | `mcp-server/tests/shipped_binary_registry.rs` | Removed the standalone `code-index` entry from all 12 `INSTALL=` lines in `release.yml` | `5 passed; 0 failed` — **GREEN** | **`lockfile_forge_registry` is blind *today*, in its own motivating file.** Its exemption `hand_escaped = body.contains(r#"replace('\\'"#)` is computed over the **whole file** inside a per-line loop, so one occurrence anywhere blanket-clears every line. `crates/mcp-server/src/main.rs:1235` carries that token **in a doc comment** — the paragraph explaining the original defect — and main.rs is the very file the gate's anti-vacuity assertion singles out to prove the scan reaches `src/`. The scan reaches it; the predicate then exempts all of it, and 40 files under `crates/` are in the same state. Control run (same forge, doc-comment token neutered): RED, naming `main.rs:1354`. So the doc comment is provably the sole cause. **`pool_capability_registry` has its own fix sitting one directory away.** Its `production_source` applies only `strip_cfg_test`; the sibling `generation_policy_registry.rs:825` applies `strip_line_comments(&strip_cfg_test(&src))` and its doc says so. Same crate, same directory, same helper name, different behaviour — the asymmetry that exposed the original bless defect, again. **`resource_grading_registry` is the one no runtime arm can ever back up.** Two variants were run. Replacing the call with a default value was caught — by *behavioural siblings*, which saw the changed behaviour, not the duplicated implementation. A faithful copy-paste (the defect #107 forbids: *"Not a second implementation"*) shipped the **whole file green**. Behavioural arms only fire once a duplicate has drifted; they cannot see the duplication that causes the drift. ### The structural signal, which is more useful than any individual finding **The declared-mutation profile predicts vulnerability better than reading the predicates does.** Every gate rated vulnerable-and-unbraced declares mutations touching only registry DATA or production SUBJECT. Every gate that survived scrutiny declares at least one mutation **of its own predicate**. That single question separates the two populations. Suggest making it the review question for any new registry. Second pattern: **negative corpora here are polarity-skewed.** Where detector tests exist, their negatives are almost always false-positive controls ("this must NOT be flagged"). The polarity `bless_registry` added — a corpus holding the non-compliant shape that was *measured green* — appears in only three files (`bless_registry`, `reason_code_registry`, `generation_policy_registry`). Third: **comment-stripping is applied inconsistently between sibling files and the split is not principled.** `generation_policy_registry` / `reason_code_registry` strip; `pool_capability_registry` / `disclosure_surface_registry` / `disclosure_derivation_registry` / `resource_grading_registry` do not. ### Source-level (NOT executed) — ranked, each with the concrete mutation 6. **`production_caller_gate.rs`** — `body.contains("build::build(")`. Its doc reasons carefully about the false-**red** direction and never about false-green. Mutation: a nested `mod _pipeline_notes { pub mod build { pub fn build() {} } }`, or one-line `const _WHY: &str = "cmd_enable calls build::build( here";` — a string literal, which `strip_line_comments` does not touch. 7. **`argument_registry_e2e.rs`** — `src.contains(&format!("fn {func}("))`, no `#[test]` check. `ShapeProbe` rows are *skipped* by the behavioural sweep, so this predicate is all that stands behind them. Mutation: delete the test body, leave `/// Superseded. See the notes on fn wire_vintage_probe( in the design record.` The file declares **no `MUTATION (RUN)` block anywhere**. 8. **`ref_kind_stance_registry.rs`** — polarity blindness, not spelling. `kinds_named` does strip comments (correcting one sub-finding), but `code.contains("'binding'")` cannot distinguish `IN (...)` from `NOT IN (...)`. Mutation: delete the word `NOT` at `daemon/src/graph.rs:1237` — every assertion passes while the population has inverted to exactly the kinds the row declares excluded. Six sibling sites take the same one-token edit. 9. **`disclosure_surface_registry.rs`** — six rows carry `producer: "lang"`, a 4-character bare substring matching `language`, `lang_id`, `by_lang`, or any comment. Mutation: delete a real disclosure, leave `// no language disclosure here`. 10. **`disclosure_derivation_registry.rs`** — membership itself is decided by `region.contains("ACTIVATION_UNAVAILABLE")` over an un-stripped corpus. Caught by an e2e for `render_count_basis`; the same edit in `render_link_package_set` (one of ~8) is green in both files. 11. **`doc_citation_gate.rs`** — the comment filter is `//`-only. A single `/* fn the_shipped_host_cannot_compile_wasm */` at file scope makes the gate's own motivating phantom resolve as a declared item. The string-literal hole is disclosed and priced; this one is not mentioned anywhere. Also: **`bounding_site_registry`** (vulnerable on `field_ident_exists`, but honestly disclosed, best negative-corpus suite in the tree, and two of its declared mutations genuinely mutate the predicate); **`inline_cargo_build_registry`** (vulnerable by *shape* — `.try_exists()`, or an early `return` — but declares and runs a real predicate mutation); **`refusal_stage_registry`** (name-based `item_is_declared`, leans on `cargo fmt` to hold `starts_with("return ")` up, but 2 of its 12 mutations are predicate mutations); **`resolution_percentage_stance`** (vulnerable only to rebinding, self-disclosed in the failure message, and already carries the full cure). ### NOT vulnerable — and these are the models to copy `reason_code_registry` (comment/`cfg(test)`/enum/`as_str`/`const` all stripped before matching, word-boundary `contains_word`, `the_scan_itself_can_fail` with 2 positives + 4 negatives, **three declared scanner-predicate mutations plus a recorded survivor**) · `plugin_command_registry` (text predicate braced by a test that runs the real CLI per row) · `symbol_id_args_registry`, `completeness_gate`, `retired_tier_gate`, `signature_gate`, `tier3_origin_gate`, `prose_spacing_gate` (behavioural) · **`kind_table_guard`**, which counts `module.imports()` on the *compiled* module and says why: *"a text scan for `(import` would pass on a module whose import arrived some other way."* That is this issue's lesson, written down before this issue existed. ### Two findings on the fixed exemplar itself 1. **`bless_registry`'s own declared mutation is now stale.** `every_registered_switch_routes_through_the_shared_verdict` still says *"add `bless_verdict` to a waivered owner → RED"*. That wording was written for the OLD `src.contains` predicate (`865e3a7`) and survived the fix (`b059146`) unchanged. Under `delegates_to_the_shared_verdict`, adding the bare name to `ruby_package_cost.rs` leaves `routes == false` and the STALE WAIVER arm green. The mutation as written no longer produces the stated result. 2. **`must_not_delegate` has no string-literal row.** The predicate strips `//` but not string literals, so a refusal *message* containing `projection::bless_verdict` would satisfy it. The negative corpus covers local wrapper, `//`, `///`, and empty — not a string. ### What I did in this lane, and what I did not I did **not** fix the eleven. Each needs its own `the_detector_can_fail` arm with its own predicate mutation, and bundling them into a workflow-and-bless lane would produce a diff nobody can review. They are recorded above with the exact edit that reproduces each. I did apply the lesson to the **new** gate this lane added (`ci_cadence::no_grading_step_is_masked_by_an_earlier_one`, #169), and the result is worth recording here because it reproduces this issue inside a fresh file: weakening `runs_even_after_a_failure` to accept *any* non-empty guard left the scan-over-real-workflows test **GREEN** — a compliant tree never exercises a weakened predicate — and only the synthetic `the_masking_detector_can_fail` went red. A scan over real inputs structurally cannot discover that its own predicate has gone vacuous. That is the argument for the paired detector, measured rather than asserted. **Priority if only three are fixed:** `lockfile_forge_registry` (failing now), `pool_capability_registry` (fix already written in the adjacent file), `resource_grading_registry` (the only invariant here no runtime arm can ever back up, guarded by a `contains` whose own comment claims a discriminating property it does not have). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

buildagent referenced this issue 2026-09-06 08:27:32 +02:00

from __future__ import … is silently absent from get_dependencies — the python walker has no arm for future_import_statement and nothing in the tree records a decision #176

buildagent referenced this issue 2026-09-06 08:42:50 +02:00

check_rename answers "clean" for a rename that would not compile — nameof(X) is not an edit site and the text backstop is file-level #171

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

The #51 agent-task benchmark has never run in CI when the corpus suites fail: it is a later step in the same job, so its status is unknown rather than passing #169

buildagent referenced this issue 2026-09-06 09:27:07 +02:00

The Windows disk pre-flight blocks CI on a percentage while its own absolute floor passes, and the prune it pairs with cannot free anything #179

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

lockfile_forge_registry is blind TODAY: a doc comment in the one file its anti-vacuity floor names exempts that whole file, so its declared mutation is false as written #180

buildagent commented 2026-09-06 09:31:43 +02:00

Author

Member

Copy link

Filed the first live instance of this class as #180 — lockfile_forge_registry, which is blind today rather than merely capable of blindness. Its whole-file hand_escaped exemption is granted by a /// doc comment at crates/mcp-server/src/main.rs:1235, in the one file its own anti-vacuity floor singles out to prove the scan reaches src/, so its declared mutation ("any scanned source → RED") is false as written. Measured with a control that isolates the doc comment as the sole cause.

Two things from this issue's audit live in #180 rather than here, to keep them next to the worked example:

• The portable rule — the declared-mutation profile predicts vulnerability better than reading the predicates does — plus the confirmation against a gate written in the same lane, where weakening the predicate left the real-workflow scan green and only the synthetic detector red.
• The list of six rated-vulnerable gates that were never mutated, each with the concrete predicate mutation to run. Their status is unknown, not safe: this audit is a floor (11 rated, 5 run), not a census, and the next lane should start from that list rather than re-deriving it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

Filed the first **live** instance of this class as **#180** — `lockfile_forge_registry`, which is blind today rather than merely capable of blindness. Its whole-file `hand_escaped` exemption is granted by a `///` doc comment at `crates/mcp-server/src/main.rs:1235`, in the one file its own anti-vacuity floor singles out to prove the scan reaches `src/`, so its declared mutation (*"any scanned source → RED"*) is **false as written**. Measured with a control that isolates the doc comment as the sole cause. Two things from this issue's audit live in #180 rather than here, to keep them next to the worked example: - **The portable rule** — *the declared-mutation profile predicts vulnerability better than reading the predicates does* — plus the confirmation against a gate written in the same lane, where weakening the predicate left the real-workflow scan green and only the synthetic detector red. - **The list of six rated-vulnerable gates that were never mutated**, each with the concrete predicate mutation to run. Their status is *unknown*, not safe: this audit is a floor (11 rated, 5 run), not a census, and the next lane should start from that list rather than re-deriving it. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

buildagent referenced this issue 2026-09-06 12:06:34 +02:00

lockfile_forge_registry is blind TODAY: a doc comment in the one file its anti-vacuity floor names exempts that whole file, so its declared mutation is false as written #180

buildagent commented 2026-09-06 12:48:58 +02:00

Author

Member

Copy link

STAYING OPEN, NARROWED — the audit is complete; five confirmed-blind gates are still blind on master, and four of them are tracked nowhere else

Close-out lane, master 552e3a2. Title corrected.

Done

The bless_registry fix is on master and graded — the_delegation_detector_can_fail at crates/indexer/tests/bless_registry.rs:468, suite 5/5, EXIT=0. And the audit this issue asked for is finished: 11 registries rated vulnerable, all 11 mutated across two lanes, 11 confirmed / 0 refuted.

Not done — and this is the whole reason the issue must stay open

Five of the confirmed-blind gates are unfixed, and git log -- <file> shows none has been touched since this issue was filed:

gate	last touched
crates/daemon/tests/lockfile_forge_registry.rs	09c9be4 (pre-#178)
crates/indexer/tests/pool_capability_registry.rs	75f6308 (pre-#178)
crates/mcp-server/tests/resource_grading_registry.rs	1aa6514 (pre-#178)
crates/test-support/tests/exec_copy_registry.rs	656666f (pre-#178)
crates/mcp-server/tests/shipped_binary_registry.rs	8e6bcac (pre-#178)

All five pass green today — resource_grading_registry 5/5, shipped_binary_registry 5/5, exec_copy_registry 7/7 — which is the same green they showed under the mutations that should have reddened them. A confirmed-blind gate that is still green is not a finding that has been acted on; it is a finding that has been written down.

Only lockfile_forge_registry has its own tracker (#180). Closing #178 would drop pool_capability_registry, resource_grading_registry, exec_copy_registry and shipped_binary_registry off the board with no issue anywhere — which is exactly the silent disappearance this close-out lane exists to prevent.

Corrected scope

Retitle as above. Strike "no other registry has been audited" — that is discharged. The remaining work is: fix, or split into per-gate trackers, the four blind registries that have no owner, plus lockfile_forge_registry if #180 is not taken first.

Residuals the implementing lane named, recorded here so they are not lost

• disclosure_surface_registry's produces is still a spelling — fn search_text's lang parameter alone satisfies one row.
• kind_polarity leaves SQL shapes outside its four classes unclassified: 21 sites classify against a floor of 10.
• Two COSI_E2E_LEG=daemon e2e failures with one signature on different tests per run (index_coverage_facts_e2e::a_refused_file_is_not_reported_as_indexed_and_current, activation_offer_e2e::an_unconsultable_store_is_never_rendered_as_nothing_to_activate), both passing in isolation — reported as a fixture-readiness race, not blessed. That is #192.

## STAYING OPEN, NARROWED — the audit is complete; **five confirmed-blind gates are still blind on master**, and four of them are tracked nowhere else Close-out lane, master `552e3a2`. **Title corrected.** ### Done The `bless_registry` fix is on master and graded — `the_delegation_detector_can_fail` at `crates/indexer/tests/bless_registry.rs:468`, suite 5/5, **EXIT=0**. And the audit this issue asked for is **finished**: 11 registries rated vulnerable, all 11 mutated across two lanes, **11 confirmed / 0 refuted**. ### Not done — and this is the whole reason the issue must stay open Five of the confirmed-blind gates are **unfixed**, and `git log -- <file>` shows none has been touched since this issue was filed: | gate | last touched | |---|---| | `crates/daemon/tests/lockfile_forge_registry.rs` | `09c9be4` (pre-#178) | | `crates/indexer/tests/pool_capability_registry.rs` | `75f6308` (pre-#178) | | `crates/mcp-server/tests/resource_grading_registry.rs` | `1aa6514` (pre-#178) | | `crates/test-support/tests/exec_copy_registry.rs` | `656666f` (pre-#178) | | `crates/mcp-server/tests/shipped_binary_registry.rs` | `8e6bcac` (pre-#178) | All five pass green today — `resource_grading_registry` 5/5, `shipped_binary_registry` 5/5, `exec_copy_registry` 7/7 — which is the same green they showed **under the mutations that should have reddened them**. A confirmed-blind gate that is still green is not a finding that has been acted on; it is a finding that has been written down. Only `lockfile_forge_registry` has its own tracker (**#180**). Closing #178 would drop `pool_capability_registry`, `resource_grading_registry`, `exec_copy_registry` and `shipped_binary_registry` off the board with **no issue anywhere** — which is exactly the silent disappearance this close-out lane exists to prevent. ### Corrected scope Retitle as above. Strike *"no other registry has been audited"* — that is discharged. The remaining work is: **fix, or split into per-gate trackers, the four blind registries that have no owner**, plus `lockfile_forge_registry` if #180 is not taken first. ### Residuals the implementing lane named, recorded here so they are not lost - `disclosure_surface_registry`'s `produces` is still a spelling — `fn search_text`'s `lang` **parameter** alone satisfies one row. - `kind_polarity` leaves SQL shapes outside its four classes unclassified: 21 sites classify against a floor of 10. - Two `COSI_E2E_LEG=daemon` e2e failures with one signature on *different* tests per run (`index_coverage_facts_e2e::a_refused_file_is_not_reported_as_indexed_and_current`, `activation_offer_e2e::an_unconsultable_store_is_never_rendered_as_nothing_to_activate`), both passing in isolation — reported as a fixture-readiness race, not blessed. That is **#192**.

buildagent changed title from Gate-design class: a population check satisfied by the very thing it was meant to detect — bless_registry's src.contains("bless_verdict") passed on every local wrapper, and the other registries were not audited for the same shape to Five registries were CONFIRMED blind by mutation and four have no tracker: pool_capability, resource_grading, exec_copy and shipped_binary are still green under the mutations that should redden them 2026-09-06 12:48:59 +02:00

buildagent referenced this issue 2026-09-06 12:49:17 +02:00

The Windows disk pre-flight blocks CI on a percentage while its own absolute floor passes, and the prune it pairs with cannot free anything #179

buildagent referenced this issue 2026-09-06 12:49:31 +02:00

lockfile_forge_registry is blind TODAY: a doc comment in the one file its anti-vacuity floor names exempts that whole file, so its declared mutation is false as written #180

buildagent referenced this issue 2026-09-06 12:51:07 +02:00

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

buildagent referenced this issue 2026-09-06 12:51:28 +02:00

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

buildagent referenced this issue 2026-09-06 12:53:29 +02:00

Two $minFreeGb assignments with different values, and the gate pinning them matches whole-file so it only ever sees the first — the Windows reclaim can never fire #193

dhoyer referenced this issue from a commit 2026-09-06 13:04:19 +02:00

fix: `clean` is derived from a roster, not inferred from silence (#171 + five)

dhoyer referenced this issue from a commit 2026-09-06 13:04:19 +02:00

fix: a test that EXECUTES a .sh needs an interpreter Windows actually has

dhoyer closed this issue 2026-09-06 13:04:19 +02:00

buildagent referenced this issue 2026-09-06 13:05:03 +02:00

release_gate_e2e.rs:102-122 still says musl is continue-on-error and that nothing runs the step-13 migration gate — both false since #84 #187

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

precision_gate's population is far smaller than its reputation — phantom_count == 0 bounds ~50 hand-written probes, not the corpus, and it is cited across the tree as an absolute guarantee #188

dhoyer referenced this issue from a commit 2026-09-06 19:27:53 +02:00

fix: a barrier above 31 suites, a gate that sees every assignment, and #194 refused with numbers

buildagent referenced this issue 2026-09-07 00:37:20 +02:00

Six gates were rated vulnerable and never mutated — their status is UNKNOWN, not safe (the #180 audit residual) #204

buildagent referenced this issue from a commit 2026-09-13 23:13:16 +02:00

fix(ci): cargo fmt --all exceeds the Windows command-line limit (#269)

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#178

No description provided.