claim::Key has no bounded path globs, and a fixture row named bounded_glob_claim tests no glob #135
Labels
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
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
h-dv/code-index#135
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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::KeyisExt | Name | Suffix— two of the three. There is no glob.The part that is actively misleading
A fixture row is named
bounded_glob_claimand 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
#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.Ext | Name | Suffixis 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/Suffixcannot 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_identityfor 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.
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-72records why bounded path globs are not being added, with two reasons that are properties of the system rather than estimates:intersectfrom an exact witness path to conservative superset probes.Keytherefore staysExt | 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_claimexercised no glob. That name is gone: it is nowbounded_suffix_claim, asserted atcrates/indexer/tests/generation_equivalence.rs:302, with the rationale at:286-296and the fixture comment atcrates/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 exhaustivematchonclaim::Key. So a fourthKeykind 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.Where the remaining question lives — this is the important line
The directory-claim half is not dropped, it is DEFERRED INTO #154.
claim.rs:67says 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::Keyas 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