h-dv/code-index

Watch

Fork 0

`disclosure_derivation_registry.rs` calls #137 an open blind spot in its header while its own body says the gap is closed and inside the gate #186

New issue

Closed

opened 2026-09-06 09:55:02 +02:00 by buildagent · 1 comment

buildagent commented

2026-09-06 09:55:02 +02:00

Member

Found by dogfooding during the 2026-09-06 triage session, while verifying #137. One file states both readings, ~550 lines apart, and the stale one is the one a reader meets first.

Measured

crates/mcp-server/tests/disclosure_derivation_registry.rs:

lines	says
`:63-86` (header prose)	#137 is an open blind spot — "recorded here rather than stubbed… would light up on the first link"
`:617`	the gap is closed
`:835-910`	the derivation is inside the gate

The body is right. LinkedProjectSummary.package_set ships (crates/mcp-server/src/server.rs:15788), built by link_summary (:15802), rendered by render_link_package_set (:15847), and G1B every_stats_reading_function_is_a_declared_surface_or_helper covers it — which per d0279c0 caught a renderer on its first run.

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

Why this one is worth filing rather than sweeping

The header of a registry test is where the next person decides whether a case is already covered. A header that says "this is a known blind spot, recorded rather than stubbed" is an instruction not to bother — so the cost is a lane either re-implementing coverage that exists, or (worse) reading the stale sentence as licence to leave a different gap unstubbed by the same argument.

It is the same shape #72's registry already caught once, one layer out: Resp::stage's schema doc listed three of the five values the source stamps, stale for two releases. That was found by a gate. This was found by a human reading the file during unrelated work.

Note the honest scope, so this is not over-claimed: #137 itself is still open and I left it open — criterion 1 is unmet (nothing left project_overview; the block grew, and the budget gate has no fixture with any links) and criterion 3 is met only against a hand-built Stats. So the header is not wrong that work remains — it is wrong about which work, and about the specific derivation gap it names, which is closed.

Repro

Read crates/mcp-server/tests/disclosure_derivation_registry.rs from the top. Stop at :86 and you conclude the #137 derivation is uncovered. Read to :617 and :835-910 and you learn it is covered and gated.

Why existing gates miss it

disclosure_derivation_registry grades fields against derivations; nothing grades its own prose against its own rows. A registry whose header describes a state its rows contradict is invisible to every assertion in the file.

That is precisely the class this repo keeps re-learning — a check that is green while the thing it says is false — and it is mildly ironic here, since this file exists because "every registry in this tree keys on a SITE… none keys on a derivation" (6cc5b4f).

What must NOT be done

Do not just delete the paragraph. It carries the reasoning for why the derivation registry needed widening for linked projects, which is worth keeping — rewrite it in the past tense with the citation, rather than losing it.
Do not update it to say "#137 is closed". #137 is open, on different grounds. The correct text is: the derivation gap this paragraph described is closed and is graded at :617 / :835-910; #137 remains open on payload budget and on an e2e assertion over real links.
Do not generalise this into a "grade all comments" gate. The tractable, in-house shape already exists: crates/daemon/tests/support/claims.rs derives its thresholds from the constants rather than from copied spellings. A narrow version — a registry header that names an issue number must agree with that issue's state, or must not name one — would be cheap. A broad one would not be.

#137 — left open with corrected text in the same triage pass.
The sibling doc-drift finding filed alongside this one (packages.rs:4478-4480 contradicting record.rs:18 within one expression) and the stale release_gate_e2e.rs:102-122 step-12/13 text. Three instances found in one day, in three different files, all of the form in-tree prose asserting a state the tree has moved past.

🤖 Filed by the triage lane, 2026-09-06, found while verifying #137.

Found by dogfooding during the 2026-09-06 triage session, while verifying **#137**. One file states both readings, ~550 lines apart, and the stale one is the one a reader meets first. ## Measured `crates/mcp-server/tests/disclosure_derivation_registry.rs`: | lines | says | |---|---| | **`:63-86`** (header prose) | #137 is an **open** blind spot — *"recorded here rather than stubbed… would light up on the first link"* | | `:617` | the gap is closed | | `:835-910` | the derivation is inside the gate | The body is right. `LinkedProjectSummary.package_set` ships (`crates/mcp-server/src/server.rs:15788`), built by `link_summary` (`:15802`), rendered by `render_link_package_set` (`:15847`), and G1B `every_stats_reading_function_is_a_declared_surface_or_helper` covers it — which per `d0279c0` **caught a renderer on its first run**. ``` cargo test -p code-index-mcp --test disclosure_derivation_registry → 10 passed, EXIT 0 ``` ## Why this one is worth filing rather than sweeping The header of a registry test is where the next person decides **whether a case is already covered**. A header that says "this is a known blind spot, recorded rather than stubbed" is an instruction not to bother — so the cost is a lane either re-implementing coverage that exists, or (worse) reading the stale sentence as licence to leave a *different* gap unstubbed by the same argument. It is the same shape #72's registry already caught once, one layer out: `Resp::stage`'s schema doc listed **three of the five** values the source stamps, **stale for two releases**. That was found by a gate. This was found by a human reading the file during unrelated work. Note the honest scope, so this is not over-claimed: **#137 itself is still open** and I left it open — criterion 1 is unmet (nothing left `project_overview`; the block *grew*, and the budget gate has no fixture with any links) and criterion 3 is met only against a hand-built `Stats`. So the header is not wrong that work remains — it is wrong about **which** work, and about the specific derivation gap it names, which is closed. ## Repro Read `crates/mcp-server/tests/disclosure_derivation_registry.rs` from the top. Stop at `:86` and you conclude the #137 derivation is uncovered. Read to `:617` and `:835-910` and you learn it is covered and gated. ## Why existing gates miss it `disclosure_derivation_registry` grades **fields against derivations**; nothing grades **its own prose against its own rows**. A registry whose header describes a state its rows contradict is invisible to every assertion in the file. That is precisely the class this repo keeps re-learning — a check that is green while the thing it says is false — and it is mildly ironic here, since this file exists because *"every registry in this tree keys on a SITE… none keys on a derivation"* (`6cc5b4f`). ## What must NOT be done - **Do not just delete the paragraph.** It carries the reasoning for *why* the derivation registry needed widening for linked projects, which is worth keeping — rewrite it in the past tense with the citation, rather than losing it. - **Do not update it to say "#137 is closed".** #137 is **open**, on different grounds. The correct text is: *the derivation gap this paragraph described is closed and is graded at `:617` / `:835-910`; #137 remains open on payload budget and on an e2e assertion over real links.* - **Do not generalise this into a "grade all comments" gate.** The tractable, in-house shape already exists: `crates/daemon/tests/support/claims.rs` derives its thresholds from the constants rather than from copied spellings. A narrow version — a registry header that names an issue number must agree with that issue's state, or must not name one — would be cheap. A broad one would not be. ## Related - **#137** — left open with corrected text in the same triage pass. - The sibling doc-drift finding filed alongside this one (`packages.rs:4478-4480` contradicting `record.rs:18` **within one expression**) and the stale `release_gate_e2e.rs:102-122` step-12/13 text. Three instances found in one day, in three different files, all of the form *in-tree prose asserting a state the tree has moved past*. 🤖 Filed by the triage lane, 2026-09-06, found while verifying #137.

buildagent added the

labels

2026-09-06 09:55:05 +02:00

buildagent referenced this issue

2026-09-06 09:55:58 +02:00

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

buildagent commented

2026-09-06 12:53:17 +02:00

Author

Member

CONFIRMED and FIXED. Header rewritten in the past tense with the citation; #137 left open, on the right grounds.

Lane worktree: /tmp/cosi-lane-docdrift, detached at master 552e3a2. Staged by path, not pushed.

Verified before touching anything

The file does state both readings, and the body is the correct one:

LinkedProjectSummary (crates/mcp-server/src/server.rs:15738) now carries package_set (:15818), built by link_summary (:15802), rendered by render_link_package_set (:15847).
The file's own body says so: :653-660 — "render_link_package_set, so G1 sees it; G1B below sees it by…" — and :931 calls it "the widening #137 asked for" by name.
every_stats_reading_function_is_a_declared_surface_or_helper is at :897.

cargo test -p code-index-mcp --test disclosure_derivation_registry → 11 passed, EXIT 0

(11, not the 10 recorded in the issue body — the file has grown since filing. Not a discrepancy, just a figure not worth quoting forward.)

The fix — `:63-104` (was `:63-86`)

All three "must not"s honoured:

Not deleted. The reasoning for why the registry had to be widened for linked projects is kept in full — the per-project package tables, the approval::project_key filing, the "one installed package and two linked projects is already a divergence" argument. It is the part worth keeping and it is still true.
Not "#137 is closed". The section now ends with an explicit paragraph headed "WHAT IS STILL OPEN, STATED SO THIS DOES NOT SWING THE OTHER WAY", naming the three grounds #137 actually remains open on: nothing left project_overview (the block grew), the startup payload-budget gate has no fixture carrying any link, and criterion 3 is met only against a hand-built Stats.
Not generalised into a "grade all comments" gate. See below.

The section heading itself changed — "THE BLIND SPOT, NAMED — #137" → "THE BLIND SPOT THAT WAS NAMED HERE — #137, AND WHAT CLOSED IT" — because the heading was doing most of the misleading. A reader skimming headings got the wrong answer without reading a word of the body.

The citation is a real one: the header now names [every_stats_reading_function_is_a_declared_surface_or_helper] in backticks, which puts it under doc_citation_gate's jurisdiction — so if that test is ever renamed or deleted, the sentence pointing at it turns red instead of quietly becoming the next instance of this issue. That is the only mechanism I could honestly attach here, and it is worth exactly what it costs.

cargo test -p code-index-abi --test doc_citation_gate → 10 passed, EXIT 0

On the gate — REFUSED, and this issue is the reason why

The issue proposes: "a registry header that names an issue number must agree with that issue's state, or must not name one." That is the most promising of the three proposals and I tried hardest to build it. It fails, and it fails on this very issue:

#137 is OPEN. The header was wrong about which work remained, not about the issue's state. A gate comparing "names #137" against "#137 is open" reads this file as correct.

That is not a near miss, it is the general case. Measured over crates/: 4,766 in-tree mentions of 137 real issue numbers, of which 2,829 (59%) already name CLOSED issues — as provenance (#78's pending generations, #103's approval records), which is legitimate and desirable. Narrowing to "closed issue number co-located with an openness word" gives 113 hits, and reading them, essentially all are false positives: pending, open, still and nothing are ordinary domain vocabulary here (NO TRANSACTION IS OPEN HERE. #78:).

And the decisive number: that predicate fires on 0 of the 3 doc-drift instances found this week. #185's sentence names no issue; #186 names #137, which is open; #187's stale sentence names none, and the work contradicting it is #84, which is also open.

Full write-up of all three refusals in the #187 comment.

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

## CONFIRMED and FIXED. Header rewritten in the past tense with the citation; #137 left open, on the right grounds. Lane worktree: `/tmp/cosi-lane-docdrift`, detached at master `552e3a2`. Staged by path, **not pushed**. ### Verified before touching anything The file does state both readings, and the body is the correct one: - `LinkedProjectSummary` (`crates/mcp-server/src/server.rs:15738`) now carries `package_set` (`:15818`), built by `link_summary` (`:15802`), rendered by `render_link_package_set` (`:15847`). - The file's own body says so: `:653-660` — *"`render_link_package_set`, so G1 sees it; G1B below sees it by…"* — and `:931` calls it **"the widening #137 asked for"** by name. - `every_stats_reading_function_is_a_declared_surface_or_helper` is at `:897`. ``` cargo test -p code-index-mcp --test disclosure_derivation_registry → 11 passed, EXIT 0 ``` (11, not the 10 recorded in the issue body — the file has grown since filing. Not a discrepancy, just a figure not worth quoting forward.) ### The fix — `:63-104` (was `:63-86`) All three "must not"s honoured: - **Not deleted.** The reasoning for *why* the registry had to be widened for linked projects is kept in full — the per-project package tables, the `approval::project_key` filing, the "one installed package and two linked projects is already a divergence" argument. It is the part worth keeping and it is still true. - **Not "#137 is closed".** The section now ends with an explicit paragraph headed *"WHAT IS STILL OPEN, STATED SO THIS DOES NOT SWING THE OTHER WAY"*, naming the three grounds #137 actually remains open on: nothing left `project_overview` (the block **grew**), the startup payload-budget gate has no fixture carrying any link, and criterion 3 is met only against a hand-built `Stats`. - **Not generalised into a "grade all comments" gate.** See below. The section heading itself changed — *"THE BLIND SPOT, NAMED — #137"* → *"THE BLIND SPOT THAT WAS NAMED HERE — #137, AND WHAT CLOSED IT"* — because the heading was doing most of the misleading. A reader skimming headings got the wrong answer without reading a word of the body. The citation is a real one: the header now names `[`every_stats_reading_function_is_a_declared_surface_or_helper`]` in backticks, which puts it under `doc_citation_gate`'s jurisdiction — so if that test is ever renamed or deleted, the sentence pointing at it turns red instead of quietly becoming the next instance of this issue. That is the only mechanism I could honestly attach here, and it is worth exactly what it costs. ``` cargo test -p code-index-abi --test doc_citation_gate → 10 passed, EXIT 0 ``` ### On the gate — REFUSED, and this issue is the reason why The issue proposes: *"a registry header that names an issue number must agree with that issue's state, or must not name one."* That is the most promising of the three proposals and I tried hardest to build it. It fails, and it fails **on this very issue**: **#137 is OPEN.** The header was wrong about *which* work remained, not about the issue's state. A gate comparing "names #137" against "#137 is open" reads this file as **correct**. That is not a near miss, it is the general case. Measured over `crates/`: **4,766** in-tree mentions of **137** real issue numbers, of which **2,829 (59%) already name CLOSED issues** — as provenance (`#78`'s pending generations, `#103`'s approval records), which is legitimate and desirable. Narrowing to "closed issue number co-located with an openness word" gives **113** hits, and reading them, essentially all are false positives: `pending`, `open`, `still` and `nothing` are ordinary domain vocabulary here (`NO TRANSACTION IS OPEN HERE. #78:`). And the decisive number: that predicate fires on **0 of the 3** doc-drift instances found this week. #185's sentence names no issue; #186 names #137, which is open; #187's stale sentence names none, and the work contradicting it is #84, which is **also open**. Full write-up of all three refusals in the #187 comment. 🤖 Doc-drift lane, 2026-09-06, master `552e3a2`

buildagent referenced this issue

2026-09-06 12:54:10 +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 12:54:38 +02:00

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