claim::Key has no bounded path globs, and a fixture row named bounded_glob_claim tests no glob #135

Closed
opened 2026-09-05 01:34:55 +02:00 by buildagent · 1 comment
Member

Split out of #76 so it can close. Small, real, and blocks no acceptance criterion as amended.

The gap

#76's manifest contract specifies "ordered path claims: extensions, exact basenames and bounded globs". claim::Key is Ext | Name | Suffix — two of the three. There is no glob.

The part that is actively misleading

A fixture row is named bounded_glob_claim and tests no glob. A reader auditing claim coverage finds a row whose name asserts the feature exists, which is worse than the absence itself: it converts "not implemented" into "apparently covered".

That is the same shape this project has repeatedly paid for — a check whose name claims more than its content. Rename it as part of whatever happens here, even if globs are never built.

Two honest options

  1. Implement bounded globs. "Bounded" is load-bearing: the manifest contract is explicit that a package may not ship unbounded pattern work, and #65's whole history is resolver stages whose populations grew without a bound. Any glob accepted here needs a stated upper bound on what it can match and a gate proving the bound holds.
  2. Retire the requirement, the way #76's declarative tier was retired: amend the contract text, rename the fixture, and record why Ext | Name | Suffix is sufficient. The Ruby and XAML packages both claim files without needing a glob, which is evidence for this option rather than against it.

I lean toward (2) on current evidence — no shipped package has wanted one, and an unused pattern surface in a manifest that third parties author is a liability rather than a feature. But that is a product call, and the measurement that would settle it is simply: does any plausible language claim files in a way Ext/Name/Suffix cannot express?

Not urgent

No package needs it, no gate depends on it, and the fixture name is the only thing currently saying something untrue. Worth doing before the ABI is declared stable, since adding a claim kind afterwards moves extraction_identity for every package.

Split from #76 (closed). Same family as the declarative-tier retirement recorded there: a manifest surface the host does not implement is a trap for package authors.

Split out of #76 so it can close. Small, real, and blocks no acceptance criterion as amended. ## The gap #76's manifest contract specifies *"ordered path claims: **extensions, exact basenames and bounded globs**"*. `claim::Key` is `Ext | Name | Suffix` — two of the three. There is no glob. ## The part that is actively misleading A fixture row is named **`bounded_glob_claim`** and tests no glob. A reader auditing claim coverage finds a row whose name asserts the feature exists, which is worse than the absence itself: it converts "not implemented" into "apparently covered". That is the same shape this project has repeatedly paid for — a check whose *name* claims more than its *content*. Rename it as part of whatever happens here, even if globs are never built. ## Two honest options 1. **Implement bounded globs.** "Bounded" is load-bearing: the manifest contract is explicit that a package may not ship unbounded pattern work, and `#65`'s whole history is resolver stages whose populations grew without a bound. Any glob accepted here needs a stated upper bound on what it can match and a gate proving the bound holds. 2. **Retire the requirement**, the way #76's declarative tier was retired: amend the contract text, rename the fixture, and record why `Ext | Name | Suffix` is sufficient. The Ruby and XAML packages both claim files without needing a glob, which is evidence for this option rather than against it. I lean toward (2) on current evidence — no shipped package has wanted one, and an unused pattern surface in a manifest that third parties author is a liability rather than a feature. But that is a product call, and the measurement that would settle it is simply: does any plausible language claim files in a way `Ext`/`Name`/`Suffix` cannot express? ## Not urgent No package needs it, no gate depends on it, and the fixture name is the only thing currently saying something untrue. Worth doing before the ABI is declared stable, since adding a claim kind afterwards moves `extraction_identity` for every package. ## Related Split from #76 (closed). Same family as the declarative-tier retirement recorded there: a manifest surface the host does not implement is a trap for package authors.
Author
Member

Triage 2026-09-06 at f6a878a: CLOSING as option 2 — the requirement is retired with a stated structural reason, and the vacuous fixture name is gone and gated against returning.

Verified against master and by re-running the gate myself.

The decision, and it rests on structure rather than effort

crates/package/src/claim.rs:44-72 records why bounded path globs are not being added, with two reasons that are properties of the system rather than estimates:

  1. A directory key would make ownership change on a rename that #78's dirty domain cannot see — the dirty domain is built from these same keys, so a rename would silently move a file between owners with nothing to notice.
  2. It would demote intersect from an exact witness path to conservative superset probes.

Key therefore stays Ext | Name | Suffix (claim.rs:100-108).

The half that was a real defect — the fixture that tested nothing — is fixed generically

This issue's sharpest point was that a row named bounded_glob_claim exercised no glob. That name is gone: it is now bounded_suffix_claim, asserted at crates/indexer/tests/generation_equivalence.rs:302, with the rationale at :286-296 and the fixture comment at crates/indexer/tests/generation_fixture/mod.rs:54.

And it is not a spelling fix. The gate is a_row_is_not_named_for_a_key_kind_it_does_not_exercise — generation_equivalence.rs:336 — whose kind vocabulary is read off an exhaustive match on claim::Key. So a fourth Key kind breaks the build, rather than quietly widening the set of words a fixture row is allowed to claim. That is the generic mechanism this repo asks for rather than a fix-per-case, and the mutation (rename the row back) is recorded RED.

$ export CARGO_INCREMENTAL=0
$ cargo test -p code-index-indexer --test generation_equivalence -- --exact \
    a_row_is_not_named_for_a_key_kind_it_does_not_exercise
test a_row_is_not_named_for_a_key_kind_it_does_not_exercise ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 13 filtered out
EXIT=0

Where the remaining question lives — this is the important line

The directory-claim half is not dropped, it is DEFERRED INTO #154. claim.rs:67 says so verbatim: the directory-key question is "#154's to decide, with its bridges and scopes, and #154 is deferred".

So this close means "bounded globs are refused for claim::Key as it stands, and the fixture no longer lies about what it tests" — not "directory-scoped claims were considered and rejected forever". #154 is open and carries it. Anyone reopening this line of work should go there.

🤖 Triage lane, 2026-09-06, master f6a878a

## Triage 2026-09-06 at `f6a878a`: CLOSING as **option 2 — the requirement is retired with a stated structural reason, and the vacuous fixture name is gone and gated against returning.** Verified against master and by re-running the gate myself. ### The decision, and it rests on structure rather than effort `crates/package/src/claim.rs:44-72` records why bounded path globs are **not** being added, with two reasons that are properties of the system rather than estimates: 1. **A directory key would make ownership change on a rename that #78's dirty domain cannot see** — the dirty domain is built from these same keys, so a rename would silently move a file between owners with nothing to notice. 2. **It would demote `intersect` from an exact witness path to conservative superset probes.** `Key` therefore stays `Ext | Name | Suffix` (`claim.rs:100-108`). ### The half that was a real defect — the fixture that tested nothing — is fixed generically This issue's sharpest point was that a row named `bounded_glob_claim` exercised **no glob**. That name is gone: it is now `bounded_suffix_claim`, asserted at `crates/indexer/tests/generation_equivalence.rs:302`, with the rationale at `:286-296` and the fixture comment at `crates/indexer/tests/generation_fixture/mod.rs:54`. And it is not a spelling fix. The gate is `a_row_is_not_named_for_a_key_kind_it_does_not_exercise` — `generation_equivalence.rs:336` — whose kind vocabulary is read off an **exhaustive `match` on `claim::Key`**. So a fourth `Key` kind breaks the *build*, rather than quietly widening the set of words a fixture row is allowed to claim. That is the generic mechanism this repo asks for rather than a fix-per-case, and the mutation (rename the row back) is recorded RED. ``` $ export CARGO_INCREMENTAL=0 $ cargo test -p code-index-indexer --test generation_equivalence -- --exact \ a_row_is_not_named_for_a_key_kind_it_does_not_exercise test a_row_is_not_named_for_a_key_kind_it_does_not_exercise ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 13 filtered out EXIT=0 ``` ### Where the remaining question lives — this is the important line **The directory-claim half is not dropped, it is DEFERRED INTO #154.** `claim.rs:67` says so verbatim: the directory-key question is *"#154's to decide, with its bridges and scopes, and #154 is deferred"*. So this close means "bounded globs are refused for `claim::Key` as it stands, and the fixture no longer lies about what it tests" — **not** "directory-scoped claims were considered and rejected forever". #154 is open and carries it. Anyone reopening this line of work should go there. 🤖 Triage lane, 2026-09-06, master `f6a878a`
Sign in to join this conversation.
No milestone
No project
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#135
No description provided.