release-promotionlisted

# Release promotion One job: move the integration branch onto the release branch **only when it is genuinely releasable**, tag that release, and - separately - run a hotfix so the fix reaches production and never gets lost on the next promote. Promotion is the one irreversible step in the branching model: once `main` moves and a tag is pushed, users are getting that code. So this skill fails closed. Every check has to come back green from git and CI directly; a check whose answer is *unknown* is not a passing check, and any doubt stops the promote rather than shipping through it. ## Before anything: read the overrides The branch names below are the model's defaults, not a mandate. A project may integrate on `develop`, release from `master`, or prefix hotfixes `hf/`. Read what the repo actually does and let it win: ```bash .better-dev/bin/bd-mem read overrides 2>/dev/null .better-dev/bin/bd-mem recall "release integration branch tag hotfix" 2>/dev/null ``` ```bash integration="staging" # honor an override (e.g. develop) release="main" # honor an override (e.g. master) ``` A repo can run trunk-based - integration and release are the same branch (a recorded `branch-model: trunk`; with nothing recorded, the staged two-branch shape below is the default). The promote then degenerates on purpose: the ancestor gate and the fast-forward are no-ops on a single branch, and the soak window collapses to the merge itself, because `/pr-and-verify`'s merge into the trunk *i