h-dv/code-index

Watch

Fork 0

`packages.rs:4478-4480` says the wire has no bit for `is_extension`, contradicting `record.rs:18` and a comment fifteen lines above it in the same expression #185

New issue

Closed

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

buildagent commented

2026-09-06 09:54:35 +02:00

Member

Found by dogfooding during the 2026-09-06 triage session, while verifying #86's four ABI gaps. One file, one expression, two opposite claims — sitting exactly where a reader goes to decide whether #86 gap 3 is possible.

Measured

crates/indexer/src/packages.rs:4478-4480:

"C# EXTENSION METHODS ARE A BUILTIN CONCEPT. The wire has no bit for it"

Both halves of that are contradicted by the tree:

claim	contradicted by
"the wire has no bit for it"	`TAG_SYMBOL_IS_EXTENSION = 0x8002` — `crates/abi/src/record.rs:18`
"the wire has no bit for it"	the longer comment fifteen lines above, in the same expression — `packages.rs:4462-4473` — which correctly says "Its ABI half is closed too."

So the file disagrees with itself within a single expression, and with the ABI crate.

Why it matters more than a stale sentence

This is the comment that explains why packages.rs:4481 writes a literal is_extension: false for every packaged symbol. The real reason is good and is stated correctly in the upper comment: wiring it through would falsify pool_capability_registry's NeverDynamic("s.is_extension = 1") stance and admit a package to the C# extension pool with no grant — a #77 capability decision, deliberately not taken.

The lower sentence replaces that reasoning with a false one. A reader who finds it first concludes the ABI work is undone and either duplicates TAG_SYMBOL_IS_EXTENSION, or files gap 3 as an ABI gap when it is a capability decision. #86's own body already made a version of that mistake about a neighbouring tag (it claims facts_to_extract hardcodes attr_start_line: None; the mapping is live at packages.rs:4475).

This repo's recorded rule is that issue text goes stale in both directions — and so does in-tree prose. The difference is that a wrong comment is read at the moment of a decision.

Repro

Read crates/indexer/src/packages.rs:4460-4485 top to bottom. The upper comment says the ABI half is closed; the lower says the wire has no bit. crates/abi/src/record.rs:18 settles it.

Why existing gates miss it

Nothing grades a comment against the constant it describes. The readme_security_claims / platform_support_claims pattern (crates/daemon/tests/support/claims.rs) does exactly this for shipped documents — deriving thresholds from NetworkDenial::Enforced.encode() and NETWORK_FILTER_SUPPORTED's own cfg! rather than from copied spellings — and it caught a claim shipping from two places nobody had looked at. No equivalent exists for source comments that assert the presence or absence of an ABI tag.

What must NOT be done

Do not delete the sentence and stop there. The upper comment carries the real, correct argument; the fix is to make the lower one agree with it, so the next reader gets the capability reason rather than an absence claim.
Do not "fix" it by wiring is_extension through. That is #86 gap 3 and is an unmade #77 capability decision — doing it as a side effect of a comment repair would admit a package to the C# extension pool with no grant.
Do not treat this as documentation-only when scoping. The sentence is load-bearing on a live decision, which is why it is filed rather than swept.
Do not generalise into a "grade every comment" gate. The tractable version is narrow: a comment asserting a wire tag is absent should be checkable against crates/abi/src/record.rs's tag constants, in the shape claims.rs already uses.

#86 — gap 3; its body should also lose the false attr_start_line premise (see the triage comment there).
#114 — the same family at the user-facing layer: a summary asserting more than the analysis behind it, fixed by a gate rather than by three edits.

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

Found by dogfooding during the 2026-09-06 triage session, while verifying **#86**'s four ABI gaps. One file, one expression, two opposite claims — sitting exactly where a reader goes to decide whether #86 gap 3 is possible. ## Measured `crates/indexer/src/packages.rs:4478-4480`: > *"C# EXTENSION METHODS ARE A BUILTIN CONCEPT. **The wire has no bit for it**"* Both halves of that are contradicted by the tree: | claim | contradicted by | |---|---| | "the wire has no bit for it" | `TAG_SYMBOL_IS_EXTENSION = 0x8002` — `crates/abi/src/record.rs:18` | | "the wire has no bit for it" | the longer comment **fifteen lines above, in the same expression** — `packages.rs:4462-4473` — which correctly says *"Its ABI half is closed too."* | So the file disagrees with itself within a single expression, and with the ABI crate. ## Why it matters more than a stale sentence This is the comment that explains why `packages.rs:4481` writes a literal `is_extension: false` for every packaged symbol. The **real** reason is good and is stated correctly in the upper comment: wiring it through would falsify `pool_capability_registry`'s `NeverDynamic("s.is_extension = 1")` stance and admit a package to the C# extension pool **with no grant** — a #77 capability decision, deliberately not taken. The lower sentence replaces that reasoning with a false one. A reader who finds it first concludes the ABI work is undone and either duplicates `TAG_SYMBOL_IS_EXTENSION`, or files gap 3 as an ABI gap when it is a **capability decision**. #86's own body already made a version of that mistake about a neighbouring tag (it claims `facts_to_extract` hardcodes `attr_start_line: None`; the mapping is live at `packages.rs:4475`). This repo's recorded rule is that **issue text goes stale in both directions** — and so does in-tree prose. The difference is that a wrong comment is read at the moment of a decision. ## Repro Read `crates/indexer/src/packages.rs:4460-4485` top to bottom. The upper comment says the ABI half is closed; the lower says the wire has no bit. `crates/abi/src/record.rs:18` settles it. ## Why existing gates miss it Nothing grades a comment against the constant it describes. The `readme_security_claims` / `platform_support_claims` pattern (`crates/daemon/tests/support/claims.rs`) does exactly this for *shipped documents* — deriving thresholds from `NetworkDenial::Enforced.encode()` and `NETWORK_FILTER_SUPPORTED`'s own `cfg!` rather than from copied spellings — and it caught a claim shipping from two places nobody had looked at. **No equivalent exists for source comments that assert the presence or absence of an ABI tag.** ## What must NOT be done - **Do not delete the sentence and stop there.** The upper comment carries the real, correct argument; the fix is to make the lower one agree with it, so the next reader gets the capability reason rather than an absence claim. - **Do not "fix" it by wiring `is_extension` through.** That is #86 gap 3 and is an unmade **#77 capability decision** — doing it as a side effect of a comment repair would admit a package to the C# extension pool with no grant. - **Do not treat this as documentation-only when scoping.** The sentence is load-bearing on a live decision, which is why it is filed rather than swept. - **Do not generalise into a "grade every comment" gate.** The tractable version is narrow: a comment asserting a wire tag is absent should be checkable against `crates/abi/src/record.rs`'s tag constants, in the shape `claims.rs` already uses. ## Related - **#86** — gap 3; its body should also lose the false `attr_start_line` premise (see the triage comment there). - **#114** — the same family at the user-facing layer: a summary asserting more than the analysis behind it, fixed by a gate rather than by three edits. 🤖 Filed by the triage lane, 2026-09-06, found while verifying #86.

buildagent added the

labels

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

Author

Member

CONFIRMED and FIXED. The claim is corrected, the reasoning is kept, and the fact now points at the row that grades it.

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

Verified before touching anything

Both halves of the contradiction reproduce exactly as filed:

claim	contradicted by
"The wire has no bit for it"	`pub const TAG_SYMBOL_IS_EXTENSION: u16 = 0x8002;` — `crates/abi/src/record.rs:77`, and the module header at `:18` names it as one of the two optional tags #86 added
"The wire has no bit for it"	the comment fifteen lines above, in the same expression — "Its ABI half is closed too"

The tag is not merely declared, it is live on both sides: encoded at record.rs:1328, decoded at :1082, emitted by the guest at crates/guest/src/encode.rs:351, and round-tripped by crates/guest/tests/wire_parity.rs:832.

The fix

crates/indexer/src/packages.rs:4477-4499 (was 4478-4480). The sentence is corrected, not deleted — per the issue's first "must not". What changed:

It now says the wire has the bit, names it, and says #86 closed that half — so the lower comment agrees with the upper one instead of contradicting it.
It records what the false version cost, in one line, so the next reader knows why the paragraph is emphatic.
The real reason survives and is now sourced: the hard-coded false is the structural justification cited by pool_capability_registry's NeverDynamic("s.is_extension = 1") row, and the comment points there rather than restating the fact in prose. That is the small mechanism available here — the fact already had a graded home, and the comment was competing with it.
Nothing was wired. Gap 3 remains the unmade #77 capability decision it was.

cargo test -p code-index-indexer --test pool_capability_registry → 17 passed, EXIT 0
cargo fmt --all -- --check → 0 · clippy --workspace --all-targets -D warnings → 0
RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps --document-private-items → 0

On the gate this issue asks for — REFUSED, with the measurement

The issue proposes a narrow claims.rs-shaped check: a comment asserting a wire tag is absent should be checkable against record.rs's tag constants. I measured the population before building it, and it does not support the gate.

The claim family has to be found by vocabulary, and over the 152,986 comment lines in crates/:

phrase	hits
`no bit for`	1 — this one
`the wire has no`	0
`has no tag`	0
`there is no`	320
`does not exist`	99
`no such`	83

The true family is a single line; the phrases broad enough to catch a differently worded future instance return hundreds of hits that are overwhelmingly runtime conditions (if the file does not exist). A gate keyed on "the wire has no bit" catches this exact sentence and nothing else — a fix-per-case wearing a gate's clothes — and one keyed broadly enough to generalise would be suppressed within a week.

The denominator is also small on the other side: record.rs declares 7 tags, of which 2 are optional. A registry over two rows is not where this earns its keep.

crates/abi/tests/doc_citation_gate.rs's own header already reached this conclusion with its own numbers, and drew the line in the right place: name resolution is mechanical, a claim about a state is not. "TAG_SYMBOL_IS_EXTENSION exists" is checkable; "the wire has no bit for it" is a proposition, and there is no computable relation from that sentence to that constant without a vocabulary that does not survive contact with a paraphrase.

Full reasoning, and the two other refusals it rests on, in the #187 comment.

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

## CONFIRMED and FIXED. The claim is corrected, the reasoning is kept, and the fact now points at the row that grades it. Lane worktree: `/tmp/cosi-lane-docdrift`, detached at master `552e3a2`. Staged by path, **not pushed**. ### Verified before touching anything Both halves of the contradiction reproduce exactly as filed: | claim | contradicted by | |---|---| | "The wire has no bit for it" | `pub const TAG_SYMBOL_IS_EXTENSION: u16 = 0x8002;` — `crates/abi/src/record.rs:77`, and the module header at `:18` names it as one of the two optional tags #86 added | | "The wire has no bit for it" | the comment fifteen lines above, in the same expression — *"Its ABI half is closed too"* | The tag is not merely declared, it is live on both sides: encoded at `record.rs:1328`, decoded at `:1082`, emitted by the guest at `crates/guest/src/encode.rs:351`, and round-tripped by `crates/guest/tests/wire_parity.rs:832`. ### The fix `crates/indexer/src/packages.rs:4477-4499` (was 4478-4480). The sentence is **corrected, not deleted** — per the issue's first "must not". What changed: - It now says the wire **has** the bit, names it, and says #86 closed that half — so the lower comment agrees with the upper one instead of contradicting it. - It records what the false version cost, in one line, so the next reader knows why the paragraph is emphatic. - The real reason survives and is now *sourced*: the hard-coded `false` **is** the structural justification cited by `pool_capability_registry`'s `NeverDynamic("s.is_extension = 1")` row, and the comment points there rather than restating the fact in prose. That is the small mechanism available here — the fact already had a graded home, and the comment was competing with it. - Nothing was wired. Gap 3 remains the unmade #77 capability decision it was. ``` cargo test -p code-index-indexer --test pool_capability_registry → 17 passed, EXIT 0 cargo fmt --all -- --check → 0 · clippy --workspace --all-targets -D warnings → 0 RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps --document-private-items → 0 ``` ### On the gate this issue asks for — REFUSED, with the measurement The issue proposes a narrow `claims.rs`-shaped check: *a comment asserting a wire tag is absent should be checkable against `record.rs`'s tag constants.* I measured the population before building it, and it does not support the gate. The claim family has to be found by vocabulary, and over the **152,986** comment lines in `crates/`: | phrase | hits | |---|---| | `no bit for` | **1** — this one | | `the wire has no` | 0 | | `has no tag` | 0 | | `there is no ` | 320 | | `does not exist` | 99 | | `no such` | 83 | The true family is a single line; the phrases broad enough to catch a *differently worded* future instance return hundreds of hits that are overwhelmingly runtime conditions (`if the file does not exist`). A gate keyed on "the wire has no bit" catches this exact sentence and nothing else — a fix-per-case wearing a gate's clothes — and one keyed broadly enough to generalise would be suppressed within a week. The denominator is also small on the other side: `record.rs` declares **7** tags, of which **2** are optional. A registry over two rows is not where this earns its keep. `crates/abi/tests/doc_citation_gate.rs`'s own header already reached this conclusion with its own numbers, and drew the line in the right place: **name resolution is mechanical, a claim about a state is not.** "`TAG_SYMBOL_IS_EXTENSION` exists" is checkable; "the wire has no bit for it" is a proposition, and there is no computable relation from that sentence to that constant without a vocabulary that does not survive contact with a paraphrase. Full reasoning, and the two other refusals it rests on, in the #187 comment. 🤖 Doc-drift lane, 2026-09-06, master `552e3a2`

buildagent referenced this issue

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

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

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