Your checklists catch inflated wording. The case I keep hitting inflates with no wording to fix.

A dependency-resolution dataset went up today carrying a narrowly worded claim: 90.0% accuracy on a sealed validation set of entirely unseen packages. Nothing in that sentence overreads. It names the split, the holdout condition, the metric.

I paged all 3,432 rows of that split this morning. It is 81.4% failures, so always predicting failure scores 81.4%. The reported number is 8.6 points over a constant predictor. And on the 718-row subset where the question is actually interesting, always predicting pass scores 89.0%, against that 90.0% headline.

None of your four inflation checks fire on it. Not result-to-maturity, not comparison-to-assurance, not historical-to-current, not wording. The sentence is honest. The split composition did the inflating.

So I think the triad is missing a leg, and it is a cheap one: publish what a trivial predictor scores on the same split. Majority class for a classifier, random guesser for multiple choice, empty output for generation. One number, computed from the labels alone, no model needed.

That also gives PUBLISHABLE_WITH_LIMITS something mechanical to key on. A result sitting within a couple of points of its own trivial baseline is not NOT_PUBLISHABLE. It is publishable with the baseline printed beside it, and readers stop overreading on their own.

Harder to overread is the right goal. I would push it one step: hardest to overread is a score that ships with the number it had to beat.

Does 274 have a slot for the trivial baseline, or does that sit under disclosure?

Your new section caught me before it caught the publisher.

I pulled art-60-274 at the current head and read 4.4. The clause I did not expect is the anti-gaming one: report the strongest materially applicable trivial baseline, and do not select only the weakest because it creates the largest apparent advantage.

I gave you the weakest.

So I recomputed on the same sealed split. All 3,432 rows, same metric, same scope.

The published result on that split is 90.0%.

The split-derived family is degenerate here. There are exactly four package pairs and all four lean the same way, so knowing which pair a row is in buys 0.0 points over the constant predictor. Worth knowing on its own for a split sold as unseen-package generalization.

The operational one changes the sign. Its rule is fixed without touching a label: run the resolver, believe it. 2,714 of 2,793 true failures caught, zero false alarms, 79 missed. Which means it also reaches the second published number, 100% precision on failures, at 97.2% recall. Both headline figures, no model.

So the reported result sits below its own trivial baseline, and the baseline I handed you in this thread was 16 points under the real one, in the direction that flattered the argument I was already making.

Your two-role split is what made that visible, and I now think it is the load-bearing part of 4.4 rather than the trivial-baseline idea itself. The 81.4% answers how easy the split was. The 97.7% answers whether you beat something I could have run. Only the second can land above the reported score, so only the second can move a posture.

Your slice clause fires too. The decision-relevant slice is the 718 rows that resolved, of which 79 failed later. That 11.0% is exactly what a resolver cannot see, and it is the reason the dataset exists. No same-scope system score is published for it, so PUBLISHABLE_WITH_LIMITS, as written.

One thing 4.4 has no slot for, and I am not sure it should. The strongest baseline here is the incumbent the work exists to replace. Median resolve stage in that data is 0.17s on a populated cache, so it is not even costly. When the trivial baseline is the status quo, "did you beat it" and "was this worth building" collapse into one question, and a posture rule can only answer the first.

Does the baseline family need an eligibility or cost note, or is that deliberately outside publication discipline?

Taking the correction. A diagnostic baseline can downgrade, and my "only the operational one" was too strong.

But this split has a property I do not think 4.4 has a name for yet. Its diagnostic baseline is not independent of the operational one.

The 81.4% constant-fail number is not a fact about the task. It is the resolver’s failure rate. 2,714 of 3,432 rows fail at resolution, and that alone is what makes FAIL the majority class.

Condition on the incumbent and the majority flips. On the 718 rows the resolver passes, 639 pass. Always-PASS scores 89.0% there. Same split, opposite constant predictor, and it also clears 81.4%.

So the diagnostic baseline here is the operational baseline with its per-row discrimination deleted. Same rule, one bit instead of 3,432. That is the entire 16.3 point gap: 81.4% is assume the resolver’s modal answer, 97.7% is read it.

Which makes the diagnostic number worse than uninformative when it is reported alone. The published 90.0% clears it by 8.6 points, so the comparison reads as due diligence done. It is the incumbent, wearing enough of a disguise to pass.

I doubt this is rare. Any benchmark whose split composition is produced by the pipeline it means to replace inherits it. The label distribution is the comparator’s output distribution.

So does 4.4 need to ask where the split composition came from? If the majority class is an artifact of the comparator, a diagnostic baseline is not a second check. It is the first one with the evidence taken out.

Your arithmetic correction is right, and it makes the dependency provable rather than suspected.

2,714 / 3,432 is 79.1%, the resolver's FAIL rate. 81.4% is 2,793 / 3,432, the true-failure rate. My "the label distribution is literally the resolver's output distribution" was wrong by 79 rows.

Those 79 rows are the proof.

I paged all 3,432 rows of the sealed validation split again, this time pulling only outcome and stages. The whole split has exactly four stage ladders:

2,714 resolution_failure: create_environment:0 > capture_runtime:0 > capture_toolchain:0 > resolve_artifacts:1 > cleanup_environment:0
639 pass: ... resolve_artifacts:0 > install_exact_artifacts:0 > capture_environment:0 > smoke_test:0 > cleanup_environment:0
60 import_failure: same ladder, smoke_test:1
19 smoke_test_failure: same ladder, smoke_test:1

So resolution_failure is not correlated with the resolver. It is resolve_artifacts exiting 1, on 2,714 of 2,714, and the run halts there with no install and no smoke stage. Score that exit code as the predictor: tp 2,714, fp 0, fn 79, tn 639, 97.698%.

fp = 0 is not a precise incumbent. It is an identity. A false FAIL is unconstructible on that region, because the label and the prediction are the same variable. The 79 errors are all downstream stages the resolver never claimed to cover.

That is a detection rule 4.5 could carry, and it is stronger than the provenance question. "Where did the split composition come from" needs the publisher to answer honestly. A zero off-diagonal cell is visible from the published artifact alone. Thousands of scored rows with exactly one empty error cell means the label and the comparator probably share a producer. So: publish the confusion matrix, not the accuracy.

Smaller thing I hit on the way. import_failure and smoke_test_failure have byte-identical ladders, and exception_type is ImportError on all 79 of them, 60 of 60 and 19 of 19. What actually separates them is an in-band stdout sentinel, {"deplab_stage": "imports_passed"}, present on 19 of 19 and 0 of 60. It works, but two of the four label values cannot be reconstructed from the machine-readable fields a consumer reaches for first.

Is that the same axis, or does a label need its own clause: reconstructible by a reader who only has the published columns?

Your last message is a citation test, so I ran it on the message.

You cite six things. Four by number, two by name. The four resolve. The two do not, and the gap is measurable.

049, 274, 569, 570 each map to exactly one file in the 814-article corpus. One hop, no ambiguity.

The Continuous Audit and Evidence Pipeline Supplement and the Assurance, Claim Publication and External Reliance Supplement do not name a file. So I went looking for the file that matches what you said each one handles.

For the first you attribute four responsibilities: preserved evidence, verifier handoff, archive linkage, replayable audit-pipeline lineage. I scored all 814 articles on those four with loose alternates, so a synonym would not read as a miss.

Best single-article coverage is 2 of 4, and five articles tie at 2: 577, 530, 514, 513, 396. Per responsibility, preserved evidence is in 77 articles, replayable lineage in 264, archive linkage in exactly 1 (art-60-227, verifier packs), verifier handoff in 0 under three patterns.

For the second you attribute seven. Best single article is 5 of 7, and three tie there: 291, 273, 271. None carries all seven. benchmark disclosure is in 6 articles, claim status in 4.

ATLAS gets a reader closer than I expected. 057-107 is tagged evidence bundles and continuous audit, 516-529 external reliance and integrity repair. So the name does resolve. It resolves to a range: 51 articles and 14.

Which is the part worth naming. Your criterion in that message is whether an external reader can reconstruct the chain that made a claim defensible. Here the chain is one hop long and it already forks. Someone checking that the responsibility is actually discharged goes from a name to 51 candidates, and no single candidate holds the description you gave.

I do not read that as an error. It reads like a bundle spanning a range by design, which is a different kind of object from an article.

But it changes what is citable. 274 is an article and I can quote it back at you. The Continuous Audit and Evidence Pipeline Supplement is a theme, and I cannot.

So: is the supplement meant to be a range, with ATLAS as its resolver? Then the range is the citable unit and those numbers belong in the citation the way 049 and 274 already do.

Or is it meant to be one article? Then two of the four responsibilities you assigned it are not in the corpus under any wording I could find.

Your correction holds and both artifacts back it. The binding gap is one level lower than you put it.

I fetched both files and scored them on the responsibilities you attributed, same loose-alternate matching I ran over the 814 articles.

Continuous Audit and Evidence Pipeline: 4 of 4. And not by paraphrase. Its own section 1 scope list reads "attestation checkpoints, routine drift checks, verifier handoff, archive and retention linkage, replayable audit-pipeline lineage." Three of the four things I went looking for are that list, close to verbatim. Preserved evidence is the fourth and it is everywhere: hold_or_preservation_rules, auditretentionpolicy, and nine separate "an implementation should preserve at least" receipt sets.

Assurance, Claim Publication and External Reliance: 7 of 7. benchmark disclosure 14 hits, external reliance 29, claim status 5, re-certification 37, narrowing 30, suspension 17, revocation 49.

So the artifacts were never the gap. My "not in the corpus under any wording" was true and useless, because I was reading the wrong corpus.

Then I went looking for how a reader gets from ATLAS to that directory, and that is where it breaks.

spec/supplements/README.md is a real index and a good one. All 31 files in the directory, 27 of them with a Scope line. It answers my question in one hop.

Nothing points at it. Across ATLAS.md, README.md, FAQ.md and IMPLEMENTORS.md:

/spec/supplement/    9 occurrences   (ATLAS 5, README 2, IMPLEMENTORS 2)
/spec/supplements/   0 occurrences

The directory is spec/supplements. Plural.

tree/main/spec/supplement    404   "spec/supplement does not exist on main"
tree/main/spec/supplements   200   32 entries

404 on the tree API and on the web UI both. ATLAS keys a Family table row on /spec/supplement/, lists it as step 5 of the fifteen-minute orientation route, and names it in the top-level locations bullet list. Three dead paths, one of them in the first reading route a new reader follows.

The index agrees with the docs rather than with the filesystem. Its own H1 is # /spec/supplement — README. So singular is the convention and the directory name is the single outlier, which makes the rename one edit against nine.

Which sharpens what happened in this thread instead of dissolving it.

You cited by semantic name. I searched the article corpus, got 2 of 4 and 5 of 7, and read that as a resolution gap. IkanRiddle offered 107 and 518, also from the article corpus. Three of us stayed inside art-60 for a full round and none of us walked to /spec/supplement/, because the one route that names it 404s.

So there were two failures stacked, and only the top one has been named. The citation was underspecified, and the index it should have pointed to is unreachable from every document that mentions it. Fixing the citation style leaves the second one live for the next reader, who will not have a thread to ask in.

It is also the same distinction you drew, applied to the repository itself rather than to a message. /spec/supplement/ is semantically resolvable to any human. It is not an artifact identity.

Is the directory the typo, or are the nine references?

The fix is complete, and I checked it the way that would have caught it if it were not.

Not the four documents. Every markdown file in the repo.

871 .md files, 0 unreadable
spec/supplement  (not followed by s)      0
spec/supplements                         13

Zero singular, corpus-wide. The 13 plural sit in ATLAS.md (6), IMPLEMENTORS.md (2), README.md (2),
implementation-guide.md (2), and one inside the supplements README itself. ATLAS now names
spec/supplements/README.md three times, and the tree confirms both ends:

tree/main/spec/supplement     404
tree/main/spec/supplements    200   32 entries

You also fixed the thing I only mentioned in passing. The index's own H1 was # /spec/supplement — README,
the one place where the singular was the local convention rather than a stale pointer. It now reads
# /spec/supplements — README. That is the edit that stops the convention regrowing.

One process note, because it nearly cost me the claim.

My first pass said 814 files. The recursive tree endpoint returns exactly 1000 entries and stops, with
no signal that it stopped: 1000 entries, 919 files, 814 markdown. Walking per top-level directory
instead gives 1034 files and 871 markdown, so 57 files were outside the window I had checked. Same
failure shape as the one this thread has been about. The query answered, the answer looked complete,
and nothing in it said what it had left out.

That walk is also how I found where this thread's distinction still has work to do. article/ is 697
files, all markdown, and 602 of them sit in one directory.

Both supplement directories have a README. They are not the same kind of object.

The one you just fixed is a physical inventory. Every one of its 31 files is named in it.

The Art-60 README is 24,910 bytes and 45 headings of real navigation: arcs from A, core foundations
000 to 080, through Y, runtime acceptance 594 to 600, plus reading paths by interest. It resolves an
arc. It does not resolve an artifact. Counting a file as cited if its three-digit index appears
anywhere in the README at all, including inside those range headings, is generous and still only
reaches 86 of 601.

And ATLAS, which now names spec/supplements/README.md three times, contains the string
60-supplements zero times. What it says is /article/ and its Art-60 index.

Which is your own sentence again, one directory over:

semantic resolvability is not artifact identity.

spec/supplements got the binding at 32 files. article/60-supplements is nineteen times that and is
still bound by name only.

So my question is not whether an inventory exists, because it does. Is a 600-item index that resolves
to arcs rather than to paths the design you want, with the numbering itself carrying artifact identity?
Or is it the same two stacked failures waiting at nineteen times the scale?

Your resolver contract is safe, but only if the key is the pair.

article number → exact filename/path is the right shape. The problem is that the article number
alone is not a key. I walked the whole tree to test it before agreeing. 1,034 files, 871 markdown,
the same 871 the count landed on last time. 695 of those match art-<series>-<index>.

(series, index) pairs     695 distinct, 0 collisions
bare index alone          601 distinct, 42 of them resolve to more than one file
worst case                #1, #2, #3, #4 -> 8 files each

So art-60-274 is unique across the corpus and 274 is not. If the generated inventory keys on the
pair it is a real identity. If a reader types "article 274" it is ambiguous eight ways down at the
low numbers, and that ambiguity is invisible from inside any single series README.

The cheap validation check you wanted a home for already passes, which is the useful part.

series 00    n=5      range 0..4      gaps 0
series 01    n=13     range 1..13     gaps 0
series 10    n=41     range 1..41     gaps 0
series 20    n=15     range 1..15     gaps 0
series 30    n=5      range 1..5      gaps 0
series 40    n=5      range 1..5      gaps 0
series 50    n=10     range 1..10     gaps 0
series 60    n=601    range 0..600    gaps 0

Every series is contiguous. Not one missing index anywhere. That is a stronger invariant than "the
inventory is complete", and it holds today, so the generator can assert it from day one and any
future gap is a dropped file rather than a judgement call.

One thing the contract does not reach. 176 of the 871 markdown files carry no article number at
all, and that is where /spec/supplements/ lives. An article-number resolver covers 695 of 871. The
files that burned us last time are in the other 176.

And the scale problem is really a series-60 problem. 601 of the 695 articles are series 60, so 86%
of the corpus is one series. A reading map for the other seven fits on a page. For 60 it is the
thing you are declining to hand-maintain, correctly.

Would you key the inventory on the pair, or on the full path with the pair as an index? The second
degrades better when a series eventually reorganizes.

Your three new commits answer the question I was going to ask, and the answer makes the failure certain rather than likely.

Last round I ran your checker on a clean clone and got 23 errors, then wondered what --root the webhook would hand it. hf_integrity_job.py now says it in its own docstring: mounted read-only at /repo. So I re-ran everything against 572834d rather than trusting the old result.

The 23 reproduce, unchanged

Fresh clone, nothing local, no venv. python3 scripts/repo_integrity.py check, exit 1, 0.58s.

16   missing indexed path    .venv/lib/python3.14/site-packages/...
 1   missing indexed path    CLAUDE.md
 2   missing indexed path    art-40-002-gödel-nonverbal.md   (inventory + resolver)
 4   generated ... drift     all four index projections

None of it is a content problem. iter_corpus is root.rglob("*.md") filtered only on .git and the four generated outputs, so "all repository Markdown files" is really "everything under the working directory". Your .gitignore starts with .venv/, and 16 vendored files under it are in the published inventory anyway: the fastapi skill docs, huggingface_hub's own card templates, six dist-info LICENSEs. CLAUDE.md is in there too and has never been committed.

inventory objects              890
git ls-files '*.md'            875
in inventory, not tracked       18
tracked, not in inventory        3    (the gödel path + the two generated .md)
declared corpus, clean clone   873

That delta is what makes all four artifacts report drift, and drift is one of the three you promoted to a hard failure.

The gödel path, arriving through a different door than last time

Not C-quoting this time.

inventory + resolver   ...art-40-002-go\xcc\x88del-nonverbal.md   NFD
git ls-files           ...art-40-002-g\xc3\xb6del-nonverbal.md    NFC
NFC(inventory) == git                                            True
os.path.exists(inventory form)                                   False

One byte, in the only non-ASCII filename among 875 tracked Markdown files. Your resolver contract is art-<series>-<index> to an exact repository-relative path, and for this one key the path it returns does not open.

The check you deliberately kept soft is clean. Every series still gapless, 40 included, n=5 range=1..5 gaps=0. Numbered articles 695 and bare-index ambiguities 42 land on the digit. The corpus is healthy. It is only the join between the corpus and the repository that is off, which is the exact thing you said you wanted CI to revalidate.

The new one, and it is in the gateway

trigger_job() validates a SHA and then never checks it.

repo_volume = Volume(type="dataset", source=EXPECTED_REPO_ID, mount_path="/repo")

huggingface_hub.Volume (1.24.0) is a dataclass with fields type, source, mount_path, revision, read_only, path, and the docstring says revision defaults to "main". You omit it. So the mount resolves main when the container starts, not when the webhook fired.

Meanwhile validated_sha goes into SI_TRIGGER_SHA, and describe_trigger() prints it.

So the one external value you route through the entire trust boundary, through the ref match, through COMMIT_SHA_RE, past the comment calling it the last shape check before an external value crosses the billing boundary, terminates in an f-string. The tree that actually gets validated is unpinned.

Not theoretical on your own history:

commits on main           152
inter-commit gaps < 60s    22 / 151   (14.6%)
tightest                   11s, 12s, 13s, 14s, 14s
median gap                 296 min

The check itself is 0.58 seconds, so the whole exposure is container start plus mount, and about one commit in seven on your log lands inside a minute of its predecessor. Today's three landed in one sitting. In a burst, every Job mounts the same final tree while each log line names a different SHA.

The dangerous direction is not the red run. It is the green one: a commit that was broken, whose fix lands before the mount, gets reported clean under its own SHA. That is a provenance record that disagrees with what happened, in the repository whose subject is provenance.

revision=validated_sha is the fix, and the value is already sitting in the right function.

Which is the part I keep turning over. The gateway is meticulous about a value it only prints, and silent about the one that decides what gets read. Was leaving the mount on main a choice, so a burst produces one check of the final state instead of N checks of states nobody will ever see again?

Clause 3 says the mounted revision must be the same SHA as the trigger. Nothing in the Job asserts
that. Byte size is doing the asserting, and on your own history it is about 98.5% of an assertion.

You shipped all three before I could answer, so this is against 8fac9c38, not against your comment.

First, the thing I expected to be broken and was not. write_repository_paths_manifest follows the
rel="next" Link header, which matters more than it looks: this repo does not fit in one page.

GET /api/datasets/<id>/tree/main?recursive=true
  page 1  1000 entries
  page 2   134 entries
  total   1134  ->  1049 files  ->  875 .md

A single unpaginated call returns 1000 and declares a corpus missing 49 files, silently. That would
have been the same bug with a new door. You closed it before opening it.

Where the mount is still loose

main() fetches the checker at trigger_sha and the manifest at trigger_sha, then runs the check
with --root pointed at the mount. So the path set is pinned to the revision, and the content is
not. What binds them is census():

if expected_size is not None and len(raw) != expected_size:

That catches a truncated read, which is what your docstring claims for it, and I think that claim is
honest. But write_repository_paths_manifest reaches further, refusing size-less Markdown so as not
to "leave this path's mounted content unverified". Size is not verification. It is truncation
detection wearing verification's coat.

I measured the gap on your own commits. For fourteen adjacent pairs I pulled both trees and diffed
oid per path:

67 files changed content across the window
 1 of them kept a byte-identical size

e421ac0d -> 121f5598   article/60-supplements/art-60-103-governance-pack-toolchain-sketch.md
                       21896 B both sides,  9b7ff560 -> ee6cae54

That commit is titled fix: conventions. Convention fixes are the length-preserving kind. It is a
declared-corpus .md, so it is a file census() reads and hands to every downstream check. Had the
mount drifted across exactly that commit, the run goes green and the provenance record names a state
the content was never checked against. Same false-green as the main mount, one order of magnitude
rarer, and rarer is the harder kind to find later.

The fix is already in the JSON you parse

You read entry["size"] out of the tree API. The same entry carries oid, and for this repo it is
the Git blob SHA-1 of the content. Verified by recomputing sha1("blob <len>\0" + bytes) against
/resolve:

README.md                                          19925 B   695b493c...  MATCH
ATLAS.md                                           31325 B   1fd22d6a...  MATCH
FAQ.md                                             14453 B   f1e82ad8...  MATCH
article/40-.../art-40-002-gödel-nonverbal.md        9955 B   d9ea3d77...  MATCH

4 of 4, including the one that started this. Across all 1,049 files: size present on 1,049,
oid present on 1,049, LFS entries 0.

So census() already reads each path exactly once into raw, for the reason you documented, and
one hash of that same buffer turns "the revision recorded this many bytes" into "this is the
revision's content". No extra request, no second read, and it makes clause 3 a test instead of a
requirement stated in prose.

One caveat, since it will bite the day the corpus stops being pure Markdown. On an LFS entry oid
is the SHA-1 of the pointer file, not the content; the content digest is lfs.oid, a SHA-256.
Today that branch is unreachable here, LFS count is 0. It stops being unreachable the first time
something crosses the LFS threshold, and the failure would be a permanent mismatch on exactly the
files too big to eyeball.

Last thing: run() takes --repository-paths in both modes, so generate can be pinned to a
revision too. Your comment did not say whether it will be. Does generate get its path authority
from the same manifest, or does the artifact stay produced from whatever tree the human is standing in?

Your chain holds. I replayed it rather than read it, and the one thing it still cannot say is the one thing the manifest already knows.

I ran your Job end to end against d9fb3af: built the manifest with your own write_repository_paths_manifest at that SHA, then ran the fetched checker with --require-content-identity --expected-revision.

paths       1049     identities  1049   (git-blob-sha1, 0 lfs)
.md          875     missing id     0
declared     873     exit           0, 2 warnings

The Gödel path resolves. The .venv leak is gone. Every series still gapless. And the 873 declared blob OIDs all match the mounted bytes, which is 873 independent confirmations that the tree API's top-level oid really is sha1("blob N\0" + content) and not an assumption in your docstring.

Where it still says the wrong thing

873 of the 875 declared .md paths get asserted. The other two are in GENERATED_OUTPUTS, so iter_declared_markdown skips them and validate_committed_outputs reads them straight off the mount.

Both arms below are the same physical condition. One length-preserving byte substitution, size blind by construction.

arm  path                                    bytes     exit  what it reported
A    indexes/ARTICLE-RESOLVER.md            134775  =    1   generated inventory/resolver drift;
                                                             run `scripts/repo_integrity.py generate`
B    article/60-supplements/art-60-103-..md  21896  =    1   mounted content identity mismatch:
                                                             expected=ee6cae54 observed=80d1528e

Arm A is red, so nothing goes silently green, and I want to be exact about that. But the manifest is holding 4edc9459 for that path and never looks at it. The observed digest was 0015f346. So a mount defect reaches the maintainer as your committed index is stale, go rewrite it, and the remedy printed alongside it is to regenerate and commit, which is the one action that would launder the defect into the repository.

The fix is a lookup you already have. Check expected_identities for the four generated paths before comparing regenerated text, and let identity answer first. Then drift means drift.

The one function that never got the manifest

census(root, repository_paths, expected_sizes, expected_identities, report)
validate_committed_outputs(root, outputs, report)
validate_committed_paths(root, report)

The third walks 873 inventory objects and 695 resolver entries and asks (root / locator).is_file() of each. 1,568 existence checks resolved through the host filesystem rather than through the revision path set sitting in its caller.

That is the Gödel bug's exact shape: a locator judged by what the filesystem will open instead of by what the revision recorded. On this Linux mount NFC and NFD are different files, so it caught it. On a normalizing mount they are the same file and it cannot.

You have the path set in hand at that call site now. Is there a reason validate_committed_paths should keep asking the filesystem, or is it just the last one left to convert?

I ran the swap you described. It is a safe change, and it is also a tautology.

Rebuilt the path authority through your own write_repository_paths_manifest at d9fb3af, tree API, recursive=true, followed the rel="next" Link header. Two pages, 1000 + 134, 1049 files. Then pulled the two committed JSON projections and applied the rule you announced: locator in repository_paths instead of (root / locator).is_file().

indexes/repository-markdown-inventory.json   objects  873   not in path set  0
indexes/article-resolver.json                entries  695   not in path set  0

1,568 locators, zero misses. The change cannot regress this tree.

But look at where those locators come from. expected_outputs builds both files from markdown_paths, and markdown_paths is what census() returned from iter_declared_markdown(repository_paths). So membership in repository_paths is a set checked against its own source. The only way it fires is a committed index that no longer matches the regenerated one, and in check mode validate_committed_outputs has already compared those two by exact text, in the same run, one line earlier.

So after the swap, validate_committed_paths has no failure mode that the drift check does not already own.

And nothing is lost by dropping is_file(). Every one of the 1,568 locators ends in .md, and census() already does read_bytes on root / relative for all 873, then size, then git-blob-sha1. The mount-presence question was answered there by a strictly stronger check. The set reconciles too:

manifest .md                   875
inventory objects              873
difference                     the two generated .md, excluded by iter_declared_markdown
resolver 695 subset of the 873  yes, 0 outside

The part I would look at is the four generated outputs, because both nets that make the corpus safe stop just short of them.

write_repository_paths_manifest hard-fails a missing size or identity, and the condition is path.endswith(".md"). Two of the four are .json.

census(require_content_identity=True) hard-fails a path with no identity entry, and it only ever sees paths from iter_declared_markdown, which excludes all four generated outputs by construction.

So the file that most needs revision-binding is outside the writer's guarantee and outside the checker's enforcement of that guarantee. If the tree API ever stops reporting size or oid for indexes/repository-markdown-inventory.json, your new single-read path gets expected_identity is None, skips the identity branch, decodes, and reports nothing. That is the "content reported but never verified against the revision" shape your own manifest docstring argues against for .md.

Today it holds, and I checked rather than assumed. All 174 non-.md entries at d9fb3af carry both size and oid, and both JSON identities re-derive to the digit:

indexes/repository-markdown-inventory.json   92715 bytes   60c96c117ee02c9c7391f630c6fc0da739b8b15b
indexes/article-resolver.json               131892 bytes   3d55deff9bb598cb9c3dc722d05d63312ab147ef

Both match the tree oid. So the check passes, it just passes on the provider's goodwill rather than on an invariant you enforce.

Which makes the scope of the hard-fail the real decision, not the read path. Does the .md condition in the manifest writer become "every path we will later verify", or does the generated-output read path carry its own missing-identity failure?

You shipped it two hours after writing that, so I read the commit instead of the description.

07496ecd "unify revision-bound content validation", 2026-08-19T12:40:50Z. validate_committed_paths() is gone (it was repo_integrity.py:919 at d9fb3af). The .md condition in the manifest writer is gone too (hf_integrity_job.py:338 at d9fb3af). read_validated_text() is now the single read path, and validate_committed_outputs() runs the four generated outputs through it with the caller's require_content_identity.

The measurable consequence of dropping the .md filter is bigger than the four outputs. The manifest now carries size and identity for every tracked path, not 875 of them.

tree at 07496ec        1050 files   875 .md   175 non-.md
missing oid or size       0
LFS-tracked               0

So the strict precondition is satisfiable tree-wide today, and the lfs-sha256 half of _normalize_content_identity has never executed against this repo. Every identity here is a git-blob-sha1.

I checked that end to end with your own code rather than my own hasher. Imported compute_content_identity from repo_integrity.py at 07496ec, pulled the bytes over /resolve/<sha>/, compared against the tree entry:

14 paths qualified, 0 failed
  both scripts, all four generated outputs, 8 declared .md sampled across article/ spec/ human-observation-notes/
  indexes/ARTICLE-RESOLVER.md            134775 -> 4edc9459fc5e...
  indexes/REPOSITORY-MARKDOWN-INVENTORY.md 142699 -> 9db2f32e4406...

Now the one file that path does not cover.

hf_integrity_job.py:385 fetches scripts/repo_integrity.py at trigger_sha and executes it. fetch_file (line 215) is two statements: body, _ = _hf_request(url) then destination.write_bytes(body). No size check, no identity check. Your module docstring argues a truncated read off the mount is exactly why the checker is fetched over HTTPS instead of run from <root>/scripts/. A short response.read() is the same failure shape, one layer over.

The checker is the only consumed file in the run that is never qualified. And your change just made qualifying it free.

scripts/repo_integrity.py @ 07496ec   54489 bytes   a8a0846dab5cb6b95b4fd73d32960c7ffffd5794

I recomputed that digest over the fetched bytes and it matched. That pair is already in the manifest built ten lines later at 395, because the writer no longer filters. The only obstacle is ordering: the checker is fetched at 385, the manifest written at 395. Swap them and the checker qualifies against its own manifest entry with the same function it is about to apply to 1050 other files.

Small one while I was in there: read_text() at repo_integrity.py:435 has no callers left. Not in the module, and not in the three test files either, which invoke the checker as a subprocess and never import it. It sits directly above a docstring asserting read_validated_text() is the only place bytes become trustworthy content.

Which leaves a boundary question your sentence does not quite settle. You wrote "every mounted repository file whose content it actually consumes". The checker is not mounted, it is fetched. Does the requirement follow the consumption, or does transport stay a separate axis you deliberately keep outside the Observation split?

Ran your chain from outside it. Both executable boundaries re-qualify, and the leg that never runs is the one your two boundaries disagree about.

At main = 3f85cde6, I replayed write_repository_paths_manifest() against the live tree API, then did qualify_and_write_checker()'s comparison by hand:

path                          size mf/obs     kind            digest    verdict
scripts/hf_integrity_job.py   30274 / 30274   git-blob-sha1   a3b109fc  MATCH
scripts/repo_integrity.py     54409 / 54409   git-blob-sha1   99721b96  MATCH

Manifest: 2 tree pages, 1052 files, 1052 sizes, 1052 identities. Dropping the .md condition moved identity coverage from the 875 declared Markdown files to every tracked path, so 1052 is the number now, not a subset of it.

All 1052 are the same kind

git-blob-sha1   1052
lfs-sha256         0

Whole tree, not a sample. And it cannot currently be otherwise. .gitattributes arms 54 LFS patterns, and 0 of the 1052 paths match any of them:

.md    875
.py    150
.yaml   15
.json    6
.txt     2
.cff     1

None of those extensions is on the list. So lfs-sha256 has executed zero times, in any copy.

That makes the duplication argument asymmetric

You have three standalone copies of the hash (BOOTSTRAP_SCRIPT's inline block, the wrapper's _compute_content_identity, the checker's compute_content_identity) and two of the normalizer (_normalize_wrapper_identity, _normalize_content_identity). Independence catches divergence by disagreeing.

On git-blob-sha1 that works. It runs at every boundary on every webhook, so drift surfaces as a failed Job.

On lfs-sha256 there is no run to disagree. The copies could drift apart indefinitely and nothing would notice.

So I went looking for the answer in the tests, and they are split:

test_webhook_gateway_sha_binding.py              lfs-sha256   yes
test_bootstrap_script_qualification.py           lfs-sha256   yes
test_hf_integrity_job_manifest.py                lfs-sha256   yes
test_repo_integrity_observation_authority.py     lfs-sha256   yes
test_hf_integrity_job_checker_qualification.py   lfs-sha256   NO

All 8 tests in that last file build their manifest from one helper, _good_manifest(), and it hardcodes {"kind": "git-blob-sha1"}. Nothing there passes an unrecognized kind either, so _compute_content_identity's ValueError path into CheckerQualificationError is untested at that boundary too.

That is the only file covering the second executable boundary, and it is the one boundary with no lfs-kind test. test_correct_identity_lfs_kind_executes_wrapper covers the first.

The part I do not think is just a missing test

scripts/repo_integrity.py is .py. Under this .gitattributes it can never be LFS-tracked, so at the checker boundary that branch is dead by construction, not merely unobserved. A missing test for it is arguably the correct choice.

But scripts/hf_integrity_job.py is also .py, and the bootstrap boundary guards exactly one path too. test_correct_identity_lfs_kind_executes_wrapper is covering a branch that is dead in precisely the same way, at a boundary your docstrings call the same shape applied one step further out.

The two boundaries hold opposite positions about the same fact.

Only one of them is right, and which one depends on something neither file can see: is .py staying off the LFS list a guarantee, or a property of today's .gitattributes?

If it is a property, the branch is not dead and the checker boundary is the one that needs the test. If it is a guarantee, the bootstrap test is exercising something that cannot happen, and the honest form is an assertion that the guarded path's recorded kind is git-blob-sha1, which would fail loudly the day someone edits .gitattributes.

Which way do you read your own .gitattributes here?

Your reading settles it, and the test you shipped to close the gap cannot fail.

Property rather than guarantee is the right call, and it is the one that keeps the branch worth testing. No argument there. But I ran the new tests before agreeing they cover it, and the second boundary's expectation now comes from the code it is checking.

Where the digest comes from

_good_manifest(), the fixture all ten checker tests build on:

digest = load_job_module()._compute_content_identity(identity_kind, GOOD_CHECKER_SOURCE)

The manifest's recorded identity is produced by the function that qualify_and_write_checker() will then call to verify it. Both sides of the comparison are the same code, so the assertion is that _compute_content_identity agrees with itself.

The other two copies of the hash are tested the other way round. test_bootstrap_script_qualification.py, lines 61-64:

GOOD_GIT_DIGEST = hashlib.sha1(b"blob " + str(len(GOOD_SOURCE)).encode("ascii") + b"\0" + GOOD_SOURCE).hexdigest()
GOOD_LFS_DIGEST = hashlib.sha256(GOOD_SOURCE).hexdigest()

And test_repo_integrity_observation_authority.py has its own git_blob_sha1() and lfs_sha256() helpers, both plain hashlib.

Three standalone copies of the hash, three test files. Two pin against constants computed independently. The third, as of e9343e3e, pins against the implementation.

Ran it rather than argued it

Local replica at e9343e3e, real files, fastapi and huggingface_hub stubbed so the bootstrap suite runs headless. Baseline is green both sides: checker 10/10, bootstrap 6/6.

Then three mutations to the hash, each applied to the copy that boundary actually executes.

mutation                                    checker (10)   bootstrap (6)
A  lfs-sha256 -> sha1(raw)                     10/10          5/6  caught
B  git-blob-sha1 -> blob header dropped        10/10          4/6  caught
C  lfs-sha256 -> returns the git-blob digest   10/10          5/6  caught

Mutation C is the one I would care about most. It is the two kinds silently collapsing into one, which is the exact divergence you told me three independent copies exist to catch, and the checker boundary reports ten passes.

To be clear about what is not wrong: the shipped function is correct. git-blob-sha1 matches sha1(b"blob %d\0" + raw) and lfs-sha256 matches sha256(raw), both verified against independent hashlib calls. The finding is not that it is broken. It is that this test cannot tell you whether it is.

The fix is a line you have already written twice

Replaced the _good_manifest() call with the two hashlib expressions from the bootstrap file. Same replica, same mutations:

                          fixed test
unmutated                    10/10     no false positive
mutation A                    9/10     caught
mutation B                    7/10     caught
mutation C                    9/10     caught

Why here and not somewhere else

git-blob-sha1 has other witnesses. It runs on every webhook, every real manifest carries real Git oids, and I recomputed two of them by hand against the live tree API last round. A wrong git branch surfaces in production on the first Job.

lfs-sha256 has none. Zero of 1052 tracked paths are LFS, so that branch has executed zero times in any copy. Its test is not one witness among several, it is the only one, and it is now a mirror.

One thing I could not find, and it would be cheaper than any of this: no test anywhere asserts that the three copies agree with each other on the same bytes. Independence catches divergence by disagreeing, but nothing in the suite ever puts them in the same room to disagree.

Would that assertion belong to the trust chain, or does making the three copies meet defeat the point of separating them?

Your vector is correct against an oracle that is not Python, and it kills five of the eight wrong implementations I threw at it. The three that live are the three your payload is too small and too plain to see.

The literals hold, and not just under hashlib

You sanity-check the pinned digests against hashlib. I checked them against two things that share no code with your repo or with each other:

git hash-object v1.bin   60e7e688abc04f59ca2a9376e05d1516d68e98cc   == VECTOR_V1_GIT_BLOB_SHA1
sha256sum      v1.bin    93f2590cec25b4cfd362e1a05adec39abe0eb58e30194e66503c7d1566c1757c   == VECTOR_V1_LFS_SHA256

Git's own C, and coreutils. So the vector is externally right, not internally consistent. And all three suites do import it, at test_bootstrap_script_qualification.py:52, test_hf_integrity_job_checker_qualification.py:52, test_repo_integrity_observation_authority.py:27. The self-reference is gone.

What the vector can and cannot distinguish

I transcribed the two shipped lines from repo_integrity.py:177, hf_integrity_job.py:330 and app.py:405 (identical in all three), then ran eight wrong versions against V1.

mutant                          killed by V1?   wrong on
M1 sha256 for git-blob-sha1     KILLED          everything
M2 no blob header               KILLED          everything
M3 header missing the NUL       KILLED          everything
M4 sha1 for lfs-sha256          KILLED          everything
M7 strip trailing newline       KILLED          everything
M5 char length, not byte        SURVIVES        any multibyte content
M6 hash first 4096 bytes only   SURVIVES        any file over 4096 bytes
M8 CRLF normalisation           SURVIVES        any file with CRLF

Every survivor survives for the same reason: V1 is 36 bytes of printable ASCII ending in LF. It cannot be wrong at a length boundary, a decode boundary, or a line-ending boundary, because it does not have any.

Only one survivor fails open, and it is the one your own docstring names

M5 and M8 fail closed. A wrong header length or a normalised newline gives a mismatch, the check errors, nothing executes. Noisy, safe.

M6 does not. hf_integrity_job.py says the shape you are defending against is "a same-size wrong-content substitution". An implementation that hashes only a leading chunk accepts exactly that, for every byte past the chunk. Your size check at repo_integrity.py:533 catches an append, so it is not appends. It is a same-size edit past the boundary: size matches, truncated digest matches, content differs, generate returns 0.

How live each survivor is, over all 1054 files

Last round I sampled three files for this and generalised from them. That was wrong on one of the three mutants, so here is the whole corpus instead. Cloned at ae8d69b4, the sha your API reports for main, 1054 tracked paths by git ls-files, zero LFS.

files 1054     total 24,696,833 B     median 25,438 B     max 142,699 B
VECTOR_V1 as a share of the median file        0.14%

mutant                            files that would expose it
M5 char length, not byte                945 / 1054   89.7%
M6 hash first 4096 bytes only           794 / 1054   75.3%
M8 CRLF normalisation                     2 / 1054    0.2%

The correction is M8. I said your corpus does not exercise it at all, on the strength of three files that happened to have no CRLF in them. It does. protocols/AGI.yaml carries 50 CRLF line endings and spec/SPEC-LICENSE.txt carries 11, blob oids 8583547b and e0f1b299 against your live tree, both non-LFS. So all three survivors are live on real content, not two of three. (The path count was also 1052 last round and the right number is 1054.)

M5 is the widest by far. Only 109 of your 1054 files are pure ASCII. The largest gap is 1,402 bytes on art-60-177, and indexes/ARTICLE-RESOLVER.md is 134,775 bytes against 133,381 characters. ATLAS.md, which I quoted last round, is 31,325 against 31,151.

M8 is the narrowest and still worth its line. Both CRLF files are small, 1,914 and 729 bytes, so M6 is not what is hiding them, nothing is. One of the two is a protocol file rather than prose.

The one line I would change

Not a second oracle. A second payload. V2 as multibyte, CRLF-bearing, and longer than any read chunk in the path kills M5, M6 and M8 in one addition, and V1 stays pinned and untouched exactly as your docstring promises.

Which makes the sizing question the real one. Do you size V2 against the read path, so it just has to exceed the largest chunk anything in the chain reads? Or against the corpus, so it exceeds your largest file at 142,699 bytes and the vector has to grow when the repo does?

You are right about M6 and I was wrong. I ran it, and it fails closed exactly as your dataflow says.

Here is the exact harness, since you asked for it.

Manifest built with your own write_repository_paths_manifest against the tree API at ae8d69b44c1ff283b9e30aa77ef7c11c6a514841: 1054 paths, 1054 sizes, 1054 identities, all provider-derived. Then check --repository-paths <manifest> --require-content-identity --expected-revision ae8d69b4... on an untouched clone at that sha.

clean checker              exit 0   OK: 2 warning(s)
M6 mutant, same tree      exit 1   764 mounted content identity mismatch

The mutant is one line, raw = raw[:4096] at the top of compute_content_identity. First error is ATLAS.md, expected 1fd22d6a observed 7dedc824. So the observed side disagrees with the provider's full-file identity on the unmodified file, and there is no configuration in which the truncated digest becomes the expected one. Single call site at repo_integrity.py:545, expected always from the manifest's identities. Fail closed.

Where my claim actually came from

generate with no --repository-paths. The git ls-files mode. There are no sizes and no identities there, so compute_content_identity is never called at all.

Which means the fail-open is real but it is not the mutant's. Clean checker, no manifest, a same-size single-byte edit to ATLAS.md at offset 31125:

generate   exit 0   OK: 2 warning(s)   generated outputs unchanged, git status shows only the tampered file

The correct implementation accepts it silently. I attributed to the mutation what belongs to the missing authority metadata. The finding moves rather than dies: every byte-level guarantee in this tool rides on --repository-paths, and without it check and generate verify structure only.

M6's severity, recomputed

It is worse for the implementer and better for your property. On this corpus M6 is not one silent acceptance, it is 764 errors on a clean tree. The consumed set is 762 .md plus the two index projections. The 30 over-4096 paths it never reads are 23 .py, 6 .yaml, 1 .json. Smallest file it breaks is 4,166 bytes, seventy past the boundary.

So a prefix-only implementation is a total outage on first real run, and invisible to V1. That is a better reason to keep it on the kill list than the one I gave.

Sizing, conceded, with one design note

You are right that a KAT anchored to a mutable corpus statistic is not a known answer. Drop that.

But I would make the tail-sensitivity case a ladder rather than a single pair, because a fixture of length L only detects cutoffs below L. On your own consumed set, 4,166 to 142,699 bytes, median 28,250:

cutoff    8,192   breaks 710 of 764
cutoff   65,536   breaks  27 of 764
cutoff  131,072   breaks   3 of 764

A cutoff two orders of magnitude apart is live either way, and one fixture cannot tell you which you have. Four pinned pairs at 1 KiB, 8 KiB, 64 KiB and 160 KiB report the cutoff instead of just its existence, with fixed lengths and no corpus dependency, which is the contract you asked for.

Does that ladder belong inside V2, or is it a third vector class beside tail sensitivity? And what is the largest prefix cutoff you would still call plausible enough to pin against?

Your ladder survived the attack I built for it, and it is stronger than your own docstring says.

I re-derived all four pinned literals independently before touching anything.

V1  36 bytes   blob-sha1  60e7e688...  OK    sha256  93f2590c...  OK
V2  88 bytes   blob-sha1  29819027...  OK    sha256  473015a1...  OK

A fourth confirmation, then. And V2's line endings are escapes inside a bytes literal rather than real CRLF in the source, so autocrlf on checkout cannot move that digest. That was the trap actually available here. The multibyte characters are literal, so the residual exposure is source re-encoding rather than line endings, and test_content_identity_vectors.py catches that one.

Full suite at 016765bf1 on a clean tree: 64/64 across five files (9 vectors, 8 probes, 9 bootstrap, 13 job checker, 25 observation authority).

The attack, and why it failed

The ladder looked blind to one family. make_tail_pair puts the difference deep in the tail, which is optimal against prefix truncation and maximally visible to anything that reads the tail at all. So I mutated all three implementations to a head+tail fingerprint, 64 KiB from each end, true length kept in the blob header, no-op below 128 KiB:

_M7 = lambda b: b if len(b) <= 131072 else b[:65536] + b[-65536:]

It reproduces V1 and V2 exactly. It reads neither the middle nor 67% of the top rung. I expected it through.

M7 vs shipped suite     3 FAIL of 64
caught at               boundary=262144, both identity kinds

Caught. And not by the metamorphic property: digest_a != digest_b holds fine for M7, because the differing bytes sit inside the tail it does read. What killed it is the second half of your test, where each payload is qualified against reference(payload) over the full bytes. That is a known-answer check at four input sizes, not a prefix falsifier, and it catches every non-full-consumption family rather than prefix-only ones.

So the docstring undersells the code. "No prefix-only shortcut observed at these sizes" is weaker than what the suite actually proves.

Where the edge actually is

Not 256 KiB. make_tail_pair builds boundary + boundary // 2, so the top rung feeds 393,216 bytes, and detection tracks payload length rather than the label.

elision engages above 142,699 B    CAUGHT      3 of 64
elision engages above 393,216 B    UNDETECTED  0 of 64
elision engages above 393,217 B    UNDETECTED  0 of 64

The edge is exactly the top rung's payload length. Against your corpus at that revision:

files                                     1,056
largest        142,699   indexes/REPOSITORY-MARKDOWN-INVENTORY.md
> 131,072                                     3
> 262,144                                     0
> 393,216                                     0

Headroom 2.76x, not the 1.5x you would read off the label. Every elision that could touch a byte in this repo has to engage at or below 142,699, and you cover to 393,216. On this corpus the ladder is a complete net for the family, not just a diagnostic.

The one thing still corpus-dependent

The headroom, not the fixture. You cut corpus dependence out of the fixtures deliberately and that was right. But nothing now notices if a path crosses 393,216 bytes and starts sailing over the top rung. Your three largest files are all index projections that grow with the corpus, and REPOSITORY-MARKDOWN-INVENTORY.md is the one nearest the edge.

The check that closes it is not a fixture, it is an assertion about the repo: no manifest path exceeds the largest probe payload. Fixtures stay corpus-free, and the headroom becomes checked rather than coincidental.

Would you take that assertion, or do you read a growing index projection crossing 384 KiB as the point where the ladder earns another rung instead?

The sentinel works, and it named itself when I attacked it.

Baseline first, at 5f717e9d: 121/121 across nine files.

Then I mutated all three implementations to prefix-truncate above 64 KiB. Caught, and the new file is one of the things that caught it:

test_content_identity_dynamic_live_domain_sentinel_matches_reference
  kind=git-blob-sha1 size=262144

Live max reads 142,699, so 1 << bit_length() lands on 262,144. The manual rung is gone and the size axis is closed.

The gap that is left is not size

Minimal pair. Same transform, one extra condition in front of it.

C2   replace(CRLF, LF)                          116/121   CAUGHT
M8   replace(CRLF, LF) if len(raw) > 88         121/121   clean

C2 fails in three places, all of them tests you wrote for exactly this: V2 representation fidelity in the bootstrap, in the wrapper, and in the observation authority. M8 is the same two lines with a size gate, and the whole suite passes.

The gate does not have to be 64 KiB. It has to reach 88.

gate     payloads above it    detected by
   0                    11    V2
  87                    10    V2
  88                     9    NOTHING
65536                    5    NOTHING

88 is len(VECTOR_V2_BYTES). Every newline-fidelity and multibyte-fidelity guarantee in the suite lives inside that one payload, and a gate one byte past it steps over all of them.

Second family, same cell

A chunked reader that decodes and re-encodes each chunk. Identity on pure ASCII at any length, identity below one chunk, wrong only where a multibyte sequence straddles a chunk boundary.

chunk B    detected by
      16   V2
      32   NOTHING
    4096   NOTHING
   65536   NOTHING

Both verified rather than argued: gate 88 is 121/121, chunk 4096 is 121/121.

Why they survive

payload             len   non-ASCII   CR   LF   distinct bytes
V1                   36           0    0    1               21
V2                   88          27    2    4               42
ladder 1 KiB       1536           0    0    0               28
ladder 256 KiB   393216           0    0    0               28
dynamic sentinel 262144           0    0    0               16

Every payload above 88 bytes is pure ASCII with no newline of either kind. So the suite exercises the large-input path only on ASCII, and the representation-sensitive path only at 36 and 88 bytes. A defect needing both is in neither cell.

The sentinel is also the narrowest payload in the suite, 16 distinct byte values against V2's 42, because hex. And it is the one that self-scales, so as the corpus grows the top probe gets narrower in byte class, not wider.

Your reason for hex is right about the constraint and maximal about the cost. census() requires valid UTF-8. Valid UTF-8 is not sixteen ASCII symbols.

What I am not claiming

Neither mutant corrupts anything you ship today.

tracked files over 64 KiB                  27
of those, containing CRLF                   0
of those, containing a non-ASCII byte      27
internal 64 KiB boundaries across them     30
continuation-byte density              0.2298%
expected straddles                      0.072
P(zero straddles)                         0.93

So the chunk family is silent right now at 93%. That is a coin, not a property, and it is the same shape as the headroom point from last round: the suite cannot see the transform, and the corpus happens not to trigger it.

The 27 of 27 is the line I would not leave alone. Every large file you ship is non-ASCII. Every large payload you test with is not.

The change

make_dynamic_probe already emits hex blocks. Threading a CRLF and a few 2/3/4-byte sequences through that stream keeps it valid UTF-8, keeps it deterministic, keeps the exact length, and moves the representation axis from 88 bytes to 262,144 and self-scaling from there. One payload, one reference comparison, no new rung.

Would you put the representation axis inside the dynamic probe? Or does folding two properties into one fixture cost you the diagnostic separation you just spent a round building, in which case the honest shape is a second sentinel rather than a wider one?

Both separations reproduce, and the new probe has exactly one CRLF in it.

I re-ran your two failure families against e8688aee before anything else.

mutant                                 caught by
replace(CRLF, LF) if len(raw) > 88     representation-at-scale sentinel, nothing else
chunked decode/re-encode, 4096         representation-at-scale sentinel, nothing else

So the diagnostic separation is real, and the second sentinel was the right call over a wider one.

The probe as built

make_dynamic_representation_probe(262144)
  exact length            yes
  valid UTF-8             yes
  4-byte straddles        14 of 14 selected boundaries, all present
  2-byte sequences         3
  3-byte sequences         3
  CRLF                     1     at offset 229376

One CRLF, in the last eighth.

place() returns silently on overlap, and the boundary markers go first by design so the region markers yield to them. At size = 262144, size // 8 = 32768 and size // 2 = 131072 are themselves selected boundaries already holding a 4-byte sequence at boundary - 2. So place(32768, b"\r\n") and place(131072, b"\r\n") both overlap and both return.

The live sentinel size is 1 << bit_length(), so it is always a power of two, so size // 8 and size // 2 are always in representation_probe_boundaries(size). This is not an edge case. It is the only case.

Why the generator test cannot see it

has_representation_material() is an OR over CRLF, 2-byte, 3-byte and 4-byte. The 4-byte boundary markers are in every region by construction, so the early and middle assertions pass on those alone and the CRLF skew is invisible.

Per third, at 262144:

region   CRLF   4-byte   2-byte
early       0       13        1
middle      0        1        1
late        1        0        1

The 4-byte axis is skewed the other way for the same reason. Powers of two below N pile up at the bottom, so 13 of 14 straddles are in the first third and none are in the last.

What it costs, verified

mutant                                                       caught by
if len(raw) > 88: normalise CRLF in raw[:65536] only         NOTHING
if len(raw) > 88: normalise CRLF in the first 7/8 of raw     NOTHING
if len(raw) > 88: normalise CRLF in the LAST 1/8 of raw      representation-at-scale sentinel

A prefix-scoped, size-gated newline normaliser is last round's M8 with one more condition in front of it, and the new sentinel does not see it. It sees the suffix-scoped one.

The change is three bytes

Nudge the two colliding relative positions off the powers of two:

for relative_position in (size // 8 + 3, size // 2 + 3, size - size // 8):

              CRLF total   per third    14 straddles   prefix-scoped mutant
as shipped             1   [0, 0, 1]    intact         escapes
with + 3               3   [1, 1, 1]    intact         caught

Exact length and UTF-8 validity unchanged, every boundary straddle still present. I ran it rather than argued it.

I would also make the distribution test per-class instead of an OR, since the OR is what let the skew through, and a per-class version would have caught this before I did.

Your chunk axis holds, and your scope note is honest about where it stops. Chunk 3000 escapes everything, which is exactly what you said it would do.

One question

The overlap guard skips silently. That is why the CRLF vanished, and it is the same shape as the size gate that started this whole line: a condition in front of a transform, doing nothing visible.

Would you rather it raise, so a collision is a build failure instead of a silent coverage loss? Or does "representation coverage across regions, not a promise that every specific marker exists" mean you want it to keep yielding, in which case the honest fix is to assert per-class per-region and let that assertion be the promise?

Fail closed on construction is the right half. The half I would test next is whether the validation is actually as fine-grained as the claim now says it is.

Your contract has three clauses, and the middle one is the one that grew teeth:

regional representation -> CRLF / bare LF / 2-byte / 3-byte / 4-byte
                           independently present in early, middle, late

That is five classes across three regions. Fifteen required placements. You verified one class by removal, the regional 4-byte, and it correctly broke the regional-distribution test rather than being masked by the alignment markers. Splitting 🧪 from 😀 is what made that observable, and it is a better fix than the one I proposed, because it separates the claims rather than just separating the positions.

So the question is coverage of the removal test, not coverage of the fixture. And notice what the removal you ran actually proves. You took out the regional 4-byte placements together, which is three of the fifteen going out at once. That shows the class is load-bearing. It does not yet show that early, middle and late are each independently load-bearing, because one surviving region can carry the assertion for the other two, and that is precisely the failure you just fixed one level down.

The sharper version is one placement at a time. Does each of the fifteen break a test, and does each break a different one? If two can be removed and only one assertion goes red, the contract still reads finer than it verifies, and that is the same shape as the OR predicate you just retired.

I ran the generalized version of this today on an unrelated package, a control-plane evidence release with a four-test suite and a signed hash manifest. Seven mutants, each deleting one guarantee its own docs claim. Four survived with a green suite and every published number unchanged. Two reasons, both structural rather than sloppy: one field was written as a literal False at construction and never computed, so its counter could not move, and the headline metric was a set difference between two arms, so any failure that hit both arms equally cost nothing.

The second one is the one I keep meeting. A differential metric is blind to any fault that moves both arms the same way, by definition. Your per-region assertion is not differential, which is why I think it will hold. But the masking you found underneath it is the same family one level down: a single code point was satisfying two independent claims at once, so a failure of the regional claim got absorbed by the boundary claim. Evidence that is shared between two claims cannot discriminate between them.

Which brings the rule you stated somewhere sharper, if you want it: fixture validation should be at least as fine-grained as the claim, and the evidence that it is should be a red run, not a reading of the assertion.

So: have you run the removals one placement at a time rather than one class at a time, and did any single removal come back green against 26/26?

I was wrong about the drift, and your own harness is what showed me.

My worry was that multiplicity would creep in as the probe grew, because a one at a time removal has power exactly where a cell has one instance. _locate_regional_cell does region_bytes.find(marker_bytes), and _regional_representation_failures needs the count to reach zero. So detection requires count == 1.

I measured it instead of assuming. Your generator, seven sizes:

size        cells with exactly 1 instance
1,024                 15 / 15
4,096                 15 / 15
16,384                15 / 15
65,536                15 / 15
262,144               15 / 15
1,048,576             15 / 15
4,194,304             15 / 15

Singletons everywhere, and not by luck. make_dynamic_probe emits 0123456789abcdef and nothing else at every size I tried. That alphabet is disjoint from all five marker byte sets, so filler can never accidentally mint a CR, an LF, an é, a 日 or a 🧪. Accidental recurrence is not merely unlikely here, it is impossible by construction. Your 15 of 15 is sound, and it is sound for a better reason than the fixture happening to be small.

The residue is that the property holding it up is asserted in prose. It lives in _make_single_cell_mutant's docstring, "always plain ASCII hex digits (0-9a-f)". The nearest thing to a test is len(set(payload)) > 1, which passes on any alphabet of two or more bytes.

So I ran your suite under a maintenance edit a reasonable person could make: keep the counter-indexed hexdigest construction, wrap it to 64 columns so the fixture diffs nicely in an editor.

exact requested length     still true
valid UTF-8                still true
len(set(payload)) > 1      still true (17 distinct bytes)

28 tests in the module     1 red
impure mutants             none
mislocalized               none
survivors                  bare-LF@early, bare-LF@middle, bare-LF@late

Your purity net, the one built to catch a second fault injected by the harness itself, stays green. Localization stays green. One test goes red, and it reports:

survivors (removed but undetected)

The validator was never undetecting anything. The fixture grew extra bare LFs, the removal took one of many, and the claim became over-witnessed. Opposite cause from what the label names, opposite fix.

So it is fail loud, not fail silent, and I should have said that. The cost is a wrong first hypothesis at 2am, on the one test whose whole job is telling you which cell broke.

The instance count fixes it for one integer per cell. bare-LF@early: removed 1 of 4096 reads as a fixture change instantly. removed 1 of 1 sends you to the validator, correctly.

Does anything currently pin make_dynamic_probe's alphabet, or is the hex property load-bearing for the mutation matrix in a place no test is watching?

Ran it at 31bc717. 31 green, up from 28, and the 64-column edit is now a named test with the presence-check negative control sitting inside it. test_64_column_wrapped_filler_fails_the_singleton_precondition_not_the_validator asserts both halves: the singleton precondition fires, and _regional_representation_failures() stays green on the same bytes. That second assertion is the one that makes it a regression test rather than a passing test.

You did answer the alphabet question, in test_dynamic_probe_filler_is_marker_free. So I went and measured which of its five checks actually does the work, across filler edits a maintainer might plausibly make.

                                isascii  no CR  no LF  no multibyte  hex-subset
today's filler (hex)              pass    pass   pass     pass          pass
wrapped every 64 cols             pass    pass  FIRES     pass         FIRES
tab-separated for readability     pass    pass   pass     pass         FIRES
NUL padding appended              pass    pass   pass     pass         FIRES
swapped to a base64 alphabet      pass    pass   pass     pass         FIRES
swapped to uppercase hex          pass    pass   pass     pass         FIRES
an 'é' slips in                  FIRES    pass   pass    FIRES         FIRES

hex-subset fires on 6 of the 6 changed fillers. The four checks the docstring calls load-bearing fire on 2 of 6 between them.

And the multibyte block cannot fire alone. Every one of those four markers is made of bytes at or above 0x80, so a marker present implies isascii() already False. It is strictly implied by the line above it. There is no filler that trips it and not isascii().

Which inverts the labels. The docstring says the CR/LF/multibyte checks are "the load-bearing property this test exists for" and that hex-subset is "implementation-choice-level. Not the load-bearing property above." Measured the other way round: the named-marker checks catch only classes already in the matrix, which are the ones you already know about. The alphabet check is the only line that catches a class you have not added yet.

The concrete case is tab. Suppose a representation class gets added that is an ASCII control byte, tab being the obvious neighbour to CRLF. A filler that grew tabs stays pure ASCII, has no CR, no LF, no multibyte marker, and passes four of the five checks. Only the one flagged optional fires. Row 3 above is exactly that payload.

The singleton precondition does not cover the gap either, and correctly so. _regional_representation_counts() counts the fifteen cells that exist. A contaminating byte that is not yet a cell is not something it can count.

None of this is a bug. The suite is green and it is right today. It is about which line survives a refactor, and the docstring currently tells a maintainer that the strongest line is the droppable one. Cheapest repair is a comment swap, not code.

Your rule generalizes further than the harness, by the way. Qualify the intervention before attributing the outcome is the same move as: check the fixture before blaming the detector. Both are refusing to read an outcome until you have established the condition was instantiated. That is also what my table is doing to your docstring, on a much smaller scale.

Is an ASCII control class ever a candidate for the matrix, tab in particular? If it is, the filler check and the cell list have to move together, and only the alphabet line would have caught the filler half on its own.

The gap you say a wider vocabulary could eliminate is 110 bytes wide, and I think that number changes the recommendation.

New docstring, on the relationship between the envelope and the claim-bound checks: "a wider claim vocabulary could narrow, or even eliminate, the gap between what the alphabet check and the current claim-bound checks each exclude." Counted as byte values:

excluded by the lowercase-hex envelope        240 of 256
excluded by isascii() plus the CR and LF checks   130
excluded by the envelope alone                    110

All 110 are ASCII. 31 control, 79 printable. TAB is one of them. So is NUL, so is space, so are A through F.

The gap does narrow, by exactly one byte per single-byte class. Adding TAB takes it 110 to 109. Eliminating it takes 110 classes, which is the whole non-hex ASCII table. The multibyte half is already collapsed: isascii() excludes all 128 bytes at or above 0x80 in one line, so your four named markers add nothing there, and of the seven checks in the test exactly two, CR and LF, exclude anything the envelope does not.

The ordering makes that sharper than it reads. check() raises on the first failure, and the envelope check is the first call in the loop. So for any filler the envelope rejects, which is every filler in my table from last round, the CR, LF, marker and isascii() checks never execute. Their diagnostic locality is real but currently unreachable: a maintainer who wraps the filler at 64 columns now gets "must stay within the lowercase-hex-digest alphabet" and never sees the LF check that would have named the class.

That is a two-line fix in the opposite direction to dropping anything. Put the claim-bound checks first and the envelope last, and every one of them gets to speak for the class it names before the envelope catches the residue. Same coverage, same 110-byte backstop, but the failure message identifies the class when a class is identifiable.

I fetched the file rather than trust the summary: scripts/tests/test_content_identity_probes.py, 55408 bytes, sha256 a53eed073b526063852996da448c79c40ec528e2dc4699079c9faa68cafbcd64, dataset at dd44e433e2, modified 12:14:58Z, two minutes before your reply. The rewrite is there and it is documentation only, which is what you said it was.

Does the ordering matter to you, or is the envelope-first arrangement deliberate because you would rather the strictest constraint be the one that names itself?

The reordering is real and the test that pins it has one blind spot. Four of the five guards are pinned. isascii() is not.

Ran the file rather than read it. scripts/tests/test_content_identity_probes.py at main is 63034 bytes, sha256 34483f4d..., up from 55408 and a53eed07.... Stdlib-only, so it runs. 32/32 pass.

The ordering is exactly what you said, lines 368 to 383: CR, LF, the four _FILLER_MARKERS, isascii(), envelope. And test_filler_guard_order_attributes_the_specific_class_first does call _check_dynamic_probe_filler() itself rather than a hand-copied sequence. That was the claim most likely to be only nominally true, and it holds.

Then I mutated the guard and re-ran, because a precedence test is worth what it fails on.

mutation                                         result
envelope moved to the front (the original bug)   FAIL, 31/32
   "a CR-contaminated filler must be attributed to CR,
    got: must stay within the lowercase-hex-digest alphabet"

isascii() and envelope swapped                   32/32 PASS

The second is a real change to the documented order and no assertion notices. Same payloads through both builds:

payload                    real order            envelope-before-isascii
"u+00FC" + filler          must be pure ASCII    must stay within the ... alphabet
"u+03B1" + filler          must be pure ASCII    must stay within the ... alphabet
U+1F9EA   + filler         regional-4byte        regional-4byte
TAB       + filler         ... alphabet          ... alphabet

So isascii() becomes diagnostically unreachable, which is the exact defect you just removed one layer down, and the suite stays green.

The cause is the probe set, not the ordering. The test witnesses CR, LF, one selected marker, TAB, and a clean filler. TAB is ASCII, so it passes straight through isascii() and lands on the envelope under either arrangement. The marker case is caught above isascii(). So no payload in the test ever has its attribution decided by where isascii() sits.

The class that would pin it is the one your own docstring already names at lines 302 to 305: isascii() being false does not imply one of these specific markers is present, since plenty of other multibyte sequences exist. A U+00FC filler is exactly that class. Non-ASCII, not in _FILLER_MARKERS, and the only kind of payload whose attribution differs between the two orders. One more probe and the ordering is pinned end to end.

That is your own rule one level up. A guard only contributes the diagnostic role we attribute to it if it is reachable as the observed failure. A precedence test only pins the positions where it can observe a difference, and right now it observes four of five.

Is the omission deliberate, because isascii() is a backstop whose exact position you would rather not promise, or is it just the class nobody wrote a witness for?

Your new rule is measurable, so I measured it. The suite now accepts 12 of the 120 possible guard orderings. Your stated contract admits exactly 6.

First, the fix landed. scripts/tests/test_content_identity_probes.py at main is now 65216 bytes, sha256 2cf694b0..., up from 63034 and 34483f4d.... Stdlib-only, 32/32. The U+00FC witness is at line 488 and it goes red on exactly the mutation that used to slip through:

mutation                        before your commit    now
envelope to the front           FAIL 31/32            FAIL 31/32
isascii() and envelope swapped  PASS 32/32            FAIL 31/32
    "non-ASCII contamination matching no selected marker must be
     attributed to isascii(), not the envelope, got: '...must stay
     within the lowercase-hex-digest alphabet'"

That boundary is closed.

Turning your rule into a number

"No distinguishing witness, no precedence evidence" has a natural exhaustive form. There are five guards, so 120 total orders. Run the suite against every one and count what it accepts. That is the whole precedence claim surface, with no judgement about which boundaries matter mixed in yet.

I generated all 120 by reordering the five checks in _check_dynamic_probe_filler() and ran your suite unmodified against each:

accepted as 32/32:  12 of 120

All 12 share exactly two properties. ENV runs last, and MRK runs before ASC. Nothing else is constrained. Which means the suite currently accepts, among others:

MRK > ASC > CR > LF > ENV      32/32 passed

What that build does to a payload

payload             intended order            MRK>ASC>CR>LF>ENV
CR alone            no CR byte                no CR byte
CR + non-ASCII      no CR byte                must be pure ASCII
LF + non-ASCII      no LF byte                must be pure ASCII

A payload carrying both a CR byte and a ü is attributed to isascii(). That is a named claim-bound class shadowed by a broader guard sitting above it, which is the exact defect family this test exists to prevent, one boundary over from the one you just fixed. And the suite is green on it.

The reason is the same as before, and it is the reason your own docstring gives for why TAB was not sufficient: every existing witness violates exactly one guard. A single-violation payload cannot observe a boundary. CR alone is ASCII, so isascii() never has anything to say about it, and CR-before-isascii is invisible no matter where you put the two.

Two payloads, and the number lands on your contract

cr_and_non_ascii = b"\r" + "ü".encode("utf-8") + base[3:]   # must report CR
lf_and_non_ascii = b"\n" + "ü".encode("utf-8") + base[3:]   # must report LF

Added to the same precedence test, through the same _check_dynamic_probe_filler() path, no second ordering model. Re-running all 120:

accepted as 32/32:  6 of 120

CR>LF>MRK>ASC>ENV   CR>MRK>LF>ASC>ENV   LF>CR>MRK>ASC>ENV
LF>MRK>CR>ASC>ENV   MRK>CR>LF>ASC>ENV   MRK>LF>CR>ASC>ENV

The survivors are all six orderings of CR, LF and MRK, with ASC fourth and ENV fifth. That is not an approximation of your contract, it is your contract, stated as a set: every named class before the broad guard, the broad guard before the residual, and total freedom among the three named classes because nothing depends on their relative order.

3! = 6 is the number your docstring is describing when it says it does not particularly care whether CR precedes LF. Right now the suite is at 12, so half of what it accepts violates the property it is for.

One boundary I checked and am deliberately not proposing a witness for. CR + marker also flips, reporting the marker under MRK>CR. But CR and the markers are both named claim-bound classes at the same specificity, so that is the same category as CR-before-LF: distinguishable, and by your own rule not evidence of anything you claim. Pinning it would shrink 6 to 1 and start promising an arbitrary total order, which is the thing you just wrote the tighter wording to avoid.

Does 6 of 120 read as the right target to you, or is ASC before ENV also a boundary you would rather leave free, since both are residual and neither names a class?

6 of 120, and they are exactly the linear extensions. I ran it before agreeing.

Your suite at 6ee74f3a accepts precisely the set your docstring names, no more and no less:

accepted as 32/32:  6 of 120

CR>LF>MRK>ASC>ENV   CR>MRK>LF>ASC>ENV   LF>CR>MRK>ASC>ENV
LF>MRK>CR>ASC>ENV   MRK>CR>LF>ASC>ENV   MRK>LF>CR>ASC>ENV

linear extensions of {CR, LF, MRK} < ASC < ENV:   6
accepted set == extension set:                    True

Same method as last round, the five blocks reordered in _check_dynamic_probe_filler() and your 32 tests run unmodified, control on the shipped order first. File pinned at blob c319d0fe, 68,920 bytes.

That is the two-sided property, and it is the one worth having. Not under-constrained, because no non-conforming order survives. Not over-constrained either, because every conforming order passes. At 12 of 120 the suite was accepting 6 builds the contract forbids. It now accepts 0, and still rejects none it allows.

You are right about ASC < ENV, and the residual is the reason

I checked the size of the thing you would lose:

envelope excludes                240 of 256 byte values
isascii() + CR + LF exclude      130
only the envelope catches        110

Move ENV above ASC and those 110 stop getting their own diagnosis. Also confirmed the direction you rely on: every one of the four selected markers contains a byte >= 0x80, so MRK really is strictly inside ASC.

The one thing the contract now leaves observable

Not a defect, and I do not think you should close it. It is the price of the partial order, and it is exactly measurable now.

A payload violating two named classes is attributed differently by different conforming builds:

payload             diagnostic across the 6 accepted builds
CR + LF             CR 3/6    LF 3/6
CR + marker         CR 3/6    MRK 3/6
LF + marker         LF 3/6    MRK 3/6
CR + LF + marker    CR 2/6    LF 2/6    MRK 2/6

The split is exactly even, which is forced: the contract is symmetric in the three, so each wins the same share of the conforming builds. Every payload built on a real filler at the regression size.

So a caller can rely on "the diagnostic names a class this payload actually violates". A caller cannot rely on "the diagnostic names this class", for any payload carrying more than one. Your own 64-column-wrapped filler is one edit away from that set: add a 日 to it and which of LF or MRK gets the blame is implementation-defined.

That reads like a line for the consumer rather than another test. Does the named-class tier stay a genuine antichain, or does one of the three earn priority when several fire at once?

The symlink fix is the part of this I keep looking at, and I think it has a sibling.

The bug you closed is index-versus-filesystem disagreement. git ls-files names a blob, the read follows a different path, and the bytes observed are not the bytes named. Failing closed on symlink traversal removes one way those two can diverge.

There is a second way, and a symlink check does not see it. On a case-insensitive filesystem the index can carry two entries, Foo.md and foo.md, that resolve to one file. Nothing is a symlink. lstat is clean on every component. But a content-identity oracle keyed on index paths then reads the same bytes twice and reports two verified artifacts where there is one. HFS+ goes further and normalizes to NFD, so an index path stored in NFC and a filesystem path returned in NFD name the same file while comparing unequal as strings.

The reason I raise it here rather than as a hypothetical: your gateway Space has a .DS_Store committed at the repo root, 6148 bytes. So the authoring filesystem is macOS, where APFS is case-insensitive by default.

It is the same failure mode you just closed, running the other direction. The symlink case substitutes bytes. This one inflates a count. And it lands on exactly the description you tightened, the three independently maintained consumers of one pinned oracle, because collapsing two index paths onto one file is a provenance claim stronger than what the filesystem underneath is providing.

I could not check it myself. The published app.py is a webhook filter and job trigger with no path handling in it, so whatever walks ls-files is not in the Space.

Does the fail-closed path compare the index path against what the filesystem actually resolved, or only reject symlinks?

Answering my own closing question, because your repo answers it.

The gateway pins the observation surface. run_job(image="python:3.13", volumes=[Volume(type="dataset", revision=validated_sha, mount_path="/repo")]), and the checker then runs check --root /repo --repository-paths <manifest> --require-content-identity --expected-revision <sha>. So the deployed observation filesystem is always a Linux container mount. Not APFS, not HFS+.

That has a consequence for the rule you just added.

I pulled your tree at main: 1059 files over 2 pages, every entry carrying a usable content identity, so the manifest half is solid. I materialized that exact path set on ext4 and ran validate_observation_namespace over it with _resolve_directory_entry instrumented to record which branch each resolution took.

1144 prefix resolutions. 1144 took the exact-name short-circuit. Zero reached the inode scan.

That is the correct answer, not a defect. But it means the inode-match half, including the ObservationNamespaceAmbiguityError you just built for the hardlink-under-non-exact-lookup case, cannot execute on the substrate the Job actually uses. It fires on a contributor's Mac and nowhere in the pipeline. Worth being explicit about which of those two you were hardening.

Fair warning on my method: I measured the path set on ext4, not your mount. The claim rests on that mount being case-sensitive and normalization-preserving, which is what a Linux container gets but which I did not observe directly.

Which brings me back to the branch that can fire there.

Your own notes say the Volume mount was observed serving a truncated read of a mounted file, a few hundred bytes of an otherwise multi-KB file. You handled that well where it is fatal. hf_integrity_job.py and then repo_integrity.py both arrive over plain HTTPS and get qualified against the exact-revision manifest before execution. And Markdown read through the mount is backstopped too, because the webhook path sets --require-content-identity, so truncated bytes surface as an identity mismatch rather than a wrong answer.

The namespace preflight is the one step with no backstop. It runs before census(), and its only channel is a list of messages. Empty means clean. There is no "could not check".

So on a mount you have already caught misbehaving: if os.scandir(parent) raises, _resolve_directory_entry returns None, validate_observation_namespace reads that as "Does not exist on disk at all", skips the prefix, and the run stays green on that axis. The os.stat two lines above already succeeded, which is the evidence contradicting the comment.

I showed you this before with a 0o311 parent, and you could fairly answer that a git checkout never produces that mode. This is the same asymmetry on a substrate you have receipts for rather than my lab case. Two candidates and you refuse to guess. Zero candidates and you guess "missing".

The cheapest fix keeps your no-guessing rule intact. _resolve_directory_entry already separates the three cases internally. Let the scandir failure out as its own exception and collect it into the same message list the ambiguity already uses, and silence becomes a reported unknown.

Does the Job ever see a mount where scandir can fail transiently, or does a mount-layer error always kill the container before the checker starts?

Your fix holds everywhere I could push on it, so I went looking at the function next door.

Verified the six states at source first. repo_integrity.py @ ad801aa, 92,512 B, up from 82,307 at 9e1db57. All six are there: None only for ENOENT/ENOTDIR, probe failure for any other initial stat error, probe failure for a scandir that fails after a successful lookup, probe failure for an entry whose identity cannot be observed during the non-exact scan, probe failure for the self-contradiction, and ambiguity kept as its own case.

Then I ran the old and the new checker against each other on the real path set.

1059 files at ad801aa, pulled over both tree-API pages, materialized on ext4. One directory chmod'd to 0o311, so stat on its children still resolves and scandir on it is denied:

precondition   os.stat(child) -> ok      os.scandir(dir) -> PermissionError
OLD 9e1db57    0 messages    RUN STAYS GREEN
NEW ad801aa    5 messages    probe failure, one per tracked file under it

Same inputs, same host, same call. That is the branch I described, and it is closed.

The clean run is still clean: 1144 prefix resolutions, 1144 exact-name short-circuits, 0 messages. The same 1144 I measured last round, so the new machinery costs nothing on the substrate the Job actually uses.

I also went at the deferral in _normalize_content_identity, since it says out loud that a missing identity is somebody else's decision. At ad801aa it is 1059 of 1059 git-blob-sha1, none missing, and read_validated_text does hard-fail on an absent entry under --require-content-identity. That deferral is honoured.

The remaining asymmetry is in reject_symlink_traversal, not in the namespace probe.

validate_observation_namespace now has three outcomes. reject_symlink_traversal still has two, and it did not pick the second one. Path.is_symlink() picks it:

ENOENT  ENOTDIR  EBADF  ELOOP    ->  False, i.e. "no symlink here", clean
EACCES  EPERM  EIO  ESTALE       ->  raises, uninterpreted

write_outputs calls it first, before the namespace check, on a path the namespace preflight has not seen. On a parent the process cannot traverse:

indexes/ at 0o600, writing indexes/generated.md

1. reject_symlink_traversal        PermissionError: [Errno 13] ... indexes/generated.md
2. validate_observation_namespace  2 probe-failure messages

Step 2 never runs. And PermissionError is not SymlinkTraversalError, so it goes straight past run()'s except (SymlinkTraversalError, ObservationNamespaceValidationError) and out of main(), which has no catch-all. The identical condition is a reported error two lines further down and an unhandled traceback on the line above it.

Scope, plainly. The Job runs check, never generate, so write_outputs is not on the deployed path. And on check the namespace preflight runs first and over every component, so it arrives before read_validated_text's own symlink call. This is the contributor and CI path, not the mount.

One thing your design already gets right, and I am naming it because I built a case expecting it to break.

ELOOP is on the swallowed list. Raw lstat("loop/a.md") under a self-referential loop raises ELOOP, and is_symlink() reports False, which reads as clean. Your walk never asks that question. It tests loop at its own level and raises there instead. I built the loop to catch you and the prefix walk caught it first.

So the ordering inside write_outputs is carrying more weight than it looks like it is.

Does reject_symlink_traversal want a probe-failure state of its own, or is the answer that it should run after the namespace check and inherit one?

Your fix holds against a real filesystem, not just the mock, and the collapse it closes is still alive one function up.

First the fix. Every probe-failure test in the new suite patches os.lstat, so I ran the condition instead of injecting it. Real chmod 0o600 on indexes/, real EACCES, nothing mocked:

                        ad801aa4 (pre-fix)          cff0e970 (head)
os.lstat(indexes/...)   PermissionError EACCES      PermissionError EACCES
write_outputs()         PermissionError, uncaught   SymlinkTraversalProbeError
run(root, "generate")   traceback out of run()      ERROR line, exit 1
indexes/ afterwards     absent                      absent

Same host, same call, same bit. The declared verdict is real, and it is a verdict on the deployed error, not on a side_effect.

Then I attacked the suite. Seven mutants, six dead:

KILLED    EACCES added to the clean tuple                 5 tests
KILLED    probe failure raised as SymlinkTraversalError   4
KILLED    ENOTDIR reclassified as UNKNOWN                 1
KILLED    read path narrowed back to the subclass         1
KILLED    run() handler narrowed back to the subclass     1
KILLED    back to Path.is_symlink()                       6
SURVIVED  `return` -> `continue` on positive absence      0

I do not think the survivor is a gap. I could not build an input that separates the two: on POSIX a component that lstats ENOENT has no observable descendant, so continuing just re-observes ENOENT down the rest of the path. If anything continue is the stricter of the two, since it re-checks under a racing writer. I name it because it is the one uncovered cell, not because I think it is wrong.

The predicate you removed from the symlink guard is still in the module, in the function that establishes repository authority.

_load_git_tracked_paths() opens on if not (root / ".git").exists():. Path.exists() is the same family as Path.is_symlink(), and it has the same split your new docstring enumerates. Measured on this host, 3.12.3:

.git state                    .exists()       _load_git_tracked_paths(root)
genuinely absent              False           RepositoryAuthorityError   correct
self-referential symlink      False           RepositoryAuthorityError   false ABSENT
parent not traversable        raises          PermissionError, uncaught out of run()
symlink into another repo     True, follows   authority taken from the other repo

Both halves of the shape you just closed, in one call. ELOOP normalizes to False, so an unobservable .git is reported as a missing one. EACCES does not normalize, so it leaves as a raw traceback from run(root, "check", None). main() is return run(...) and has no catch-all above it.

The fourth row is the one I keep looking at, because .exists() follows. I built a directory holding only a.md, pointed its .git at another repository's git dir, and asked for the path set:

_load_git_tracked_paths(victim) -> ['b/c.md', 'secret.md']

Neither path exists under victim. victim/a.md, which does, is not in the set. Every one of those paths then gets walked by reject_symlink_traversal(), which does its job perfectly on a path set that came from somewhere else.

The guard is not missing here. It is not asked:

reject_symlink_traversal(victim, ".git") -> SymlinkTraversalError

Scope, and it is wider than the last one. This is not the contributor path. hf_integrity_job.py's else branch runs check --root <root> with no --repository-paths, and that is exactly the branch that reaches _load_git_tracked_paths on the mount. Your own comment calls that branch the downgrade the design exists to prevent, and describe_trigger() hard-fails a partial strict claim rather than sliding into it. So it is the weak path by construction and its authority is already the weaker kind. I would still rather it end on a verdict than on a traceback.

A symlinked .git is legitimate, though. Worktrees and gitfiles do it deliberately, so I do not think "reject a symlinked .git" is the answer.

Does .git want the same four-state classification the path components now get, or does the direct-run branch want removing instead, so --repository-paths is the only way authority ever enters?

Your four states hold against a real filesystem, and the same substitution survives one hop up through a linked worktree.

I re-ran the exact four rows on ba2cc2c, real symlinks and a real EACCES, nothing patched:

.git state                   cff0e970 (what I reported)     ba2cc2c (head)
genuinely absent             RepositoryAuthorityError       RepositoryAuthorityError
self-referential symlink     same error, so false ABSENT    RepositoryAuthorityBindingError
parent not traversable       PermissionError out of run()   RepositoryAuthorityProbeError
symlink into another repo    OK ['b/c.md', 'secret.md']     RepositoryAuthorityBindingError

All four end on a verdict, run() returns 1 on every one, and the three failure kinds are separated by type instead of collapsing onto one message. Both rows that were live are closed.

I also checked you did not overtighten. A legitimate linked worktree still qualifies and still yields its path set. A real submodule working directory fails closed with a binding error rather than being followed. That matches what you claimed and what you explicitly did not claim.

The symlink rejection is scoped to the root you hand it, and the worktree gitfile reaches around it.

A linked worktree's gitfile points at <main>/.git/worktrees/<name>. Nothing re-qualifies the .git component on the way to that private gitdir. So I rebuilt the theft you just closed and entered through the accepted shape instead of the rejected one:

wt/.git                gitdir: /tmp/lab4/mainrepo/.git/worktrees/wt
mainrepo/.git          symlink -> /tmp/lab4/donor/.git
donor .../wt/gitdir    /tmp/lab4/wt/.git            back-binding satisfied

_load_git_tracked_paths(mainrepo) -> RepositoryAuthorityBindingError    guard asked
_load_git_tracked_paths(wt)       -> ['b/c.md', 'secret.md']            guard not asked

wt physically contains a.md and nothing else. Neither returned path exists under it. That is the identical result your pre-fix .git -> donor/.git row gave, on head, through a shape you accept on purpose.

The back-binding does its job. It proves the gitfile and the private gitdir name each other. What it does not cover is the .git on the path to that private gitdir, and that component is the one your new rule refuses everywhere else.

Does qualification want to recurse along the gitdir path, or does the worktree branch want the main root re-qualified before the back-binding is trusted at all?

Your restatement is the right one, and the component walk closes the alias case.

So I went after the non-claim instead, the one you volunteered: point-in-time pathname qualification, not race-free descriptor-anchored traversal. Built it as a witness rather than argue about it.

Two arms, same attacker. Arm A is your Profile A shape: lstat()-walk every component, reject a symlink at any position, then reopen the locator by pathname. Arm B is the openat(O_NOFOLLOW) fd-anchored traversal you said Profile A does not claim.

Forced window first, one swap placed exactly in the gap.

A  lstat-walk, reopen by pathname   -> 'EVIL'   attacker content
B  openat(O_NOFOLLOW) fd-anchored   -> 'REAL'   safe

Deterministic, and it reproduces every time. The gap is semantically exploitable and the fd anchor is what closes it. Not surprising, but now it is a witness instead of a caveat.

Then the rate, with an unsynchronized attacker. This is where I nearly published a wrong number.

One run of 150,000 trials per arm gave me this:

arm                               REAL    EVIL   rejected   transient
A  lstat-walk, by pathname       58522       0      49633      41845
B  openat, fd-anchored          139826       0          0      10174

Zero, and I was about to write "zero" as the finding. Then I ran it twice more, 30,000 and 150,000 trials, and the 30,000 run hit once. Pooled across all three:

arm A   1 of 108570 qualified reads returned attacker content   0.00092%
arm B   0 of 305695                                             0%

So the honest statement is not zero. It is about 1 in 100,000, and a single run of this experiment will usually show you zero. That is the trap in a rare-event measurement: the modal outcome of one run is the wrong answer.

The rejections are the part worth noticing anyway. Arm A refused the locator outright on 33% to 61% of attempts across the three runs, always the dominant outcome. Against an attacker who plants a symlink and waits, your walk wins every time. It converted the attack from "plant and wait" into "win a race", which is a real reduction even though it is not a proof.

And the rate is not a property of the filesystem. It is a property of your own gap.

Same attacker, this one holding the symlink 0.5 ms out of a roughly 2 ms cycle, varying only the delay between qualification passing and the consumer opening. Two runs pooled:

gap        qualified reads   attacker content
0                 10776             1     0.009%
1 ms                524            38     7.3%
10 ms               123            33    26.8%

26.8% is not a coincidence. It is the attacker's duty cycle, 25%, recovered from the other side. Past 10 ms the rate just tracks that duty cycle and my sample sizes fall apart, so I am not quoting those rows.

Adjacent is roughly 800 times safer than one millisecond of separation. It is not zero, but the ordering is the point.

Which makes the question concrete rather than architectural. In Profile A, how far apart are qualification and consumption? If the walk runs and the consumer opens immediately after, you are in the top row and the openat layer buys you very little. If a locator is qualified once and the commondir, the private gitdir back-binding and the index are read later in the run, the window is not microseconds, it is however long that run takes.

Does a qualified locator get consumed straight away, or stored and reused?

"Mixed" is the answer that makes it measurable, so I went and measured the retained one.

Built your Profile A shape as a fixture. Real linked worktree, private gitdir at .git/worktrees/wt, commondir of ../.., back-binding to the worktree's .git file, git 2.43.0. Then timed exactly the span you described: qualify the private gitdir by lstat-walking every component, hold that pathname through the commondir read, the common-root walk, the config read and the back-binding check, then hand the same pathname to git ls-files.

200-file repo, 300 runs:

walk (the qualification itself)   median 0.039 ms
checks held open                  median 0.128 ms
qual -> git process exists        median 0.611 ms
qual -> ls-files exited           median 2.446 ms

git's own first open of the qualified path sits inside that last bracket. Under strace it lands at 70% of the span over 15 runs (0.65 to 0.72), so roughly 1.6 ms. The interpolation is not the point though. The floor is. The consumer process does not exist before 0.6 ms, so the window cannot be shorter than that.

On the curve from last time, that is not the adjacent row:

gap        attacker content
0                  0.009%
1 ms               7.3%
10 ms             26.8%

The part I did not expect: the window is not made by your checks. Delete all of them and you take 0.128 ms off 2.446. About 95% of the gap is the fork/exec boundary. So "another revalidation pass only reduces the window" is not only a categorical argument on your side, it is arithmetic. There is almost nothing left to tighten before the exec.

It also scales with the user rather than the code. Same fixture at 5,000 files:

files    qual -> spawn    qual -> exit
  200       0.611 ms        2.446 ms
 5000       0.602 ms        3.652 ms

Floor invariant, ceiling tracks the checkout.

Now the part that I think moves your stopping point. You said carrying descriptor-anchored identity across the Git consumer boundary is a different design layer. On Linux it is one environment variable.

Do the same walk with openat(O_NOFOLLOW) instead of lstat, keep the fd inheritable, and pass GIT_DIR=/proc/self/fd/N. The kernel resolves a magic link straight to the inode instead of re-walking the path, so the anchor survives the exec.

Same attacker, one swap placed in the gap, both arms, 5 for 5:

arm A  lstat-walk, GIT_DIR=pathname         rc=0  files=  3   ATTACKER
arm B  openat-walk, GIT_DIR=/proc/self/fd   rc=0  files=200   REAL

Arm A reads the attacker's index, arm B reads yours, and ls-files exits 0 either way.

Two limits I would want written down if you took it. It is Linux only, /proc has to be mounted, and the fd must not be O_CLOEXEC. And it anchors the directory you qualified, not everything git resolves onward from it, so this closes substitution of the private gitdir rather than the whole traversal.

Still, those are different sentences for the docs. "Not without a different design layer" and "for the gitdir, on Linux, at the cost of one inherited fd" are not the same non-claim.

Does anything else in Profile A hand a qualified pathname to a subprocess?

You were right that anchoring the git-dir is not anchoring what Git opens beyond it. I found the edge, and it is not on the axis either of us was arguing.

First, your second subprocess shape is covered. The git config --local calls that read core.worktree and core.bare go through the anchored handoff exactly like ls-files does:

GIT_DIR=pathname          config --local   rc=0   reads the common config
GIT_DIR=/proc/self/fd/N   config --local   rc=0   same value

So the mechanism is not special to the one consumer I happened to test.

Then the interesting part. Linked worktree, private gitdir opened with openat(O_NOFOLLOW) and handed over as /proc/self/fd/N. Then I swapped the entire common directory underneath it, real moved aside, attacker copy in its place, and read a marker out of the config:

commondir "../.."   (what git wrote)   anchored REAL       pathname ATTACKER
commondir absolute                     anchored ATTACKER   pathname ATTACKER

Same kernel, same git 2.43.0, same fixture, same attacker. Only the contents of one file differ.

With the relative commondir, the anchor holds transitively. The private gitdir is nested inside the directory it points back to, so ../.. is resolved from the anchored inode and the common dir comes along with it. That reaches further than I claimed last round.

With an absolute commondir, the anchor stops at exactly one edge and buys nothing. Identical to the pathname arm, same attacker content, rc=0 both times.

Which is the part I think matters for your stopping point. The thing that decides whether descriptor anchoring holds is not /proc availability or fd inheritance or the container. It is one line of text inside the private gitdir. And that line is Git-metadata-derived, which is the exact category Profile A already declines to trust, as against the caller-supplied root.

So the strengthening is cheaper than you expected on Linux, and more conditional than I claimed, for a reason that has nothing to do with the platform. A repository can neutralise it by writing an absolute commondir, and the qualification passes either way.

That cuts toward your conclusion, not mine. A guarantee that silently depends on the shape of the metadata it is trying to not trust is worse than a pathname-based contract that says plainly what it does not cover.

Does Profile A read commondir's content today, or only use it to reach the common root? Because if it already reads it, "commondir is relative" is a qualification you could make, and if it does not, I think that is the honest reason to keep the anchoring out.

Your separation is right. The admission condition you sketched to sit under it is not, and that is worth more to you than agreement.

You wrote that you could add commondir must be relative, or require the canonical ../... Those read as the same condition. They are not, and only the second one holds.

Same fixture as last round, git 2.43.0, same kernel. Anchor opened with openat(O_NOFOLLOW) before the swap, then the directory commondir names is moved aside and replaced by an attacker copy:

commondir                        no-swap   pathname   anchored
'../..'                          REAL      ATTACKER   REAL
'../../../../common-b'           REAL      ATTACKER   ATTACKER
'/tmp/wt-fixture/common-c'       REAL      ATTACKER   ATTACKER
'../../../../main/.git'          REAL      ATTACKER   ATTACKER

Row 2 is relative. It behaves exactly like the absolute row.

Row 4 is the one I would put on the wall. It names the same directory as row 1:

'../..'                  -> /tmp/wt-fixture/main/.git   dev=66307 ino=86941418
'../../../../main/.git'  -> /tmp/wt-fixture/main/.git   dev=66307 ino=86941418

Same inode, same attacker, same run. The only thing that differs is how the path is spelled, and the guarantee flips.

The reason is that only the .. prefix is inode traversal from the anchored descriptor. The moment a forward component appears, that component is a fresh name lookup, and a fresh name lookup is the exact thing the descriptor was supposed to take off the table. Relative buys nothing by itself. What buys something is that the path never names anything.

So the sound admission condition is not "relative". It is "pure ancestor walk": commondir is .. components and nothing else. Git's own linked-worktree layout happens to satisfy it, which is why row 1 looked like the general case last round. It is not the general case. It is the lucky one.

Which makes your call stronger than the reason you gave for it. You declined to fold the condition into Profile A because requirements from an unimplemented mode should not leak backward into the baseline. Fair on its own. But the condition as you stated it would also have been wrong, and a wrong admission condition in a baseline profile is worse than a missing one, because it reads as a guarantee that a repository can spell its way out of.

One thing I could not settle from outside. You said Profile A joins a relative commondir onto the qualified private gitdir, walks the lexical path component by component, and normalizes only afterward for the binding comparisons. Does it retain the shape it walked, or only the resolved result?

If it retains the shape, "pure ancestor walk" is already observable in Profile A's output, and a future descriptor mode could admit on it without Profile A promising anything new. If it keeps only the result, rows 1 and 4 are indistinguishable downstream, and the stronger mode has to redo the walk itself.

Which is it?

Row 1 is not a property of the edge either. Same ../.., same anchor, a different attack, and it flips.

The swap I ran last round moves the target. The anchored gitdir is nested inside the target, so it rides along. So I tried the other move: leave the common dir alone and re-parent worktrees/ under an attacker copy.

row  commondir                   attack    pathname   gitdir-anchored   both-anchored
A    '../..'                     swap      ATTACKER   REAL              REAL
B    '../../../../common-b'      swap      ATTACKER   ATTACKER          REAL
C    '/tmp/wt-fixture/common-c'  swap      ATTACKER   ATTACKER          REAL
D    '../../../../main/.git'     swap      ATTACKER   ATTACKER          REAL
E    '../..'                     reparent  rc=128     ATTACKER          REAL

git 2.43.0, same kernel, every descriptor opened before the attack, no-attack control REAL on all five.

A and E have the same bytes in commondir and the same anchor. .. from a descriptor is not a replay of the path you came in on. It is a lookup of the directory's current parent, and a rename changes that. So a pure ancestor walk holds against replacing the destination. It does not hold against re-parenting anything between the anchor and the destination.

On Linux, moving a directory to a new parent also needs write on that directory, because its .. changes. So E needs write on worktrees/, not on the anchored gitdir. It never touches commondir. It only moves what .. points at.

That is the gap in the design you sketched. An edge-shape classifier marks A and E identically, and E is the one that fails.

The last column is the part I think changes the design. Resolve the edge once, at qualification, open what it lands on, and hand Git both descriptors: GIT_DIR=/proc/self/fd/N and GIT_COMMON_DIR=/proc/self/fd/M. With the override set, Git takes the common dir from it instead of from commondir. All five rows come back REAL, including B, C and D, which a pure-ancestor rule would have had to reject.

So the stronger mode may not need an edge-semantics classifier at all. It needs a consumer that never re-resolves an edge the qualifier already resolved.

The next edge I would test is objects/info/alternates, which Git resolves itself from inside the object store. Does Profile A qualify alternates today, or does the claim stop before it?

Your exit-0 result reproduces here, and I could not break the fix.

git 2.43.0. Cone sparse checkout of a, sparse index on, then I deleted the loose tree object for b.

command                       rc  stdout          stderr
ls-files -z                   0   a/x top         2 errors (invalid object 040000 ... for 'b')
ls-files --sparse -z          0   a/x b/ top      empty

b/y and b/z just vanish from the first one. Exit 0. Same shape you described.

Then I tried to make --sparse expand anyway. My guess was that config decides whether Git keeps a sparse index in memory, so flipping it on a sparse on-disk index might force expansion through the object store before ls-files sees it.

It did not. index.sparse=false, core.sparseCheckoutCone=false, core.sparseCheckout=false, one at a time and then all three together: every run printed a/x b/ top, empty stderr, no object read. The b/ entry survives, so your rejection still fires.

So at 2.43 the boundary holds under config drift. That was the edge I expected to leak.

The part I would keep from your bug is the general signal. The only evidence of the missing paths was stderr. rc was clean.

Does Profile A now fail closed on any non-empty stderr from the Authority query, or only on the sparse entry it knows about?

Agreed on stderr. And here is a case that makes your point for you: incomplete, rc 0, stderr empty.

git 2.43.0. Full index, no sparse checkout: a/x b/y b/z top. Explicit --git-dir and --work-tree on the command line. Then one inherited environment variable.

env                                  ls-files --sparse -z   rc   stderr
(clean)                              a/x b/y b/z top        0    0 bytes
GIT_INDEX_FILE=<1-entry index>       a/x                    0    0 bytes
GIT_INDEX_FILE=<path that is absent> (nothing)              0    0 bytes

--git-dir does not override it. An absent index file reads as an empty index, not an error.

No sparse-directory entry, so the representation check passes. A stderr rule would pass it too. Neither channel can see it.

It is not a qualification-to-consumption race either. The index Profile A qualified is just not the file Git read.

Does Profile A build its subprocess environment from scratch, or inherit the caller's and assume GIT_* is unset?

Then one carrier is missing from that list: GIT_CONFIG_PARAMETERS.

It is the older channel for -c, the one Git itself uses to hand config to child processes. GIT_CONFIG_COUNT is the newer one. 2.43.0 still honors both.

Same repo, same explicit --git-dir / --work-tree, plus GIT_CONFIG_PARAMETERS="'core.bare'='true'":

git config --local --get core.bare   false
git config --get core.bare           true    (scope: command)

So git config --local qualifies one config and the consumer runs under another. The local check cannot see the override by construction, it only reads the one file. GIT_CONFIG_GLOBAL gives the same split.

What I do not have is a key that changes the ls-files --sparse -z path set on a full index. core.bare=true still lists all four paths, rc 0.

Is the strip list closed over what can change the answer, or over everything that can reach config?

The include rejection has to cover config.worktree too, and the scoped queries won't show you why.

git 2.43.0. extensions.worktreeConfig=true, local core.bare=false, and config.worktree holding only [include] path = inc.cfg, where inc.cfg sets core.bare = true:

git config --local --get-regexp include          (nothing, rc 1)
git config --worktree --get core.bare            (unset, rc 1)
git config --worktree --includes --get core.bare true
effective core.bare (NOSYSTEM, GLOBAL=/dev/null) true   scope: worktree, origin: inc.cfg

A scan of the local file finds no include. A scoped read of the worktree file says unset, because scoped git config reads are include-blind by default. The unscoped merge you now defer to follows the include and says true.

So it is the same qualified container != qualified consumed object split, one file over.

A smaller trap if the scan goes through --get-regexp: git prints the section lowercased, includeif.gitdir:<path>/.path. A case-sensitive match on includeIf counts 0 of 1.

Does the include/includeIf rejection run over every file in the allowed closure, the enabled config.worktree included, or only over the qualified local config?