chore: remove the TestBox stubs that #3360 re-added after #3363 removed them - #3364
Conversation
…ed them Third occurrence of the same slip, with a wrinkle worth recording. PR #3363 untracked seven generated TestBox stubs and added the .gitignore entries that stop them coming back. PR #3360 then merged on top and re-added all seven — its branch was cut from 2c98644, before the ignore existed, and it was committed with `git add -A` while the paths were still untrackable-but-not-ignored. Merging the cleanup first and the older branch second undid the cleanup. The .gitignore is on develop now, so a branch cut from this point cannot repeat it. This commit just finishes what #3363 started: seven removals, no other change. Verified after committing that exactly one stub remains tracked — F952D54F…, which predates all of this and is deliberately left alone. The lesson is about ORDER, not just about `git add -A`: after merging a cleanup PR, every already-open branch that predates it still carries the thing that was cleaned, and merging it silently reverts the fix. Check the remaining branches for it before merging them, not after. Signed-off-by: Peter Amiri <peter@alurium.com>
There was a problem hiding this comment.
Wheels Bot — Reviewer
TL;DR — This PR finishes the cleanup #3363 started: it removes seven generated TestBox mock stubs that #3360 silently re-added by being cut before the .gitignore entry existed. Pure deletion of generated artifacts, no code change. Verified clean — approve.
Correctness
The diff removes exactly the seven regenerable stub files under public/testbox/system/stubs/ and nothing else. I confirmed the tail claim against the tree at the head SHA:
$ git ls-tree public/testbox/system/stubs/ (@ f2d6a93)
F952D54F1096E25C030C8E3149ABD8C4.cfm
Exactly one stub remains tracked — F952D54F…, matching the PR body's "deliberately left alone" note. The .gitignore already carries the guard, so a fresh branch can't re-add these:
$ git show f2d6a93:.gitignore | grep testbox
public/testbox/system/stubs/
These are TestBox-generated MockBox temp stubs (hash-named, e.g. tmp_closeSSEStream_…), regenerated on every test run. A git grep for the deleted hashes and the surviving one turned up zero references anywhere in the tree, so nothing depends on them.
Commits
chore: remove the TestBox stubs that #3360 re-added after #3363 removed them — valid chore type, subject is not ALL-CAPS, header is under the 100-char limit, and the body explains the why (merge-order reverted the cleanup). DCO sign-off present. Conforms to commitlint.config.js.
Docs
No changelog fragment needed — this is a chore, not a user-facing fix/feat, so it's correctly omitted. No behavior change, so no .ai/ or guides update applies.
Nice work capturing the "order, not just git add -A" lesson in the commit body — that's the reusable takeaway for the next cut-before-cleanup branch.
Finishes what #3363 started. Seven file removals, no other change.
What happened
#3363 untracked seven generated TestBox stubs and added the
.gitignoreentries that stop them coming back. #3360 then merged on top and re-added all seven.Its branch was cut from
2c9864434— before the ignore existed — and committed withgit add -Awhile those paths were still untrackable-but-not-ignored. Merging the cleanup first and the older branch second silently reverted the cleanup.The
.gitignoreis on develop now, so a branch cut from this point can't repeat it.The lesson is about order
This is the third occurrence, and the first two had the same cause (
git add -Aafter a local test run) while this one did not — the habit was already fixed. What got me here is that after merging a cleanup PR, every already-open branch that predates it still carries the thing that was cleaned, and merging it reverts the fix without any conflict or warning.Check the remaining open branches for it before merging them, not after.
Verified
Exactly one stub remains tracked after this commit —
F952D54F…, which predates all of this and is deliberately left alone.🤖 Generated with Claude Code