Say when /implement may push, and never leave a branch parked on a deliberately broken commit

[jacobdrees]

What to build

A rule for when /implement may push, and a prohibition on leaving a branch parked on a commit that was deliberately broken to prove something.

The gap

CLAUDE.md says /implement "stops at the commit", and pushing belongs to /draft-pr. But an acceptance criterion can require evidence that only GitHub can produce. CAN-54 Fail a push that adds a known-vulnerable dependency asked that a vulnerable dependency "fails the job", and the job is GitHub's. There is no way to satisfy that from a laptop, and docs/agents/workflow.md → The gates says as much in its own words: the gate is GitHub's copy of those checks, not yours.

So the push happened twice mid-implement, with nothing covering it.

The sharper half

Proving a gate works means pushing a commit that is deliberately broken. On CAN-54 that was a package carrying a critical advisory. The remote branch then sat at that commit for as long as the rest of the work took, and would have stayed there indefinitely if the session had ended, because /implement is documented as stopping before the push that would move it on.

That is the part worth a rule: not that the push happened, but that the branch was left parked on it.

Acceptance criteria

• docs/agents/workflow.md says when /implement may push before /draft-pr, with the evidence-only case named rather than left to inference.
• It requires that a deliberately-broken commit is never the head of a pushed branch at the end of a session, and says what to do instead.
• The run id and commit of such a verification are recorded, since the whole point of the push is the evidence it produces.
• CLAUDE.md's one-line description of /implement is either corrected or explicitly deferred to the fuller rule, so the two do not disagree.

Not in scope

Changing who opens the pull request, or moving any part of /draft-pr into /implement.