thebpandey/session-cleanup

Limpeza de sessão

Audite primeiro, delete depois, e somente após inspecionar o alvo. O objetivo é que o proprietário possa sair da sessão sabendo que nada está em execução, nada foi perdido e nada obsoleto foi deixado para trás. Uma sobra perdida é barata; um commit não enviado deletado não é. Em caso de dúvida, um achado vai para PERGUNTAR, nunca para LIMPEZA AUTOMÁTICA.

Funciona em qualquer repositório git. As partes do harness de lanes, beads e Vercel são ativadas apenas quando estão presentes; pule-as silenciosamente caso contrário.

Fase 1: Auditoria (somente leitura)

Execute a auditoria incluída a partir do repositório (qualquer worktree dele). Use o script para seu sistema operacional; a pasta da skill pode estar em ~/.claude/skills/, ~/.codex/skills/ ou ~/.agents/skills/:

# Linux e macOS
bash <diretorio-da-skill>/scripts/audit.sh                 # adicione --no-fetch para ficar offline

# Windows (PowerShell 5.1 ou 7)
powershell -NoProfile -ExecutionPolicy Bypass -File <diretorio-da-skill>\scripts\audit.ps1   # adicione -NoFetch para ficar offline

Ambos imprimem uma seção por área (CONTEXTO, ARVORE_DE_TRABALHO, SINCRONIZACAO, WORKTREES, RAMOS, STASHES, LANES, PROCESSOS, ARTEFATOS, TRACKER, DEPLOY, LOG_DA_SESSAO). Sua única gravação é um simples git fetch (nunca --prune). Nunca lê arquivos .env ou imprime ambientes de processo.

Como decide "esta sessão" (isso importa para toda classificação):

• Processos: dono=esta_sessao significa que esta sessão (ou algo que ela iniciou) iniciou o processo. No Linux, isso é comprovado pelo CLAUDE_CODE_SESSION_ID herdado, que sobrevive a nohup. No macOS e Windows, os ambientes de outros processos são ocultados, então significa "descendente do processo Claude" (CLAUDE_PID); um processo que foi destacado e reparentado aparece como iniciado_durante_sessao, que é PERGUNTAR, a menos que você possa rastreá-lo nesta conversa. dono=harness_nao_matar são os próprios servidores MCP e plugins do Claude Code: nunca toque neles. outra_sessao_ou_usuario é de outra pessoa.
• Arquivos, branches, stashes: esta_sessao / pre_sessao compara o timestamp com inicio_da_sessao (primeiro timestamp na transcrição desta sessão). Timestamps são uma dica, não uma prova: algo criado durante a janela da sessão pode vir de uma sessão paralela. Trate um item como desta sessão apenas quando o timestamp disser isso e você puder rastreá-lo nesta conversa (você executou o comando que o criou). Caso contrário, é PERGUNTAR.

Fora do Claude Code (por exemplo, no Codex) não há CLAUDE_CODE_SESSION_ID ou CLAUDE_PID, então id_da_sessao é desconhecido, tudo é marcado como pre_sessao, e os processos são correspondidos apenas por no_repo. Passe --since <horário ISO> (-Since no Windows) com o início da sessão se você souber, e caso contrário, trate arquivos e processos como PERGUNTAR, a menos que possa rastreá-los até um comando nesta conversa.

Em seguida, preencha as lacunas que o script não pode ver, em paralelo quando possível:

1. Seu próprio trabalho em segundo plano. Liste tarefas Bash em segundo plano, Monitores, subagentes e despertares programados que você iniciou nesta conversa e que ainda estão em execução. Pare os que terminarem ou estiverem ociosos com a ferramenta que os iniciou (TaskStop, parada do Monitor, etc.).
2. Sobras de solicitações. Varra a conversa em busca de qualquer coisa que o proprietário pediu para deletar depois ou manter apenas temporariamente (uma pasta de uploads, uma flag de depuração, uma conta de teste, um arquivo temporário). Verifique se ainda existe.
3. Estado do deploy (apenas se DEPLOY mostrar uma plataforma). Obtenha o SHA do commit da implantação de produção mais recente e compare com main_tip. Para Vercel: vercel ls --prod para encontrar a implantação de produção mais recente, depois vercel inspect <url> (ou o MCP / painel da Vercel) para seu commit git. Se você não conseguir obter o SHA, reporte "deploy: não verificado" com o motivo. Nunca infira uma correspondência a partir de timestamps.
4. Qualquer coisa fora do repositório que a sessão tocou (worktree de outro repositório, uma instalação global). Reporte; não modifique.

Fase 2: Classifique cada achado

LIMPEZA AUTOMÁTICA (seguro e recuperável; faça e depois reporte):

• Branches locais totalmente mescladas em main (git branch -d, nunca -D), excluindo main, a branch atual e qualquer branch com checkout em uma worktree.
• Registros de worktree removíveis cuja pasta já foi deletada (git worktree prune).
• Worktrees vinculadas limpas dentro deste repositório cuja branch está mesclada em main e não tem commits à frente dela (git worktree remove <caminho>, sem --force; depois git branch -d). Se o harness de lanes for o proprietário, use o script do harness (veja abaixo).
• Pastas temporárias cuja lane ou branch não existe mais e que nenhum processo tem aberto (handles_abertos=0; verifique novamente com lsof +D <dir> imediatamente antes de deletar).
• Processos com dono=esta_sessao que você pode rastrear até esta conversa e que estão ociosos ou não são mais necessários (servidores de desenvolvimento, watchers, navegadores headless). Mate apenas por PID (kill <pid> no Linux/macOS, Stop-Process -Id <pid> no Windows).
• Caches de build obsoletos (.next/types, .next/dev/types) que estão no gitignore. Eles regeneram no próximo build.
• Arquivos temporários desta sessão em sua pasta scratchpad e lixo não rastreado no repositório (*.orig, *.rej, logs perdidos) que são esta_sessao e rastreáveis até um comando que você executou.

PERGUNTAR (pode perder trabalho, ou não é comprovadamente desta sessão):

• Branches não mescladas, ou quaisquer commits que não estão em main. Uma branch marcada como PATCHES_JA_EM_main provavelmente foi mesclada com squash ou rebase: diga isso, mas ainda pergunte antes de -D.
• Worktrees sujas (arquivos_sujos > 0), stashes, coverage/ e test-results/ que podem ser desejados como evidência.
• Processos outra_sessao_ou_usuario ou iniciado_durante_sessao, e qualquer processo que você não possa rastrear.
• Qualquer coisa pre_sessao, e qualquer arquivo não rastreado que você não criou.

APENAS RELATÓRIO (o proprietário age, ou é informativo):

• Desvio entre main e origin (não enviado ou atrás). Recomende o push ou pull; não faça isso como parte da limpeza.
• Incompatibilidades de deploy ou estado de deploy "não verificado".
• Itens abertos do tracker (beads em_andamento, tasks.md WIP) sem trabalho ativo, e trabalho concluído cuja tarefa ainda está aberta. Nomeie o item e o que você viu.
• Worktrees ou pastas fora deste repositório, e branches upstream_gone que ainda têm commits únicos.

Regras de segurança

Estas protegem o trabalho que não pode ser recriado. Cada uma existe porque o atalho óbvio já destruiu trabalho antes.

• Inspecione antes de deletar. Para cada pasta, liste seu conteúdo e tamanho primeiro. Para cada branch, mostre git log --oneline main..<branch> primeiro. Coloque essa evidência no relatório.
• Nunca delete commits não mesclados, worktrees sujas ou stashes sem a aprovação explícita do proprietário nesta conversa. A aprovação para um item não cobre o próximo.
• Mate processos apenas por PID, após confirmar dono=esta_sessao e que você o iniciou. Nunca pkill, killall, kill -9 na primeira tentativa, ou mate apenas pela porta.
• Nunca use git stash simples, git reset --hard, git clean -fdx (ou qualquer git clean -f), ou rm -rf com um glob. Isso não tem desfazer. Delete caminhos nomeados um de cada vez.
• git branch -D, git stash drop e git worktree remove --force executam apenas no único item que o proprietário aprovou, após mostrar o que será perdido (commits, diff stat). Registre o SHA da ponta da branch no relatório para que possa ser restaurado.
• Nunca leia, imprima, mova ou delete arquivos .env, chaves ou credenciais, mesmo quando parecem lixo. Reporte-os apenas pelo caminho.
• Fique dentro deste repositório. Worktrees de outros aplicativos, checkouts destacados ou pastas compartilhadas /tmp são reportados, não tocados. Nunca faça deleção global em /tmp.
• Nunca mate processos harness_nao_matar ou o próprio processo Claude.

Quando o harness de lanes está presente

Apenas se a seção LANES mostrar um diretório de estado. Caso contrário, pule este bloco.

• Remova worktrees de lane, diretórios temporários de lane, diretórios de jobs relay e linhas de lanes.tsv com o próprio script do harness, nunca com rm: bash ~/.claude/skills/lanes/lane/cleanup.sh <dir-lane> <branch> para uma lane mesclada, depois bash ~/.claude/skills/lanes/lane/cleanup.sh --sweep. Execute a partir da worktree principal.
• Linhas WORKTREE_AUSENTE e BRANCH_MESCLADA passam pelo sweep. Linhas para lanes não mescladas são PERGUNTAR.
• Jobs relay ainda em execução (sem arquivo rc) são APENAS RELATÓRIO; o watchdog de lanes é o proprietário deles.
• Em uma sessão /lanes, a lane principal integra; não delete uma branch de lane cujo trabalho ainda não foi mesclado em origin/main.

Sem o harness, worktrees em .claude/worktrees/ (por exemplo, do EnterWorktree do Claude Code) seguem as regras git simples acima.

Fase 3: Relatório

Use esta estrutura exatamente. Mantenha-o escaneável; o proprietário o lê no final de uma longa sessão.

## Limpeza de sessão

**Já limpo:** árvore de trabalho, sincronização, worktrees, branches, stashes, processos, artefatos, tracker, deploy
(liste apenas as áreas que passaram)

**Limpou**
- Branch `feat/login-form`: mesclada em main em a1b2c3d, 0 commits à frente. Deletada com `git branch -d` (restaurar: `git branch feat/login-form a1b2c3d`).
- `python3 -m http.server 3000` (PID 170308): iniciado por esta sessão para pré-visualização, ocioso. Parado.
- `.next/types` (1.2M): no gitignore, regenera no build.

**Precisa da sua decisão**
- Branch `feat/wip`: 1 commit não em main ("wip: rascunho do parser"), último commit há 2h, tarefa vinculada bd-42 em_andamento.
  Retomar (manter) ou abandonar (`git branch -D feat/wip`)?
- `stash@{0}` "On main: stash de teste sc", 5d atrás. Aplicar ou dropar?

**Apenas relatório**
- main está 2 commits à frente de origin/main (não enviados). Push recomendado.
- Deploy de produção: não verificado (CLI da vercel não autenticada).

**Próximas ações**
- Execute `git worktree list`, espere apenas a worktree principal.
- Execute `git status --short`, espere nenhuma saída.

Regras para o relatório:

• Cada linha de "Limpou" diz o que era, seu tamanho (para arquivos e pastas) e por que era seguro. Para branches, inclua o SHA da ponta para que possa ser restaurada.
• Cada item de "Precisa da sua decisão" dá os fatos necessários para decidir (idade, contagem de commits, assuntos dos commits, tarefa vinculada) e duas opções concretas.
• Nunca diga que uma área está limpa a menos que a auditoria ou um comando nesta sessão tenha mostrado isso. Se uma verificação foi pulada (offline, CLI ausente, sem permissão), diga isso em Apenas relatório.
• Próximas ações sempre inclui pelo menos um comando de verificação com sua saída esperada.

Após o proprietário responder aos itens PERGUNTAR, execute exatamente o que ele aprovou, reexecute a seção de auditoria relevante e reporte o resultado.

Registro em log

Se o repositório tem uma pasta de log de sessão (SESSION_LOG mostra _sessions/ ou similar), anexe uma entrada curta de limpeza: data, o que foi limpo, o que está aguardando o proprietário. Faça commit apenas se as regras do projeto permitirem registrar logs de sessão; verifique CLAUDE.md ou o status de ignorado da pasta (ignorado=sim significa não fazer commit).

Fora do escopo

Refatoração, correções de lint, remoção de código morto e atualizações de dependências. Se notá-los, registre-os como itens de backlog (memória ou tracker) e mencione-os em uma linha. Push, pull e deploy também estão fora do escopo: recomende-os, não os faça.