chore: stop repairing the same checkout drift by hand every run - #237
Merged
Conversation
Three separate sessions have now opened this repo, found the working copy
silently wrong, and spent part of the run repairing it before any real work
could start:
2026-08-29 local main held a commit origin never got, so `git pull --ff-only`
failed for every run entering the repo.
2026-08-31 local main was 2 commits behind origin (#232, #233).
2026-09-02 local main was 3 commits behind (#234-#236), two squash-merged
worktrees were still checked out, and frontend/node_modules
predated the prettier devDependency from #233 — so the first gate
of `npm run verify` died on "prettier: not found".
A bare `git status` reports "clean" in all three cases, which is why each run
rediscovers it the hard way instead of inheriting the last one's fix. Per the
never-twice rule, the third instance gets the automation, not a fourth repair.
`npm run preflight` checks the three invisible ones — divergence from origin
(after an explicit fetch), merged worktree branches still checked out (compared
by patch id via `git cherry`, since `git branch --merged` cannot see a squash),
and node_modules older than its lockfile. Read-only by default, exit 1 on drift;
`npm run preflight -- --fix` repairs what it finds and refuses to touch a
worktree with uncommitted changes.
Both paths exercised on this branch: the read-only run caught backend/
node_modules as stale against the #229/#230 security bumps, and --fix
reinstalled it to clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PtVWdxno5WtK9zYLkrBz3P
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.
Why
Three separate sessions have opened this repo, found the working copy silently wrong, and spent part of the run repairing it before any real work could start:
mainheld a commit origin never got —git pull --ff-onlyfailed for every run entering the repomain2 commits behind origin (#232, #233)main3 commits behind (#234–#236), two squash-merged worktrees still checked out, andfrontend/node_modulespredating the prettier devDependency from #233 — so the first gate ofnpm run verifydied onprettier: not foundA bare
git statusreports "clean" in all three cases. That's why each run rediscovers it the hard way instead of inheriting the previous one's fix. Per the repo's never-twice rule, the third instance gets automation, not a fourth manual repair.What
npm run preflight— read-only, exits 1 on drift.npm run preflight -- --fixrepairs.It checks exactly the three things
git statuscannot see:git fetch. Reports ahead and behind; only fast-forwards when purely behind, and flags "ahead" loudly since that usually means a timed-out run left unpushed commits.git cherryrather thangit branch --merged, which cannot see a squash-merge. Under--fixit refuses to remove a worktree with uncommitted changes.node_modulesolder than itspackage-lock.json. The failure that reads most like a repo bug and never is.Verification
Both paths exercised on this branch:
backend/node_modulesas stale against the fix(security): bump basic-ftp to close 4 Dependabot alerts (1 critical) #229/chore(deps-dev): bump minimatch from 3.1.2 to 3.1.5 in /backend #230 security bumps — a real finding, not a synthetic one.--fixreinstalled it; re-run reports clean.npm run verifygreen locally: format:check ✓ · lint 0 errors / 161 warnings · tsc clean · 46/46 tests · build ✓.Docs live in
.claude/CLAUDE.mdnext to the existingverifyguidance, with the receipts inline so the next session knows why the check exists.🤖 Generated with Claude Code
https://claude.ai/code/session_01PtVWdxno5WtK9zYLkrBz3P