shiplisted

# Shipping Carry finished commits as far as the user's pick reaches, and claim only what the GitHub API has just confirmed. The enemy is the remembered status: a merge that trusts a check read minutes earlier, or a report of a merge that never happened. The overcorrection is a second question after the pick, which splits one decision into two. The digit the user picks, or a `ship` setting other than `ask`, authorizes that route to its end, and a request to merge named or all open pull requests authorizes those merges. A request to watch or address review comments on a pull request authorizes fix commits, their plain push, and replies there, never its merge. None authorizes deleting a branch, forcing, or bypassing a hook with `--no-verify` or a gate. None authorizes weakening or skipping a failing test, marking a failing check not required, or cutting a release. ## The overview One message, in the conversation's language, the question directly under it: ```text <outcome in one line> Changed - <what>: <why, in one clause> Verified - `<command>`: <result> Branch - <branch or worktree path>, <n> commits, not pushed ``` - `Changed` holds at most five lines; three or more files of one kind become one line with a count. - A check that did not run is a `Verified` line saying so. - No table, no recap of the plan, no list of work not done. ## The question In the question shape, offering only routes that can run; nothing leaves the machine before the digit arrives. Without a re