fix(ship-skill,babysit): clean rebase can still hide drift, fixed tem…

…p-branch name blocks recovery - A clean git rebase can replay stray commits with zero conflicts, so 'rebase succeeded' was being treated as sufficient — now the log is always re-checked after rebasing, clean or not, before trusting it - The recovery text told the agent to 'pick another name' if ship-sync-tmp was taken but then hardcoded that literal name anyway; now it just deletes the leftover (disposable, single-purpose) branch instead of introducing a naming scheme - babysit's step 5 pointed at re-running the log check alone; it now points at the full /ship step 2 recovery flow, since a review loop spanning a long session is exactly where drift compounds silently
simstudioai · waleedlatif1 · Jul 9, 2026 · Jul 9, 2026 · Jul 9, 2026 · Jul 9, 2026
commit 422f81af02bd7eb4659d1007f08c2ed345f9d28b
diff --git a/.agents/skills/babysit/SKILL.md b/.agents/skills/babysit/SKILL.md
@@ -72,11 +72,13 @@ round. Always check both conditions freshly after every push.
    gh api graphql -f query='mutation { resolveReviewThread(input: {threadId: "<threadId>"}) { thread { isResolved } } }'
    ```
 
-5. **Before pushing, re-run the sync check** from `/ship` step 2
-   (`git fetch origin staging && git log --oneline origin/staging..HEAD` should list only this
-   session's commits) — a babysit loop that runs over a long session is exactly the scenario
-   where a branch can drift. Then run the repo's lint/typecheck/boundary-validation gates the
-   same way `/ship` does before committing.
+5. **Before pushing, re-run the full sync check from `/ship` step 2** — not just the log command,
+   the whole check-and-recover flow (stash WIP if needed, rebase, verify the rebase didn't just
+   cleanly replay stray commits, cherry-pick rebuild if it did or if it conflicted). A babysit
+   loop spanning a long session is exactly the scenario where a branch can drift, and pushing
+   review fixes on top of undetected drift is how an oversized PR happens even after the branch
+   was fixed once. Then run the repo's lint/typecheck/boundary-validation gates the same way
+   `/ship` does before committing.
 
 6. **Commit and push** the round's fixes as one commit (`--force-with-lease` only if step 5's
    sync check required a rebuild).

diff --git a/.agents/skills/ship/SKILL.md b/.agents/skills/ship/SKILL.md
@@ -16,8 +16,9 @@ When the user runs `/ship`:
    - If it shows commits you don't recognize, fix it now, **before** staging/committing any new work (step 7 hasn't run yet):
      - If the working tree has uncommitted changes, stash them first — `git stash push -u -m ship-sync-fix` — so the rebase below isn't blocked by dirty state. Restore with `git stash pop` once the branch is fixed.
      - Try `git rebase origin/staging` first.
-     - If that walks through unrelated history and conflicts on commits you don't recognize, `git rebase --abort` and rebuild instead: pick a temp branch name that isn't already in use (`git branch --list ship-sync-tmp`; if it exists, delete it or pick another name), `git checkout -b ship-sync-tmp origin/staging`, `git cherry-pick <your-sha(s)>`, resolve conflicts, then `git branch -f <original-branch> HEAD`, `git checkout <original-branch>`, and delete the temp branch.
-   - Re-verify with `git log --oneline origin/staging..HEAD` — it should list only commits you recognize.
+     - **A rebase finishing without conflicts does NOT by itself mean the branch is clean** — it can replay stray commits onto the new base with no conflict at all. After the rebase (clean or not), re-run `git log --oneline origin/staging..HEAD` and re-check the commit list against what you recognize.
+     - If the rebase conflicted on commits you don't recognize, OR it finished cleanly but the re-checked log still shows commits you don't recognize, abandon that result (`git rebase --abort` if still mid-rebase) and rebuild instead: delete any leftover `ship-sync-tmp` branch from an earlier attempt (`git branch -D ship-sync-tmp` — safe, it's disposable), `git checkout -b ship-sync-tmp origin/staging`, `git cherry-pick <only the sha(s) you actually authored this session>`, resolve conflicts, then `git branch -f <original-branch> HEAD`, `git checkout <original-branch>`, and delete `ship-sync-tmp`.
+   - Re-verify with `git log --oneline origin/staging..HEAD` — it must list only commits you recognize before you proceed to committing new work.
 3. **Generate a commit message** following this format: `type(scope): description`
   - Types: `fix`, `feat`, `improvement`, `chore`
   - Scope: short identifier (e.g., `undo-redo`, `api`, `ui`)

diff --git a/.cursor/commands/babysit.md b/.cursor/commands/babysit.md
@@ -66,11 +66,13 @@ round. Always check both conditions freshly after every push.
    gh api graphql -f query='mutation { resolveReviewThread(input: {threadId: "<threadId>"}) { thread { isResolved } } }'
    ```
 
-5. **Before pushing, re-run the sync check** from `/ship` step 2
-   (`git fetch origin staging && git log --oneline origin/staging..HEAD` should list only this
-   session's commits) — a babysit loop that runs over a long session is exactly the scenario
-   where a branch can drift. Then run the repo's lint/typecheck/boundary-validation gates the
-   same way `/ship` does before committing.
+5. **Before pushing, re-run the full sync check from `/ship` step 2** — not just the log command,
+   the whole check-and-recover flow (stash WIP if needed, rebase, verify the rebase didn't just
+   cleanly replay stray commits, cherry-pick rebuild if it did or if it conflicted). A babysit
+   loop spanning a long session is exactly the scenario where a branch can drift, and pushing
+   review fixes on top of undetected drift is how an oversized PR happens even after the branch
+   was fixed once. Then run the repo's lint/typecheck/boundary-validation gates the same way
+   `/ship` does before committing.
 
 6. **Commit and push** the round's fixes as one commit (`--force-with-lease` only if step 5's
    sync check required a rebuild).

diff --git a/.cursor/commands/ship.md b/.cursor/commands/ship.md
@@ -11,8 +11,9 @@ When the user runs `/ship`:
    - If it shows commits you don't recognize, fix it now, **before** staging/committing any new work (step 5 hasn't run yet):
      - If the working tree has uncommitted changes, stash them first — `git stash push -u -m ship-sync-fix` — so the rebase below isn't blocked by dirty state. Restore with `git stash pop` once the branch is fixed.
      - Try `git rebase origin/staging` first.
-     - If that walks through unrelated history and conflicts on commits you don't recognize, `git rebase --abort` and rebuild instead: pick a temp branch name that isn't already in use (`git branch --list ship-sync-tmp`; if it exists, delete it or pick another name), `git checkout -b ship-sync-tmp origin/staging`, `git cherry-pick <your-sha(s)>`, resolve conflicts, then `git branch -f <original-branch> HEAD`, `git checkout <original-branch>`, and delete the temp branch.
-   - Re-verify with `git log --oneline origin/staging..HEAD` — it should list only commits you recognize.
+     - **A rebase finishing without conflicts does NOT by itself mean the branch is clean** — it can replay stray commits onto the new base with no conflict at all. After the rebase (clean or not), re-run `git log --oneline origin/staging..HEAD` and re-check the commit list against what you recognize.
+     - If the rebase conflicted on commits you don't recognize, OR it finished cleanly but the re-checked log still shows commits you don't recognize, abandon that result (`git rebase --abort` if still mid-rebase) and rebuild instead: delete any leftover `ship-sync-tmp` branch from an earlier attempt (`git branch -D ship-sync-tmp` — safe, it's disposable), `git checkout -b ship-sync-tmp origin/staging`, `git cherry-pick <only the sha(s) you actually authored this session>`, resolve conflicts, then `git branch -f <original-branch> HEAD`, `git checkout <original-branch>`, and delete `ship-sync-tmp`.
+   - Re-verify with `git log --oneline origin/staging..HEAD` — it must list only commits you recognize before you proceed to committing new work.
 3. **Generate a commit message** following this format: `type(scope): description`
    - Types: `fix`, `feat`, `improvement`, `chore`
    - Scope: short identifier (e.g., `undo-redo`, `api`, `ui`)