release

<user_request>$ARGUMENTS</user_request>

<golden_rules> These four rules override convenience at every phase. They are the distilled failure history of release-please, changesets, semantic-release, cargo-release and npm itself.

1. REVERSIBLE FIRST, IRREVERSIBLE LAST. No tag leaves the machine and no publish starts until every gate has passed on the exact SHA being released.
2. THE TESTED CANDIDATE IS THE RELEASED CANDIDATE. Changing versions, changelogs, generated files, or lockfiles after tests ran means the tested candidate is no longer the candidate being released. Any post-test mutation returns the flow to PREPARE.
3. ONE HUMAN DECISION, MADE UP FRONT. Authorization is settled BEFORE the pipeline starts (see ), never mid-run. If the user said "release yourself", run to completion without stopping; if they did not, ask once, right away, before doing anything. A release that blocks in the middle waiting for a click is the failure mode this rule exists to prevent. The PR stays as the durable, reviewable record — it is not a second approval step.
4. EVERY SIDE EFFECT IS A PREDICATE + ACTION. Before acting, check whether the effect already exists: absent → do it; present and matching → skip and say so; present but DIFFERENT → hard stop, this is a consistency incident, never a retry. </golden_rules>

<worktree_context> Releases are EXPECTED to run from a git worktree, not the main checkout. Detect it (git rev-parse --git-dir vs --git-common-dir differ) and treat it as normal, but know what a worktree changes:

• Tags, branches, and remotes are SHARED with the main checkout and every sibling worktree. A tag created here is instantly visible everywhere; the explicit-ref push rule matters double because sibling worktrees accumulate each other's local tags.
• The stash stack is shared too. Never bare git stash / git stash pop during a release — another session may push or pop concurrently. A temporary WIP commit is the safe way to set something aside.
• Sibling worktrees may hold in-flight work on the same files. Release from the last COMMITTED state of this branch; never chase or wait on another session's uncommitted edits.
• THE WORKTREE IS DISPOSABLE. After the release merges, the worktree is routinely reaped — and everything gitignored inside it (session folders, scratch, caches, local state) is deleted without ceremony. That is the designed lifecycle, which is exactly why the knowledge-promotion step in PREPARE and the residue report in REPORT exist: anything worth keeping must leave the worktree as a committed file BEFORE the merge, or it never will. </worktree_context>

• The user's request already says it ("release yourself", "merge and release without asking", "--auto", or equivalent) → AUTONOMOUS MODE for this whole run. Do not ask again at any point. Report every irreversible step as it happens.
• It does not → ask ONE question now, before starting: "Run this release end to end myself (merge + tag + publish without stopping), or stop before the irreversible steps for your go-ahead?" Their answer sets the mode for the run. Then start.
• Never introduce a new approval question in the middle of the pipeline. The only legitimate mid-run stops are NOT approvals: a preflight gate that failed, or a consistency incident (golden rule 4: something exists but differs). Those stop the run because proceeding would be wrong, not because permission is missing.
• Authorization covers this run only. It does not carry over to the next invocation.