Finalizar Sessao — fechar o ciclo depois que funciona

Depende de: superpowers — o Passo 6 delega o fechamento da branch a superpowers:finishing-a-development-branch. As demais etapas funcionam sem ele.

PRIMEIRO PASSO (obrigatorio)

Ao carregar esta skill, SEMPRE exibir este header antes de qualquer outra acao:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🏁 FINALIZAR SESSAO — Skill carregada
Frente: <nome recebido, ou "sessao atual">
Conferindo as quatro paradas...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

O problema que esta skill existe para resolver

/freeze cobre antes de mexer. /change cobre na hora de mexer. Nada cobria depois que funciona — e e exatamente ai que os problemas moram, porque nenhum deles tem sintoma:

Caso real: feat/minha-frente acumulou 182 commits (um pull request, 21/08/2026) e depois 175 (04/09/2026), com o site sempre no ar e ninguem percebendo.

Quando usar

• Ao terminar uma frente de trabalho (nao a cada mudanca — isso seria cerimonia)
• Quando o operador disser "finaliza", "registra", "salva", "acabou"
• Antes de encerrar uma sessao com trabalho significativo
• Sugerida automaticamente ao fim de /change quando houve deploy

Workflow de Execucao

Passo 1: Fotografar o estado (so leitura)

git branch --show-current
git status --short
git status -sb | head -1        # divergencia com o GitHub
git log --oneline -10
# como descobrir o que esta no ar depende do projeto: docker service inspect, vercel ls,
# git log da branch de producao... Se o projeto nao publica nada, pular esta linha.

Montar e MOSTRAR ao operador a tabela das quatro paradas:

PARADA          ESTADO
arquivos        3 alterados (2 de outra sessao)
commit          8de28bcb, ha 12 min
GitHub          175 commits atras  ← ATENCAO
no ar           20260904-161518-064da5dd (= commit atual)

Passo 2: Commitar o que sobrou

• git add por nome, nunca -A nem .
• NAO commitar arquivo que outra sessao deixou modificado — listar quais sao e deixar quietos
• Mensagem no padrao do projeto, com os trailers de atribuicao

Passo 3: Enviar ao GitHub (o passo que ninguem lembra)

Antes de enviar, conferir as quatro perguntas e REPORTAR as respostas:

Com as quatro respostas boas: git push. Se alguma falhar, parar e reportar — nunca --force.

Passo 4: Freeze specs

• Listar os arquivos .ts/.tsx/.js tocados nesta frente
• Para cada um, verificar se existe freeze spec e se ela descreve o codigo NOVO
• Se estiver desatualizada, rodar /freeze <modulo> — a spec descreve o que esta no ar, entao so atualizar depois do deploy confirmado
• Aplicar o Passo 4b do /freeze: conferir se alguma regra contradiz o CLAUDE.md

Passo 5: Registrar a sessao

O objetivo e um so: a proxima sessao nao comecar do zero. Onde registrar depende do projeto — procurar nesta ordem e usar o PRIMEIRO que existir:

1. O CLAUDE.md do projeto manda registrar em algum lugar? (Notion, Linear, Jira, uma planilha) Entao seguir exatamente o que ele pede, com todos os campos que ele lista. Muitos projetos tem essa regra escrita e ela vive sendo esquecida — carregar isso e metade do valor desta skill.
2. Existe pasta de sessoes no repo? (docs/sessoes/, docs/superpowers/plans/) Escrever ali.
3. Nada disso? Criar docs/sessoes/AAAA-MM-DD-<slug>.md. E um arquivo de texto no proprio repositorio: funciona em qualquer projeto, sem depender de ferramenta nenhuma, e vai junto no push do Passo 3.

O registro precisa responder cinco coisas, em qualquer formato:

• O que foi feito (bullets curtos)
• Decisoes tomadas e por que — e o que mais se perde quando ninguem escreve
• Onde ficou — commits, tag no ar, arquivos tocados
• O que sobrou — com o proximo passo escrito de forma que outra pessoa pegue sem contexto
• Armadilhas encontradas — o erro que voce quase cometeu vale mais que o codigo que funcionou

Backlog: o que sobrou vai para onde o projeto guarda tarefas — issue do GitHub (gh issue create), a ferramenta que o CLAUDE.md indicar, ou uma secao "Pendencias" no proprio arquivo de registro. Escolher UM lugar. Backlog em dois lugares vira backlog nenhum: um envelhece e ninguem sabe qual vale.

Passo 6: A frente acabou? Entao delegar ao superpowers

NAO reimplementar merge/PR aqui. O superpowers ja tem superpowers:finishing-a-development-branch, que verifica os testes, descobre a branch base e apresenta as opcoes de merge, PR ou limpeza. Esta skill cobre o que falta ANTES disso (enviar ao GitHub, contratos, registro) — a integracao da branch e daquela.

Perguntar ao operador, com o numero real na frente:

A frente <nome> esta no ar e estavel ha <N> dias, com <N> commits acumulados nesta branch. Quer fechar a branch agora? Vou usar a skill finishing-a-development-branch do superpowers.

• Se sim: invocar superpowers:finishing-a-development-branch e deixar ela conduzir.
• Se nao: registrar no relatorio final que a branch continua aberta, com o numero de commits. Numero grande e informacao, nao repreensao — o operador decide quando fechar.

Nunca fundir sozinho, nem por esta skill nem pela delegada. Quem aperta o botao e o operador.

Passo 7: Relatorio final

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🏁 SESSAO FINALIZADA
commit     <sha> · <N> commits nesta frente
GitHub     enviado (branch e remoto no mesmo ponto)
no ar      <tag, ou "projeto sem deploy">
freeze     <specs atualizadas, ou "nada a atualizar">
registro   <onde foi parar>
branch     <fechada via superpowers | aberta com N commits>
pendente   <o que sobrou, ou "nada">
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Regras (NAO QUEBRAR)

1. Nunca git add -A nem git add . — varias sessoes trabalham na mesma pasta; o "tudo" leva junto o trabalho pela metade das outras.
2. Nunca git push --force. Se o envio for recusado, parar e reportar. Force apaga trabalho de outra pessoa.
3. Nunca fundir na main sozinho. A integracao da branch e delegada a superpowers:finishing-a-development-branch; o merge e sempre do operador.
4. Freeze spec descreve o que esta no ar, nunca o que esta no disco. Atualizar so depois do deploy confirmado.
5. Push publica. Conferir repositorio privado e ausencia de credencial ANTES, sempre.
6. Se nao houver nada para commitar nem enviar, dizer isso em uma linha e seguir para o registro — a skill nao inventa trabalho para justificar a propria existencia.