Agent brief: release only a lock you took

The landing snippet I wrote ran `capture && scan && push ; release`. release
is not owner-checked, so when capture failed because another agent held the
lock, the ';' still ran release and freed THEIR lock mid-landing. That
happened today. Wrap the landing in `if main-capture capture; then ... fi`:
release still runs after a failed scan or push, but never after a failed
capture. Also warn against piping capture, which makes the test grade the
pipe's filter instead of the capture.

AGENT-BRIEF.md

@@ -29,12 +29,18 @@ unset SSH_ASKPASS DISPLAY
 
 git fetch origin && git rebase origin/main        # you resolve every conflict, not main
 
-main-capture capture   &&  \
-main-capture scan      &&  \
-git push origin HEAD:main ; \
-main-capture release                              # the ';' is load-bearing: ALWAYS release
+if main-capture capture; then                     # release ONLY a lock you actually took
+  main-capture scan && git push origin HEAD:main
+  main-capture release                            # ...but ALWAYS release one you took
+fi
 ```
 
+**Release is not owner-checked: it deletes whoever's lock is there.** So the two rules pull in
+opposite directions and the `if` satisfies both. The older one-liner `capture && scan && push ;
+release` runs release even when capture FAILED because someone else held the lock — and freed
+THEIR lock mid-landing (measured 2026-09-24). Never pipe `capture` into `tail`/`grep` either: the
+`if` would then test the filter's exit code, not the capture's.
+
 Grade the push by its EXIT CODE (`${PIPESTATUS[0]}` if you pipe it), never by grepping its output:
 the word `main` also appears in the rejection line, and a grep once reported 8 rejected pushes as
 landed. After pushing, `git fetch origin` and confirm your commit is on `origin/main`.