---
name: a-branch-in-a-pre-clear-brief-is-a-snapshot-verify-before-committing
description: the branch named in a commune/brief is where you WERE; check `git branch --show-current` before committing, and never let `cmd | tail` swallow a fatal in an && chain
metadata:
  type: feedback
---

2026-09-10: my pre-clear brief said "9 commits on docs/ir93-95-golden294 unpushed" and the session's
git snapshot named that branch, so I committed KNOWN-HAZARDS 7.66 without checking — **onto local
`main`**. Caught before any push (`origin/main` unmoved at `de5a44bc`, no CI fired, no thin lane
through a peer's timing window), moved to the lane with `cherry-pick` in that lane's own worktree,
and `git reset --keep origin/main` restored main while PRESERVING an unrelated uncommitted edit.

**A branch named in a brief is a snapshot of where you were when it was written.** The register lane
lived in `.worktrees/reg294`, so the main checkout was on `main` the whole time. `git branch
--show-current` costs nothing and the harness rule ("if on the default branch, branch first") exists
for exactly this. On a ff-only-main project a push would have run the full thin lane on BOTH runners
— see [[a-push-to-main-runs-the-full-thin-lane-on-both-runners]].

**THE SECOND FAILURE IS THE ONE THAT HID IT:** my recovery ran
`git checkout <branch> | tail -3 && git cherry-pick ... && git branch -f main ...`.
The checkout FAILED (`fatal: already used by worktree`) but the pipe's exit code is **tail's**, so
`&&` proceeded and the cherry-pick ran on main — leaving a CHERRY_PICK_HEAD to abort. Same shape as
the `$?`-after-a-pipe trap I banked that morning, committed hours later. **Never pipe a command whose
exit code gates an `&&` chain.** Run it bare, or capture status before piping.

`git reset --keep <ref>` is the verb for undoing a local commit while keeping unrelated working-tree
edits — `--hard` would have destroyed them.
Kin [[a-git-refusal-halts-the-script-and-a-tree-answers-git-status-before-it-dies]].