factory-shiplisted

# factory-ship The user's accompanying request is this workflow's argument string. Wherever these instructions refer to `$ARGUMENTS`, interpret it as that request. Ship the current release: merge everything on the integration branch to the deploy branch. My invoking this command **is** the human `master` decision — the one call the autonomous loop never makes on its own. That means you carry it through to a verified deploy or a clear stop; don't hand it back to me half-done. Interpret `$ARGUMENTS` as a repo name from `config/repos.yaml` (run from that repo's checkout); default is the repo you're standing in. ## 1. Resolve branches and preflight - Branches come from `config/repos.yaml` where the repo has an entry: `base` (integration, usually `develop`) and `deploy_branch` (usually `master`). No entry or no `deploy_branch`: use the repo's actual branches (`develop` → `master`/`main`); if base and deploy are the same branch, there is no release flow here — say so and stop. - `git fetch origin` first. Everything below reads `origin/<branch>`, never a possibly-stale local ref. - **Nothing to ship?** `git log origin/master..origin/develop --oneline` — empty means done, report and stop. - **Is develop itself healthy?** Latest CI run on the base branch must be green (`gh run list --branch develop --limit 1`) and, where the repo has a smoke check (`smoke_workflow`/`smoke_url` in `repos.yaml`), the dev smoke must be green too. Shipping a red develop just promotes the breakage; fi