commit and push when it goes wrong too

The instruction was standing and nowhere in the repo, so every session started
by waiting to be asked. Written down because the reason is not obvious: a
branch held back because it is unfinished, untested or a dead end is exactly
the branch whose history is worth having. A reverted commit and its message
explain why an approach was abandoned; a quietly discarded attempt teaches the
next person nothing, and they will try it again.

The obligation that comes with it is saying what state the work is in — in the
message, and in COMMS/ when another agent will pick it up — rather than letting
a clean commit imply it is finished.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -281,6 +281,13 @@ type parameter and let inference flow from it.
 - **Stay focused** — note unrelated problems, don't fix them uninvited
 - **Report honestly** — say what you verified and what you didn't
 
+**Always commit and push when you finish implementing — including when it went wrong.** Don't wait to be
+asked, and don't hold a branch back because it is unfinished, untested or turned out to be a dead end. The
+history of the mistakes is worth having: a reverted commit and its message explain why an approach was
+abandoned, which is exactly the thing that gets lost when a failed attempt is quietly discarded. Say what
+state it is in — in the commit message and in `COMMS/` if another agent will pick it up — rather than
+withholding the commit until it is good.
+
 Commit messages: simple lowercase, no prefixes.
 
 ## Frontend route conventions (apply to EVERY new dashboard route)