Correct a false claim in .gitattributes, and control two uncontrolled gates - #6
Merged
Conversation
… gates The .gitattributes comment said a gate compares the committed bytes to a fresh render, and that normalizing line endings per platform would make that comparison depend on who checked the repository out. Neither is true. Both sides of the comparison are read with Path.read_text, which applies universal-newline translation, so the comparison passes on a CRLF checkout with or without the pin. The pin is still worth keeping, for a narrower reason. The receipt records each drawing's byte count and SHA-256 read from the checked-out file, and those two numbers do depend on the checkout. The comment now says that instead. The test file already proved the outcome-box gate can fail, by pointing ART at a throwaway spec whose note is far too wide. The wrapper gate and the tagline gate had nothing of the kind: twelve green lines said they ran. The three geometry checks now take their spec list as an argument instead of reading the loaded set directly, and art.the_gate_can_fail feeds them one spec built to break all three at once: a note too long for the wrapper, a tagline past the rule, and an outcome band with one over-wide label and one over-long note. It asserts the exact count of complaints, so a check that half-works is caught too. Verified against a deliberately weakened copy of the module, where the control names the budgets that stopped catching anything. GATES in the test names its gates rather than counting them, so the new one is added there. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
HarperZ9
added a commit
that referenced
this pull request
Sep 3, 2026
… gates (#6) The .gitattributes comment said a gate compares the committed bytes to a fresh render, and that normalizing line endings per platform would make that comparison depend on who checked the repository out. Neither is true. Both sides of the comparison are read with Path.read_text, which applies universal-newline translation, so the comparison passes on a CRLF checkout with or without the pin. The pin is still worth keeping, for a narrower reason. The receipt records each drawing's byte count and SHA-256 read from the checked-out file, and those two numbers do depend on the checkout. The comment now says that instead. The test file already proved the outcome-box gate can fail, by pointing ART at a throwaway spec whose note is far too wide. The wrapper gate and the tagline gate had nothing of the kind: twelve green lines said they ran. The three geometry checks now take their spec list as an argument instead of reading the loaded set directly, and art.the_gate_can_fail feeds them one spec built to break all three at once: a note too long for the wrapper, a tagline past the rule, and an outcome band with one over-wide label and one over-long note. It asserts the exact count of complaints, so a check that half-works is caught too. Verified against a deliberately weakened copy of the module, where the control names the budgets that stopped catching anything. GATES in the test names its gates rather than counting them, so the new one is added there. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A correction first
The
.gitattributescomment I merged here said this:That is not true, and I wrote it. The gate compares like this:
Path.read_textapplies universal-newline translation, so a CRLF checkout isread back as LF and the comparison passes with or without the pin. The gate was
never at risk.
The pin is still worth keeping, for a narrower reason. The receipt records each
drawing's byte count and SHA-256 read from the checked-out file with
read_bytes, and those two numbers do depend on the checkout. The pin keeps themthe same for everyone. The comment now says that and nothing more.
What the gate could not do
tests/test_repo_art.pynames its gates and asserts they all report clean.Twelve green lines say the checks ran. They do not say the checks work: a check
that returns
[]unconditionally is indistinguishable from one that foundnothing wrong.
art.the_gate_can_failcloses that. The three geometry checks now take theirspec list as an argument instead of reading the loaded set directly, and the new
check feeds them one spec built to break all three at once:
It asserts the exact count of complaints, so a check that catches one problem
out of two fails here too. Verified against a deliberately weakened copy of the
module: with
TAGLINE_BUDGETraised to 10000 and the page widened to 100000, thecontrol goes from empty to naming both budgets that stopped catching anything.
What this does not cover
The renderer itself is unchanged, and no drawing moves. Nothing here checks that
a drawing looks right, only that its text fits the shapes it is drawn into.
🤖 Generated with Claude Code