ci(now-gate): the frozen archive is declared, not detected - #3390
Open
gHashTag wants to merge 1 commit into
Open
ci(now-gate): the frozen archive is declared, not detected#3390gHashTag wants to merge 1 commit into
gHashTag wants to merge 1 commit into
Conversation
`docs/NOW.md` carries "FROZEN ARCHIVE -- do not add entries here." on its first
line, and nothing enforced it. Measured: every mention of that path under
`.github/workflows/`, `scripts/` and `.githooks/` is a comment -- zero lines
reject an edit -- so an author following one of the stale instructions that
pointed there could reopen the archive and pass all four required checks.
BOTH detection rules were measured, and both fail on the same commit.
"Refuse any diff touching it" blocks `458ec0bd6`, which REPAIRS destroyed
entries: of the 600 commits since the freeze, 2 touch the file and that is one
of them. So does the narrower "refuse an ADDED `## ` heading" I proposed as the
replacement -- that repair adds three, because it restored headings whose bodies
had been destroyed. My recommendation was wrong in the same direction twice, and
the second time I had not run the replacement past the exception that killed the
first.
No textual rule separates adding an entry from repairing one: the only
difference is POSITION, which is the coupling the one-file-per-entry layout
exists to remove.
So the exception is DECLARED, where the tool looks -- the shape `# tri:no-dispatch`
and `# tri:cause-removed` already use here. A commit that edits the archive on
purpose says so:
Archive-Repair: <what was damaged, and how you know>
The gate does not judge the reason. It requires one to exist, so reopening a
frozen file is a decision somebody signed rather than an accident.
Six controls, run against a scratch repository rather than reasoned about: PR
and push, each with and without the trailer; a trailer carrying no reason
(refused); and a range that does not touch the file (unchanged). Historical
control: `458ec0bd6` carries no trailer and would be refused -- correctly; the
point is not to permit it retroactively.
My own probe was the broken instrument first: `git reset --hard` removed
`docs/now/`, the entry file could not be written, and two cases failed on the
presence check instead of on the guard. Fixed the harness, not the reading.
R12 states the rule; LOOP-RULES.sha256 moves with it in this commit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
enabled auto-merge
September 6, 2026 17:59
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Sep 6, 2026
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
1 participant
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.
Refs #3368
docs/NOW.mdcarries "FROZEN ARCHIVE — do not add entries here." on its first line, and nothing enforced it. Measured: every mention of that path under.github/workflows/,scripts/and.githooks/is a comment — zero lines reject an edit. An author following one of the stale instructions that pointed there could reopen the archive and pass all four required checks.Both detection rules were measured, and both fail on the same commit
458ec0bd6, which repairs destroyed entries. Of the 600 commits since the freeze, 2 touch the file and that is one of them.##heading" — the narrower rule I proposed as the replacement — blocks it too: that repair adds three, because it restored headings whose bodies had been destroyed.My recommendation was wrong in the same direction twice, and the second time I had not run the replacement past the exception that killed the first.
No textual rule separates adding an entry from repairing one: the only difference is position, which is the coupling the one-file-per-entry layout exists to remove.
So the exception is declared, not detected
The shape
# tri:no-dispatchand# tri:cause-removedalready use here:The gate does not judge the reason. It requires one to exist, so reopening a frozen file is a decision somebody signed rather than an accident.
Controls — run, not reasoned about
docs/NOW.md, no trailerHistorical control:
458ec0bd6carries 0 trailers and would be refused — correctly. The point is not to permit it retroactively.Blast radius: 2 commits in 600. Every other PR is unaffected.
My own probe was the broken instrument first:
git reset --hardremoveddocs/now/, the entry file could not be written, and two cases failed on the presence check rather than on the guard. Fixed the harness, not the reading.R12 states the rule;
LOOP-RULES.sha256moves with it in the same commit.