releasing-versionslisted

# Release Esta skill tem **dois regimes**, e o regime e **detectado, nunca assumido**: - **Regime release-please** — o projeto tem release-please configurado. A action e a dona do CHANGELOG, da versao e da tag. Voce so escreve commits convencionais. - **Regime manual (fallback)** — o projeto NAO tem release-please. Vale o fluxo de PR de release descrito no fim deste arquivo. A rule que governa isso e `~/.claude/rules/releases.md`, secao "Release-please (fonte primaria quando configurado)". Em caso de divergencia, a rule ganha. ## 0. Detectar o regime (SEMPRE o primeiro passo) ```bash ROOT=$(git rev-parse --show-toplevel) || exit 1 RP="" [ -f "$ROOT/release-please-config.json" ] && RP="config" [ -z "$RP" ] && [ -f "$ROOT/.release-please-manifest.json" ] && RP="manifest" [ -z "$RP" ] && grep -rq "release-please-action" "$ROOT/.github/workflows/" 2>/dev/null && RP="workflow" echo "${RP:-manual}" ``` - Saida `config` / `manifest` / `workflow` → **REGIME RELEASE-PLEASE** → seguir as secoes 1 a 4. O fallback manual **nao se aplica**; nem leia. - Saida `manual` → **REGIME MANUAL** → pular direto pro fallback no fim do arquivo. Duas coisas nao negociaveis nesse passo: - **Checar as TRES formas.** Da pra configurar release-please so por input de workflow, sem arquivo de config na raiz. Uma deteccao presa ao arquivo de raiz le esse projeto como "manual", escreve no `CHANGELOG.md` o que a action vai reescrever, e isso e conflito garantido (`rules/releases.md`). - **Ancorar na ra