v1.21.0: step 25c — verify your own work still exists on main - #17
Merged
Conversation
Steps 25a/25b check that the RECORD is complete. Neither checks that the work
is still there, and that is a different question with a different answer.
2026-08-07: a PR whose parent WAS current main — so every "am I behind?" check
passed and `git merge origin/main` would have said "Already up to date" —
deleted 59 files and 5,081 lines already merged, belonging to four sessions.
No conflict, PR green, the project's own validator passed, the tracker still
rendered. One session completed every part of its wrap-up and reported "all
parts updated" while four of its files and six of its ledger entries had
already been deleted, and did not find out for three and a half hours.
No gate catches it because a deletion is a valid state of a file: a validator
reads what is there and cannot know what should be. So it has to be an explicit
step, and it has to run LAST — after the final merge of the session, because
anything merging after you re-checks nothing.
Three passes, each catching what the previous cannot:
1. files exist (git cat-file -e origin/main:<path>)
2. content survived (a file can exist and be rolled back)
3. ledger TEXT, not just ids (a task can survive by id while its detail is
reverted to pre-session wording byte for byte
— no id check and no validator sees this)
Pass 3 is the one people skip and where the silent damage lives.
Plus splice-never-revert recovery — the offending PR's own content is usually
legitimate and reverting it destroys everything merged since, the same failure
aimed the other way — and the broadcast step, because losses are per-session
and the ones belonging to a session that has already wrapped are found by
nobody.
Summary-table row added and marked non-blankable, beside 25a and 25b.
Detection at the other end (git diff --diff-filter=D before merging) lives in
agent-traffic-control's pr-from-stale-branch-silently-reverts-newer-main-files.
npm test: 77 pass, 0 fail. The suite caught the changelog entry silently not
being added — my anchor had the wrong capitalisation, so the replace was a
no-op and the README kept 1.20.0 as newest.
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.
Steps 25a/25b check that the record is complete. Neither checks that the work is still there — a different question with a different answer.
Why
2026-08-07: a PR whose parent was current
main— so every "am I behind?" check passed andgit merge origin/mainwould have said "Already up to date" — deleted 59 files and 5,081 lines already merged, belonging to four sessions. No conflict, PR green, the project's own validator passed, the tracker still rendered.One session completed every part of its wrap-up and reported "all parts updated" while four of its files and six of its ledger entries had already been deleted. It did not find out for 3½ hours, and then only by accident.
No gate catches this, because a deletion is a valid state of a file: a validator reads what is there and cannot know what should be. So it has to be an explicit step — and it has to run last, after the final merge of the session, because anything merging after you re-checks nothing.
The three passes
Each catches what the previous cannot:
git cat-file -e origin/main:<path>origin/mainfor a distinctive marker of your changeidwhile itsdetailis reverted to pre-session wording byte for byte. No id-presence check and no validator sees this.Pass 3 is the one people skip, and it is where the silent damage lives.
Plus splice, never revert (the offending PR's own content is usually legitimate; reverting destroys everything merged since — the same failure aimed the other way), and the broadcast step, because losses are per-session and a wrapped session's are found by nobody.
Summary-table row added and marked non-blankable, beside 25a and 25b. Detection at the other end —
git diff --diff-filter=Dbefore merging — lives inagent-traffic-control'spr-from-stale-branch-silently-reverts-newer-main-files(v1.13.0).Gates
npm test— 77 pass, 0 fail. The suite earned its keep: it caught my changelog entry silently not being added (wrong capitalisation in the anchor, so the replace was a no-op and the README still had 1.20.0 as newest). Cache and source verified identical before editing, per step 24e.🤖 Generated with Claude Code
https://claude.ai/code/session_01Kj3iwhCeL8ugNZyUiNfCQf