kanaria007 PRO

Thanks, it was not deliberate. It was the one missing witness class in this precedence test.

Your mutation makes the gap very clear: the existing cases reached CR, LF, a selected marker, and the residual ASCII envelope case, but none of them made the relative position of isascii() and the envelope observable.

I added a U+00FC (ü) case for exactly that reason.

It is:

• non-ASCII;
• not one of the current _FILLER_MARKERS;
• outside the lowercase-hex construction envelope.

With the intended order, it must therefore reach isascii() first and report the isascii() diagnostic. If the envelope moves ahead of isascii(), the observed attribution changes to the alphabet diagnostic.

The new case goes through the same shared _check_dynamic_probe_filler() path as the other precedence witnesses; there is no second hand-copied ordering model.

I am also treating U+00FC strictly as a test-only precedence witness, not as a new regional representation class. The matrix claim surface is unchanged.

I tightened the wording around what the regression actually promises as well. The interesting contract is not an arbitrary exact total order among all five guards — for example, I do not particularly care whether CR precedes LF as an abstract property. What matters is the diagnostically meaningful partial order: specific attribution should remain reachable before broader or residual exclusion can shadow it.

So I think the reusable rule becomes slightly sharper:

A precedence boundary is only tested when some witness changes its observed attribution if that boundary is inverted.

Or, shorter:

No distinguishing witness, no precedence evidence.

Your “a precedence test is worth what it fails on” mutation was the right way to expose this one. Thanks for pushing the rule back onto the test itself.

Thanks. Yes, the ordering matters, and envelope-first was not deliberate.

Your 110-byte count also changes how I would describe the relationship between the two layers.

I had written that a wider claim vocabulary could eventually eliminate the gap between the claim-bound checks and the lowercase-hex envelope. That is technically true, but misleading as a design direction. The measured residual is much larger and more structural than that wording suggests: adding TAB would only move it from 110 to 109. Eliminating it would effectively mean modeling the whole non-hex ASCII space.

So I now think the cleaner distinction is:

• the named checks describe the representation classes this matrix currently claims to discriminate;
• isascii() catches the remaining non-ASCII space;
• the lowercase-hex restriction is intentionally broader and remains a residual fixture-construction backstop.

I did not add TAB or any other new class.

I also changed the fail-fast ordering to:

CR → LF → selected multibyte markers → isascii() → lowercase-hex envelope

so the most specific modeled class gets to name the failure before a broader guard shadows it. A wrapped filler now reaches the LF diagnostic first; selected multibyte contamination reaches its marker-specific diagnostic; unrelated non-ASCII falls to isascii(); TAB/NUL/space/uppercase-style drift falls through to the envelope.

I also pinned that ordering through the actual shared guard path rather than testing a separately duplicated ordering model, so the regression test cannot stay green if the real guard sequence drifts.

I think the reusable rule here is:

In a fail-fast harness, order specific attribution before residual exclusion.

Or more generally: a diagnostic guard only contributes the diagnostic role we attribute to it if that guard is actually reachable as the observed failure.

Thanks for measuring the byte-space rather than leaving the “wider vocabulary” claim qualitative. The 110-byte number made the boundary much clearer.

Thanks, your table convinced me that the labels were wrong even though the fixture behavior was right.

I changed the documentation around test_dynamic_probe_filler_is_marker_free to separate three different roles more accurately.

The lowercase-hex restriction is now described as the fixture's construction envelope, not as a disposable implementation choice. Its useful property is broader than the current marker list: it keeps the filler vocabulary deliberately narrower than the representation vocabulary, so edits such as TAB-separated formatting, NUL padding, uppercase hex, or a different alphabet are rejected before they can quietly become new fixture semantics.

The CR/LF/current-marker checks are now described as claim-bound checks for the representation classes the matrix models today.

And I corrected the multibyte description as well: for the current selected UTF-8 markers, those explicit checks are not an independent enforcement dimension beyond isascii(). They remain useful because they make the intended representation exclusions local and diagnostic, but I no longer count them as separate assurance.

So the dependency is now stated in the right direction:

lowercase hex -> ASCII -> current selected multibyte markers absent

but absence of those selected markers does not imply ASCII.

On TAB specifically: yes, I think an ASCII-control representation class is a plausible future matrix extension, with TAB being the obvious first candidate. I did not add it now, though. The current matrix is still a bounded falsifier for the failure families it already claims to exercise, and I do not want to broaden that claim surface just because another class is imaginable.

What I did make explicit is the maintenance relationship you pointed out: the filler vocabulary and the modeled representation-class vocabulary are coupled fixture structures. If a new class such as TAB is added later, the filler-envelope assumptions need to be revalidated at the same boundary.

There is another reusable rule here too:

Qualify the guard before attributing assurance.

A guard's assurance role should come from what it independently excludes, which other guards subsume its exclusion set, and which claim boundary it actually protects — not from how important its comment sounds.

Your table was a nice small example of exactly that: it tested the docstring's classification instead of trusting the classification because it was written down.

Thanks, I think your reclassification is exactly right, and the measurement made the reason stronger than either of us had stated before.

The singleton property was not drifting with size. The current filler is plain hex and disjoint from all five representation-marker classes, so its growth cannot accidentally mint another CRLF, bare LF, or selected multibyte sequence.

The remaining issue was one layer higher: that property was load-bearing for the mutation experiment, but the harness was relying on it rather than independently proving that the experiment it was about to interpret was actually a single-cell removal.

I tightened that boundary.

The harness now checks the baseline witness counts before constructing any validator claim: every one of the 15 regional cells must have exactly one witness. For each mutant, it then verifies that the target changed from exactly 1 -> 0 and that every non-target cell count remained unchanged. Only after those checks pass is the validator allowed to produce a survivor or localization result.

I also pinned the 64-column wrapping case directly. A formatting change that introduces additional bare LFs now fails as a fixture precondition failure before the validator is evaluated, rather than surfacing as “removed but undetected.”

So the distinction is now explicit:

removed 1 of N, where N > 1
→ the falsifier itself is not admissible for that claim

removed 1 of 1, target becomes 0, everything else stays fixed
→ now the validator can legitimately be implicated if it misses the removal

I think there is a useful general rule hiding in this one:

Qualify the intervention before attributing the outcome.

A detector can only be blamed after the harness has independently established that the condition it was supposed to detect was actually instantiated. Otherwise a red test may still be useful, but its failure attribution is unsound.

That also sharpens the point you made about this being fail-loud rather than fail-silent. The suite was already telling us that something had gone wrong; what it did not yet know was which layer had gone wrong.

Thanks for going back and measuring the original drift hypothesis rather than carrying it forward. The correction itself exposed the more interesting issue.

Yes, I took the sharper version and turned it into an explicit first-order mutation test.

The regional claim is now represented as exactly fifteen pinned cells:

5 representation classes × 3 regions

with the exact ordered set itself asserted separately, so the mutation matrix cannot silently shrink from 15/15 to 12/12 if a class disappears from the enumeration.

For each cell, one at a time, the test:

1. starts from a genuine generated probe;
2. locates that marker from the actual emitted bytes rather than re-deriving the generator's placement arithmetic;
3. overwrites only that marker with the corresponding bytes from the plain ASCII dynamic probe;
4. checks that length and UTF-8 validity are unchanged;
5. runs the per-class/per-region validator;
6. requires the validator to report exactly that one cell as missing.

So the acceptance condition is stronger than “some assertion went red”:

remove(cell_i) -> missing == [cell_i]

for all fifteen cells independently.

I also pinned the fifteen-cell inventory itself separately. That closes a smaller self-reference trap I noticed while implementing your suggestion: if the mutation test merely iterated whatever cells the validator currently knew about, deleting a class from both sides could reduce the matrix to 12/12 and still look healthy.

The current result is:

15 mutants
15 detected
15 correctly localized
0 survivors
0 mislocalized
0 impure mutants

The mutation harness does not reuse the generator's placement formulas. It scans the actual generated payload for the claimed marker in the claimed region, then removes that observed marker. That keeps “where the generator says it wrote something” separate from “what the fixture actually contains.”

So this is now red-run evidence at the same resolution as the regional claim, rather than an inference from reading the validator.

I also kept the scope narrow. This is first-order single-placement falsification of the fifteen regional claim cells, not pairwise or higher-order combinatorial mutation coverage. I do not think fifteen separate named test functions are the important property here; detection and localization at the fifteen-cell claim surface are.

Your unrelated-package example helped sharpen why.

A differential metric can be perfectly implemented and still have a common-mode fault direction that leaves the published value unchanged. The earlier shared 😀 witness had the same structural shape at a smaller scale: two claims intended to be independently falsifiable collapsed onto one observation, so one claim could disappear without changing what the validator saw.

The failure mode in both cases is not simply “insufficient test count.” It is an observationally null fault direction: a claim-relevant change exists that the evidence mapping does not distinguish.

Splitting 🧪 from 😀 removed one such ambiguity between the regional and alignment claims. The fifteen one-at-a-time removals now test the next level down: whether each declared regional cell is itself distinguishable under the selected single-removal fault family.

So I think the rule sharpens beyond just matching assertion structure:

A claim is only as fine-grained as the smallest claim-relevant fault its evidence system can distinguish.

Or operationally:

claim granularity, validation granularity, and falsification granularity should agree at the surface being asserted.

That still does not imply exhaustive combinatorial coverage. The fifteen removals establish first-order sensitivity for the fifteen declared cells; they do not prove arbitrary two-cell interactions, substitutions, relocations, or unrelated representation transforms.

Thanks — this was a good next test because it moved the question from “is the validator written at the claimed resolution?” to “can the evidence system actually observe a fault at that resolution?”

That is a much stronger distinction.

Yes, I ended up taking both.

The overlap is now a construction failure rather than a silent yield, and the fixture tests now assert the representation classes independently per region instead of collapsing them through the old OR predicate.

I also took your +3 adjustment for the two colliding CRLF positions. At the current 262,144-byte live-domain-derived probe size, that gives CRLF in all three regions while preserving all 14 selected boundary straddles.

There was one more version of the same problem hiding underneath that: the regional 4-byte markers and the selected-boundary 4-byte markers were initially the same code point, so a missing regional marker could still be masked by a boundary marker in the same region.

I split those as well:

regional 4-byte marker -> 🧪
selected-boundary straddle marker -> 😀

so the two claims are now independently observable rather than merely independently placed.

The generator contract is now effectively:

required placement collision -> construction error
regional representation -> CRLF / bare LF / 2-byte / 3-byte / 4-byte independently present in early, middle, and late regions
selected-boundary alignment -> 4-byte UTF-8 straddles every selected power-of-two boundary

I added a direct collision regression as well, rather than relying only on a too-small probe failing out of bounds. The probe fixture suite now passes 26/26, and removing only the regional 4-byte placements now correctly breaks the regional-distribution test instead of being masked by the alignment markers.

So I think your diagnosis was right: the problem was not another missing sentinel. It was that the sentinel generator could silently fail to realize part of the evidence surface it claimed to construct, and its own validation was coarser than that claim.

The useful rule I am taking from this round is:

For required test evidence, construction should fail closed, and fixture validation should be at least as fine-grained as the evidence claim it supports.

Thanks, this was a good catch. The second sentinel still keeps the diagnostic separation we wanted, but required evidence can no longer disappear silently during fixture construction.

Yes, I think this attack found a real missing interaction cell rather than another weakness in either V2 or the size sentinel individually.

The suite had per-axis coverage on both dimensions:

representation fidelity -> V2
large-input consumption -> fixed ladder + dynamic size sentinel

but it did not have joint coverage of representation-sensitive behavior at large sizes. Your gated-CRLF mutant and chunked decode/re-encode mutant sit exactly in that empty interaction cell.

I kept the existing dynamic size sentinel unchanged and added a second dynamic representation-at-scale sentinel rather than folding the two responsibilities together.

The evidence split is now:

V1 -> literal algorithm/object-format KAT
V2 -> literal representation-fidelity KAT
fixed ladder -> stable bounded consumption/elision falsification
dynamic size sentinel -> current live-domain size applicability
dynamic representation-at-scale sentinel -> bounded representation × size × selected-boundary alignment interaction falsification

Both dynamic sentinels use the same live-domain-derived target size, so there is still only one size authority. At the current live maximum of 142,699 bytes, both are 262,144-byte probes.

The new probe is deterministic, exact-length, and valid UTF-8. It distributes mixed CRLF/bare-LF and recurring 2-, 3-, and 4-byte UTF-8 sequences across the payload rather than concentrating the representation-sensitive material in a small prefix.

It also deliberately places multibyte sequences across a bounded set of selected power-of-two internal boundaries. Those are adversarial test points, not a claim that an implementation uses those chunk sizes, and not a claim of arbitrary chunk-boundary coverage.

The probe generator itself is tested for the properties it claims: exact length, UTF-8 validity, line-ending diversity, 2/3/4-byte sequences, distribution across early/middle/late regions, and actual straddling at each selected boundary.

The new sentinel is then compared against the same independently anchored full-byte reference under all three independently maintained content-identity implementations and both git-blob-sha1 and lfs-sha256.

I also reran the two failure families you demonstrated.

For the gated CRLF transform:

replace(CRLF, LF) if len(raw) > 88

I now get the diagnostic shape I wanted:

V2 -> PASS
dynamic size sentinel -> PASS
representation-at-scale sentinel -> FAIL

The 4096-byte chunked decode/re-encode mutant produces the same separation:

V2 -> PASS
dynamic size sentinel -> PASS
representation-at-scale sentinel -> FAIL

So the new test is not just making the suite red somewhere; it localizes the missing evidence to the representation × scale/alignment interaction.

I deliberately stopped there.

I did not add arbitrary chunk-size enumeration, NFC/NFKC cases, BOM stripping, whitespace normalization, or a Cartesian product of every representation factor. The documentation now says explicitly that the selected boundaries and representation classes are finite adversarial evidence, not a proof over arbitrary future transforms or chunk boundaries.

So the contract remains:

identity is over the complete, exact raw byte sequence.

The evidence remains finite and factorized:

stable literal anchors + stable bounded falsifiers + live-domain size evidence + one independently diagnosable interaction sentinel.

Your 27/27 observation was the part that convinced me this was worth adding: every large tracked file currently contains non-ASCII bytes, while every large synthetic identity probe had been ASCII-only. That was a real mismatch between the live domain and the joint evidence surface, not merely a hypothetical mutant.

Thanks, this one moved the design from per-axis coverage to explicit interaction evidence without turning the size sentinel into a mega-fixture.

Thanks, this was a useful attack, especially because it exposed that the fixed ladder was doing more than I had described.

You are right about what killed M7. The metamorphic half alone was not enough: digest_a != digest_b still held because your head+tail implementation consumed the differing tail. The failure came from the independent full-byte reference comparison on each generated payload.

I have updated the implementation and documentation around that distinction.

I kept V1, V2, and the fixed ladder unchanged:

V1 -literal algorithm/object-format KAT
V2 -literal representation-fidelity KAT
fixed ladder -stable bounded conformance/falsification evidence

The ladder is now described more accurately as combining two checks:

• a metamorphic tail-sensitivity relation;
• a full-reference comparison for each generated payload.

So it can falsify prefix truncation and other byte-elision strategies that produce a non-reference identity at those bounded probe sizes. I stopped short of describing that as a proof against every possible non-full-consumption implementation, because the fixture set is still finite.

You are also right that the top 256 KiB boundary produces a 393,216-byte payload, so the effective size of that particular fixed probe is 384 KiB rather than 256 KiB.

I did not, however, turn that number into either a repository limit or a permanent “add another rung here” threshold.

Instead I split stable diagnostic/conformance evidence from current live-domain size coverage.

I added a deterministic dynamic live-domain sentinel. The test measures the current maximum byte size among payloads covered by the live qualification surfaces of the three content-identity implementations — declared Markdown, generated projections, and the wrapper/checker source payloads themselves — and generates a synthetic sentinel at the next power of two strictly above that maximum.

That sentinel is then checked against the same independently anchored full-byte reference by all three independently maintained content-identity implementations, under both git-blob-sha1 and lfs-sha256.

This is a size-domain sentinel, not a representative sample of repository content.

So the structure is now:

unbounded contract
-identity is over the complete, exact raw byte sequence

stable evidence
-V1 / V2 / fixed 1-8-64-256 KiB ladder

current-domain size applicability evidence
-dynamically sized sentinel beyond the current live qualified-payload maximum

This means I did not add:

• manifest path <= 393,216 as an admissibility rule;
• a repository/runtime content-size ceiling;
• a manual rule saying that crossing 384 KiB earns another fixed rung.

If the repository grows, the dynamic sentinel grows with it automatically. The fixed ladder remains corpus-independent and useful for stable diagnostics, while the live-domain size evidence follows the size domain whose coverage claim it is actually supporting.

The documentation also now explicitly says that neither the fixed ladder nor the dynamic sentinel proves correctness for arbitrary future input lengths. The contract is unbounded; the evidence is finite and scoped.

So I ended up taking a third route relative to your final question:

do not constrain the repository to the finite falsifier, and do not rely on remembering to extend the ladder when the corpus grows. Let a separate size-applicability probe scale with the live domain instead.

Thanks again — the M7 mutation was what made the distinction between the ladder's metamorphic role and its full-reference role visible enough to separate those two kinds of evidence cleanly.

Thanks for rerunning M6 and for separating the actual no-manifest result from the mutation. Your revised result matches the dataflow I had in mind: with provider-derived full-file identity on the expected side, a prefix-only implementation is a hard outage on the untouched revision-bound tree, not a silent acceptance.

I have implemented the follow-up.

I kept V1 unchanged and added V2 as a second pinned literal known-answer vector. V2 stays deliberately small and is focused on the representation dimensions V1 cannot exercise: multibyte UTF-8, mixed CRLF/LF, and preservation of the exact raw byte sequence.

I did not put the prefix-cutoff ladder inside V2, and I ended up making the distinction stronger than “third vector class.”

The split is now:

V1 -basic algorithm/object-format literal known answer
V2 -exact-byte representation adversarial literal known answer
tail ladder -deterministic metamorphic falsifier for prefix truncation / omitted suffix consumption

The ladder probes:

1 KiB -8 KiB -64 KiB -256 KiB

Each rung generates two equal-length inputs that share the entire prefix through the selected boundary and differ only in a distinctive tail beyond it. The same probes are applied to all three standalone content-identity implementations, under both git-blob-sha1 and lfs-sha256.

I deliberately did not pin a large table of ladder digests. The test-only reference calculator is itself checked against the pinned V1/V2 literals, and the generated tail pairs are then compared against that reference. So V1/V2 remain the concrete known-answer anchors, while the ladder acts as a bounded metamorphic falsifier for prefix truncation / omitted suffix consumption.

I also kept your logarithmic sizing idea but did not define a “largest plausible cutoff.” Every finite prefix-only cutoff is wrong under the contract. The 256 KiB top rung is only a finite diagnostic probe, not a semantic limit, runtime chunk size, or repository-size promise. I chose 256 KiB rather than something derived from the current 142,699-byte corpus maximum specifically so the fixture does not track mutable repository state.

The invariant remains:

identity is computed over the complete, exact raw byte sequence.

The finite probes are bounded falsifiers against known wrong implementation families; they do not define how much input an implementation is allowed to consume.

I also made the no-manifest boundary more explicit in the tooling documentation. Rather than treating assurance as a binary local/strict distinction, the documentation now separates three orthogonal dimensions: path authority, revision binding, and content-identity policy.

Ordinary local git ls-files operation remains a tracked working-tree-candidate check and makes no independent revision-qualified byte-identity claim; the webhook path is the strict revision-qualified profile that combines manifest authority, expected-revision binding, and mandatory content identity.

So I think the two findings now land in separate places:

• M6 exposed a real conformance-test gap, now covered by the tail falsifier;
• the no-manifest experiment exposed an assurance-posture boundary, now documented more explicitly rather than being turned into a self-derived local byte-identity check.

Thanks for pushing both far enough to distinguish those two.

Yes. I agree with the V1 result: the oracle is now independent, but the payload is not discriminating enough. A 36-byte ASCII+LF vector cannot exercise byte-vs-character length, suffix consumption, or CRLF preservation, so M5/M6/M8 surviving it is expected once you look at the input shape.

And thanks for checking the literals against git hash-object and sha256sum. That gives the literals an independent external cross-check in this review, rather than only another Python computation.

I would add V2, but I would not size it against the current corpus maximum.

The corpus size is current repository state, not part of the content-identity contract, and I do not want a versioned KAT to grow every time the largest tracked file grows. I also would not make any current read-chunk size part of the contract.

The contract I want is simpler:

the identity is computed over the complete, exact raw byte sequence, with no decoding, newline normalization, prefix truncation, or character-length substitution.

So I would keep V1 pinned and add an adversarial V2 that crosses the dimensions V1 cannot:

• multibyte UTF-8 content;
• CRLF as well as LF;
• length beyond a deliberately chosen test boundary, explicitly not a runtime or corpus invariant;
• a distinctive tail marker beyond that boundary.

I would also add a suffix-sensitivity case rather than asking one finite payload to stand in for arbitrary-length consumption: two equal-length byte strings with an identical long prefix and a difference only near the tail, each checked against independently pinned expected digests. That gives us a direct falsifier for prefix-only hashing.

So the test split would be:

V1 -basic algorithm/object-format known answer
V2 -encoding/newline/boundary adversarial known answer
tail sensitivity -prefix-truncation / suffix-consumption falsifier

One point where I read the production consequence differently is M6.

I agree that M6 survives V1, and the conformance suite should kill it. But I do not think a prefix-only implementation fails open in the strict revision-bound chain as it stands.

The expected identity there is the provider-reported full-file Git/LFS identity from revision-bound tree metadata. A prefix-only implementation on a file larger than its cutoff would therefore disagree with the legitimate full-file identity on the unmodified file itself and fail closed.

A same-size suffix edit would preserve the mutant's truncated observed digest, but that truncated digest would still not equal the provider's full-file expected digest. For it to fail open, the expected side would also have to be produced through the same truncated mapping — essentially the self-referential-oracle class we just removed.

So I would classify M6 as:

• a real conformance gap in V1;
• a live implementation mutation worth killing;
• but, under the current revision-bound provider-identity chain, fail-closed rather than fail-open.

If your generate returns 0 M6 run used the provider-derived full-file identity as the expected value, I would be interested in the exact harness, because that would contradict the dataflow above and would be a separate gap worth reproducing.

On your sizing question, then: neither the corpus maximum nor the current chunk size is the invariant. I would make V2 stable and deliberately boundary-crossing, and use the tail-sensitivity case as a separate falsifier for prefix truncation and omitted suffix consumption.

Yes, mutation C makes the problem clear. The checker-boundary test was self-referential: _good_manifest() derived the expected digest from the same _compute_content_identity() implementation that qualify_and_write_checker() was supposed to test. So it established internal consistency, not correctness.

I fixed the coverage asymmetry first and failed to check the independence of the test oracle. That was the missing step.

I have fixed that now.

Rather than only replacing the checker fixture with another per-test hashlib derivation, I added a small versioned test-only known-answer vector:

fixed bytes + identity kind + pinned literal expected digest

The same vector is now applied independently to all three standalone content-identity implementations:

• the bootstrap implementation;
• the wrapper's _compute_content_identity();
• repo_integrity.py's compute_content_identity().

The pinned literals are separately sanity-checked against direct hashlib reference computations, but none of the three implementations under test produces its own expected value.

On your three-copy question, I think this gives the boundary I want:

runtime separation, test-level convergence on an independent known-answer witness.

I still do not want one repository-side implementation to establish another implementation's correctness at runtime by agreeing with it. That would weaken the staged trust chain.

But the three implementations should absolutely meet at the conformance boundary. I prefer having each of them reproduce the same pinned known-answer vector over making three-way agreement itself the primary oracle, because A == B == C can still be true when all three are wrong in the same way.

A direct three-way comparison could still be a useful secondary drift check, but it is no longer needed as the common witness: all three now independently converge on the same pinned answer.

So yes: your mutation table exposed a real test-oracle bug. The shipped hashing code was correct, but the checker test could not independently distinguish that correctness from a mirrored bug. It now has an independent witness for that contract.

I read .gitattributes here as current repository configuration, not as a storage invariant.

The fact that all 1052 tracked paths are Git blobs today is useful evidence about the current repository state, but nothing in the tooling says that *.py must remain outside LFS. The identity model treats git-blob-sha1 versus lfs-sha256 as a provider-reported storage fact, and the executable qualification boundary only requires a usable supported identity.

So I treated the asymmetry as a test-coverage gap rather than a verifier-contract difference.

I added the missing coverage at the second executable boundary:

• a valid lfs-sha256 identity now exercises successful qualification of repo_integrity.py;
• an unsupported identity kind now exercises the fail-closed path before the checker is written or executed.

That makes the two executable boundaries consistent: both explicitly cover both identity kinds accepted by the verifier, and both reject unsupported kinds without execution.

I did not add a rule that repository-side executables must be Git blobs, and neither boundary infers its admissible identity kinds from the current .gitattributes. If that ever became an intended invariant, I agree the cleaner implementation would be to assert git-blob-sha1 explicitly and remove the LFS branches instead.

For now, I read it as a property, not a guarantee. The second boundary was under-tested; that gap is now covered.

Yes. I ended up treating the requirement as following consumption, not the mount transport specifically. HTTPS versus a mounted volume is just a transport distinction; neither makes repository bytes trustworthy by itself.

The bootstrap wrinkle was the important part. I did not want repo_integrity.py to establish trust in its own bytes by executing its own compute_content_identity(), so the qualification chain is now staged.

The separately deployed gateway is the trust root for this flow. It resolves and passes the expected content identity for hf_integrity_job.py from tree metadata at the validated trigger SHA before starting the billed Job. The inline bootstrap then fetches that wrapper over HTTPS and verifies the fetched bytes before runpy.run_path() is allowed to execute them.

Once the qualified wrapper is running, it builds the exact-revision manifest first, fetches repo_integrity.py, and qualifies those bytes against the manifest entry before the checker is executed. repo_integrity.py never participates in establishing its own identity.

So the implemented chain is now:

• deployed gateway resolves the wrapper identity at the trigger SHA;
• bootstrap qualifies the repository-side wrapper before execution;
• qualified wrapper builds the exact-revision manifest and qualifies the checker;
• qualified checker qualifies the repository content it consumes;
• derivation constructs;
• check compares.

Missing or unsupported identity now fails before the relevant executable runs, and same-size wrong-content substitution is covered at both executable boundaries. The manifest writer remains a generic fact carrier; it still has no executable-file-specific policy.

I also removed the dead read_text() helper.

The new regression coverage pins both stages directly: wrapper qualification, checker qualification, manifest-before-checker ordering, and no execution on missing identity, truncation, or same-size wrong bytes.

So yes — the requirement ended up following consumption all the way out to the executable bootstrap boundary, rather than stopping at mounted repository content.

Yes. The tautology point changes the shape of the fix in a useful way.

I am going to remove validate_committed_paths() rather than convert it. Once the committed JSON has matched the deterministic projection generated from the authoritative markdown_paths, that second locator-membership pass has no independent failure mode. The 1,568/1,568 replay makes that especially clear.

On the hard-fail question, I am choosing the consumer boundary rather than expanding the writer policy.

More precisely, I am also removing the current .md-specific metadata requirement from write_repository_paths_manifest(). The manifest writer should just carry the facts the tree API provides for the requested revision: paths, revision, and whatever size/content-identity metadata is available. It should not need to know which files a later checker happens to consume.

The strict checker then owns the requirement:

every mounted repository file whose content it actually consumes must have a usable content identity when --require-content-identity is active.

That includes the declared Markdown corpus and all four generated outputs. So if the tree API stopped returning oid for either generated JSON file, the manifest could still be constructed, but the strict check would fail that file before decode and before projection comparison.

The common read path becomes:

• one mounted read;
• size check if size metadata is available;
• identity presence required in strict mode;
• identity verification when present;
• decode only after qualification.

Size stays a truncation diagnostic. Content identity is what qualifies the observed bytes.

I am also separating the remediation cases more carefully. If a required generated output is absent from the authoritative repository path set, that is a missing committed projection, and generate + commit is an appropriate remedy. But in the revision-pinned path, once the generated path is present in the authoritative repository path set, a read, size, missing-identity, or identity-mismatch failure is an observation failure, so the checker must not tell the maintainer to regenerate. Only identity-qualified committed text that differs from the deterministic projection is genuine generated drift.

So the resulting split is smaller than the one I had in mind:

Authority describes. Observation qualifies. Derivation constructs. Check compares.

And your two JSON OID checks are useful confirmation of the current provider behavior. With the new boundary, if that behavior stops holding, the strict check fails explicitly rather than silently weakening its revision observation.

Yes. Both are leftovers of the previous observation surface.

And your distinction on arm A is important: it is not a false green. It is a false diagnosis with a dangerous remediation. The run fails, but it reports committed-output drift and tells the maintainer to regenerate when the actual failure is that the mounted generated output did not match the revision.

The generated outputs should therefore be revision-bound before any drift comparison. I am going to put all four generated outputs through the same single-read path as the corpus:

• read once;
• size check;
• content-identity check;
• decode;
• only then compare against the regenerated projection.

For the two generated JSON files, that same validated text can then be parsed and reused by validate_committed_paths(). There is no reason for that function to ask (root / locator).is_file() anymore now that the authoritative repository path set is already in scope.

So the locator check becomes membership in repository_paths, using the repository-namespace spelling as the authority rather than whatever spelling the host filesystem happens to resolve.

That also removes the second filesystem read of the generated JSON: the bytes whose revision identity was verified are the same bytes whose inventory/resolver locators are subsequently validated.

And thank you for replaying the whole chain rather than just reading it. The 873/873 blob matches are useful confirmation that the tree API oid interpretation is actually holding across the declared corpus, rather than merely being an assumption embedded in the implementation.