Release Green

🌍 View in other languages

Release-Green: mantendo a fila e a release branch verdes

O problema que isto resolve

O gate completo (.github/workflows/ci.yml — unit shards, vitest, ratchets, package-artifact, SonarQube, E2E) roda apenas na release PR (PR → main). PRs para release/** recebem só as fast-gates (quality.yml: testes TIA-impactados + typecheck + lint). Consequência: reds se acumulam silenciosamente na release branch e explodem em camadas de ~40 min no momento do release, uma de cada vez.

A "família release-green" existe para antecipar esses reds — validar o equivalente ao gate completo localmente / fora do release, a qualquer momento, para que a release PR já nasça verde na primeira CI.

Princípio inegociável: nada disto bloqueia o contribuidor. Não adicionamos um required check que falhe o PR dele. O drift (ratchets) é do mantenedor rebaselinar no release — nunca uma preocupação do contribuidor. Nenhuma peça fecha um PR (roubo de crédito) nem enfraquece um teste para passar.

A família (4 peças) — e como cada uma roda à parte

Peça	O que é	Quando rodar	Escopo
/green-prs (Solução A)	Varredura sob demanda do mantenedor sobre a fila de PRs abertos	À parte, periódico — e principalmente antes de um /generate-release	Fila inteira de PRs → release/**
/validate-release-green (Solução C — npm run check:release-green)	Motor de validação: reproduz o gate completo contra uma branch OU um merge-candidato	À parte, a qualquer momento	Uma branch específica ou um PR-merge
/babysit <PR#>	Conduz a CI ao vivo de um PR até o verde	À parte, por PR	Um PR
nightly-release-green.yml (Solução D)	Workflow noturno automático; abre issue em HARD red	Automático (cron)	A release branch ativa

Resposta curta à pergunta "é só para release?": não. O /green-prs foi desenhado para rodar de tempos em tempos, entre releases. Rodar à parte é o uso normal — o release é apenas o momento em que rodá-lo dá mais retorno.

Solução C — npm run check:release-green (o motor)

Reproduz a validação release-equivalente contra a árvore de trabalho atual e classifica cada red:

• HARD (typecheck, lint errors, unit, vitest, db-rules, public-creds, opcional package-artifact) → defeito real; exit 1. Conserta-se na branch de origem (TDD, Rule #18).
• DRIFT (eslint warnings, cognitive-complexity, file-size) → drift de ratchet acumulado no ciclo, não é culpa do contribuidor; é só reportado e rebaselinado pelo mantenedor no release. Drift nunca muda o exit code — então nunca bloqueia ninguém.

npm run check:release-green                 # branch atual (working tree)
node scripts/quality/validate-release-green.mjs --json   # saída estruturada
node scripts/quality/validate-release-green.mjs --quick  # pula unit+vitest (só drift+typecheck+lint)
node scripts/quality/validate-release-green.mjs --with-build  # inclui package-artifact (lento)

Diagnostica e reporta apenas (sem auto-fix). A orquestração de fix-to-green vive no /green-prs e no /review-prs.

Solução A — /green-prs (a varredura da fila)

Procedimento (resumo — ver a skill green-prs para o detalhe):

1. Inventariar a fila de PRs abertos contra a release branch ativa.
2. Triar cada PR (viável / reject-worthy / needs-author) — reject/needs-author são reportados, não fechados (o dono decide).
3. Para cada viável, em worktree isolado (Rule #19), trazer o PR ao tip da release e rodar npm run check:release-green:
   • HARD → consertar na branch do contribuidor via coautoria (mantém o "Merged" do autor), re-rodar até zerar os HARD.
   • DRIFT → deixar; é rebaselinado no release.
4. Reportar uma tabela PR × (verdict, HARD reds, fixado?, DRIFT, release-green agora?).

Pode preparar a fila sem mergear; só mergeia quando explicitamente pedido — e nunca fecha PR.

Cadência recomendada

• Rode /green-prs periodicamente (ex.: semanalmente) e sempre antes de um /generate-release.
• Deixe o nightly-release-green.yml (Solução D) como sinal contínuo: quando ele abrir issue de HARD red, é hora de uma varredura.
• Use /validate-release-green ad-hoc para checar uma branch ou um merge-candidato pontual.
• Use /babysit <PR#> quando um PR específico precisa ser conduzido ao verde na CI ao vivo.

Relação com o release

• /generate-release chama a validação na Fase 0 (pré-flight): rebaselina o DRIFT e conserta o HARD antes de abrir a release PR.
• /review-prs usa o gate release-green no passo de decisão de merge (verde-antes-de-merge).

O objetivo de todas as peças é o mesmo: a release PR verde na primeira CI, em vez de surfar reds em camadas de 40 min no dia do release.