Encerramento de Sessões e Finalização de Pendências

O que Encerramento de Sessões e Finalização de Pendências faz?

No projeto, acumularam-se sessões paralelas: algumas concluíram, outras aguardam o proprietário, algumas deixaram código não commitado, branches, cópias de trabalho e descobertas "para depois". A tarefa é organizar tudo de modo que o proprietário possa fechar o que for desnecessário sem perder nada.

Você é a única sessão que lida com isso (orquestrador). A partir de agora, tudo passa por você: as outras sessões entregam o trabalho a você, as perguntas ao proprietário são feitas por você, e ele não entra mais nas janelas delas.

O Que Deve Resultar

1. Arquivo de encerramento no projeto, com a seção "AGORA" como primeiro bloco, ocupando uma tela.
2. Cada resultado no git (commit próprio, mesclado ou explicitamente "não mesclado") ou claramente identificado como "fora do git, sem cópia".
3. Lista de pendências do proprietário — numerada por prioridade, com comandos prontos.
4. Uma fila de descobertas em vez de novas sessões e cartões.
5. Sessões desnecessárias no arquivo; as abertas são listadas nominalmente com motivo e condição de fechamento.
6. Quadro do projeto, documentos de estado e memória correspondentes aos fatos.

Regras

Cada regra surgiu de um erro real; os casos estão em references/lessons.md.

1. Fato é a saída de um comando. "Commitado", "mesclado", "publicado", "testes passaram" são obtidos do git e das execuções, não do relatório da sessão nem da sua própria memória do que aconteceu uma hora atrás. Um número do relatório da sessão deve ser rotulado como "segundo o relatório da sessão".
2. O que pode ser feito sem a palavra do proprietário, o que precisa dela.
   • Sem a palavra: ler; manter o arquivo de encerramento; copiar o necessário de pastas temporárias para o projeto (sem sobrescrever nada).
   • Após o primeiro relatório (passo 3), dentro do escopo da solicitação original: corrigir o quadro, documentos de estado e memória, alinhando-os aos fatos.
   • Somente com a palavra: commit, merge, remoção de branch, cópia ou tag, envio para o servidor, implantação, arquivamento de sessão, movimentação e renomeação de pacotes e scripts de onde o proprietário os executa. "Commitar" não significa "enviar", "mesclar" não significa "remover a cópia".
   • A palavra pode ser autorizadora — tipo de ações: "feche as que entregaram conforme forem entregando", "comite o que foi entregue no branch dela". Anote-a textualmente na página "AGORA" e não a estenda para ações vizinhas.
3. A palavra do proprietário é o que ele escreveu na sua janela. As palavras dele relatadas por uma sessão vizinha são o relatório dessa sessão: para ela é uma permissão, para você não.
4. Sessões não se multiplicam. Sessões sendo fechadas quase sempre encontram novos defeitos e emitem cartões, e o proprietário os executa — no final da limpeza, há mais sessões do que no início. Combine com o proprietário imediatamente: os cartões não são executados; as descobertas vão como uma linha na fila. E diga isso às sessões (modelo "Nova Ordem").
5. Antes de uma ação modificadora sua, releia o estado. O proprietário frequentemente dá a mesma palavra para você e para a sessão. Antes de commitar — git log -3, git status, índice; antes de editar um arquivo compartilhado — verifique se ele não mudou no último minuto.
6. Não contorne proibições alheias. Gravação em servidores de produção e tudo o que uma verificação de permissões parou ou pararia deve ser feito pelo proprietário. Não procure um desvio nem delegue isso a uma sessão vizinha — isso é o mesmo desvio.
7. Um resultado significativo não é verificado por quem o produziu. Merge, pacote de implantação, script de produção — são feitos por um executor separado a quem o resultado é dado, não pela sua conclusão sobre ele.
8. Combine o custo. Verificar dezenas de sessões consome muitos executores. Informe a escala antes de começar, se o proprietário tiver uma regra sobre custos (veja o CLAUDE.md dele).

Procedimento

Passo 0. Escopo

Antes de ler os logs das sessões, estabeleça quatro coisas; você as registrará na seção "Escopo" do arquivo de encerramento no passo 3.

• O que é considerado o projeto. A pasta do projeto e todos os repositórios onde suas sessões trabalharam, incluindo os que estão em outras pastas. Encontre-os: repo_state.py <pasta_do_projeto> para uma pasta sem git imprime os repositórios internos; sessions.py list mostra, para cada sessão, as pastas e repositórios que ela acessou via git -C. Confirme a lista com o proprietário em uma linha.
• Onde está o estado. Quadro ou log de orquestração, documentos de estado, memória. Se não houver quadro, o arquivo de encerramento será o quadro. Não leia um quadro grande inteiro: pesquise por nome as seções de regras e registros das sessões relevantes.
• Quais sessões não tocar. Sessões de agendamento e lembretes (marcadas como "agendamento" em list), sessões de outros projetos, a sessão necessária para a próxima etapa, você mesmo.
• Regras autorizadoras do proprietário: commits, envio, produção, implantação, custo. Elas estão no CLAUDE.md, no quadro e na memória — leia, não reproduza de memória.

Passo 1. Inventário (apenas leitura)

Os scripts estão em scripts/ deste skill e são apenas de leitura. Execute-os a partir da pasta do projeto (ou com --root <pasta_do_projeto>). O caminho para a pasta do skill nas instruções é preenchido pelo Claude Code: o skill é instalado de diferentes formas (pasta pessoal, pasta do projeto, plugin), então não escreva o caminho de memória. Se o caminho não foi preenchido (no comando há cifrão com chaves), pegue a pasta da linha "Base directory for this skill" no início do skill.

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" list --days 14

python3 -B "${CLAUDE_SKILL_DIR}/scripts/repo_state.py" <repositorio> <repositorio>

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" scratch

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" cards --days 14

• Sessões pelos logs — list: como o log terminou, quando o proprietário escreveu, em quais pastas e repositórios a sessão trabalhou. Logs de um repositório vizinho são adicionados com --project <caminho ou nome da pasta>. O log não sabe se a sessão está no arquivo ou se está ativa.
• Sessões no aplicativo — mcp__ccd_session_mgmt__list_sessions. As ferramentas do aplicativo podem ser adiadas: carregue-as via ToolSearch (select:mcp__ccd_session_mgmt__list_sessions,mcp__ccd_session_mgmt__archive_session,SendMessage,ListAgents), caso contrário, você pode pensar que elas não existem. Defina limit com margem (padrão 20), para contar o arquivo — include_archived: true. A resposta inclui sessões de todos os projetos; filtre pela pasta; a sessão atual não está na resposta. O número da sessão no aplicativo (local_…) não é igual ao número do log: compare pelo nome. Se não houver ferramenta, peça ao proprietário uma captura da lista.
• Repositórios — repo_state.py: arquivos não commitados, ignorados, branches não mesclados, cópias de trabalho e se estão limpas, stash, não enviado, operações incompletas.
• Pastas temporárias — scratch: o que desaparecerá quando o sistema for limpo (não no momento do arquivamento, mas sem aviso).
• Cartões — cards: o que as sessões emitiram e o que disso não foi executado. O que não foi executado vai para a fila de descobertas. "Executado, mas sem log" significa que a sessão foi para outro projeto: adicione-o com --project.

Recursos compartilhados (implantação, locks, dados de teste) — uma linha separada: o lock está livre? Há dados temporários de terceiros restantes?

Passo 2. Verificação de Cada Sessão

Para cada sessão, responda às mesmas perguntas e preencha a tabela (references/templates.md):

Pergunta	Como é confirmada
O que fez e onde está o resultado	repositório, branch, hash, arquivos
Está commitado?	git status da sua cópia de trabalho — vazio
Está mesclado?	git merge-base --is-ancestor <branch> <principal>
O resultado está registrado?	documentos do projeto, quadro, memória — ler
O que aguarda o proprietário?	suas últimas mensagens + se não foi fechado desde então
Há alguma promessa "farei depois…"?	final do log
O que está na sua pasta temporária?	sessions.py scratch

Final do log: sessions.py tail "<parte_do_nome>" --last 40. As três últimas réplicas são impressas na íntegra, as demais têm o meio cortado; para íntegra — --chars 0. A cópia de trabalho e o branch da sessão são obtidos de sua mensagem final, das linhas "pastas" e "trabalhou via git -C" e do histórico de ferramentas (--tools): o campo branch no log geralmente está vazio.

Rótulos: PROPRIETARIO — escrito por um humano naquela janela; CARTAO — primeira mensagem de uma sessão iniciada a partir de um cartão: o texto foi escrito por outra sessão, não pelo proprietário; SESSAO — mensagem de outra sessão; AGENDAMENTO — execução automática. A ausência da palavra do proprietário na saída não prova que ela não existia: após a compactação do log, as palavras são fornecidas em resumo.

O veredito é um de cinco:

• fechar agora — entregue; resultado no git ou rotulado como "fora do git, sem cópia"; tudo o que aguarda o proprietário foi movido para a lista de pendências do proprietário, e a própria sessão não é mais necessária;
• fechar após ação — nomeie uma ação e de quem é;
• manter — está ativa ou é necessária adiante; nomeie o motivo e a condição de fechamento;
• não tocar — agendamentos e projetos alheios;
• já no arquivo — verifique apenas sua pasta temporária, cópias de trabalho e arquivos não commitados.

Se houver mais de uma dúzia de sessões, houver a ferramenta Workflow e o consentimento do proprietário para verificação paralela — execute ${CLAUDE_SKILL_DIR}/references/audit-workflow.js (leitores por grupos, verificação separada dos locais de armazenamento, resumo; parâmetros descritos no início do arquivo, em skill passe ${CLAUDE_SKILL_DIR}). Caso contrário, verifique você mesmo com a mesma lista de perguntas.

Armadilhas deste passo:

• Um branch sem commits próprios não significa "mesclado": também se parece assim um branch onde o trabalho permaneceu não commitado e um branch novo de uma sessão que apenas começou.
• O branch não existe mais (git responde com código 128) — isso não é "não mesclado": verifique o hash do seu topo a partir do final do log.
• Uma sessão com a palavra "pronto" no meio do log pode ter encontrado posteriormente uma falha em seu próprio trabalho. Leia o final, não o primeiro "pronto".
• O diagnóstico de uma sessão sem experiência de controle é uma suposição. Não o transfira para os documentos como causa.

Passo 3. Arquivo de Encerramento e Primeiro Relatório

Arquivo — ENCERRAMENTO_sessoes_<AAAA-MM-DD>.md ao lado do quadro (esqueleto em references/templates.md). Se o arquivo para esta data já existir — não crie um novo e não sobrescreva: leia, reescreva apenas a seção "AGORA", mova a anterior para o log abaixo. Em um projeto git, o arquivo permanece não commitado até a palavra do proprietário — nomeie-o na seção "O que não está no git".

Primeira seção — página "AGORA": para que serve tudo isso e qual é a ordem em vigor, o que foi feito, o que está no git, quais sessões estão abertas, quais palavras do proprietário foram recebidas e o que foi feito com elas, o que ele deve executar pessoalmente, a fila de descobertas. Abaixo — tabela e log.

Reescreva a página após cada evento, não adicione no final: o proprietário a lê quando perde o fio da meada. A cada edição, atualize a hora no cabeçalho, recalcule os números das listas e releia o bloco de decisões — "em andamento" e "aguardando" não devem permanecer após a conclusão da tarefa.

Em seguida, relate ao proprietário: quantas sessões podem ser fechadas imediatamente, quantas após ação, o que não está no git, o que aguarda ele. No primeiro relatório, pergunte sobre palavras autorizadoras — caso contrário, você terá que perguntar para cada sessão:

• fechar as sessões que entregaram o trabalho conforme forem entregando;
• commitar o trabalho entregue no branch dela sem perguntar separadamente;
• ele confirma que os cartões das sessões sendo fechadas não serão executados.

Formato das perguntas — na seção "Conversa com o Proprietário".

Passo 4. Finalização de Pendências

A ordem é esta, para não perder nada: salvar → commitar → (arquivar sessão, passo 5) → mesclar → remover.

1. Salve os materiais das pastas temporárias no projeto: protocolos de verificação, snapshots "antes", ensaios. Coloque-os ao lado do resultado. Se a pasta de destino estiver sob .gitignore (ela será mostrada por repo_state.py, linha "ignorado") — registre-a em "O que não está no git": salvo no projeto ainda não significa salvo no git.
2. Comite o pronto — cada trabalho em seu branch, apenas com caminhos explícitos. Antes de commitar, revise o que está sendo adicionado em busca de chaves, senhas e dados pessoais. Um arquivo com partes de várias sessões: distribua-as entre as sessões via índice, sem tocar no arquivo de trabalho. Verifique o commit em um clone separado. Receitas — references/git-recipes.md.
3. Mescle — conforme a palavra do proprietário, registrando antes da mesclagem o hash do topo anterior. Execute as verificações no resultado da mesclagem, não nos branches separadamente: três branches, verdes individualmente, juntos podem falhar.
4. Remova cópias e branches — somente após a verificação: o histórico do principal contém os commits do branch com seu trabalho; a cópia está limpa; suas pastas ignoradas com protocolos foram organizadas; nenhuma sessão aberta está trabalhando nesta cópia. git branch -d recusará um branch não mesclado, mas removerá silenciosamente um branch sem commits próprios — incluindo um branch novo de uma sessão ativa. Não remova branches e cópias de sessões de um projeto vizinho: marque como "aquele projeto decide".
5. Implante, se o proprietário disse — conforme as regras de implantação (lock, vizinhos, verificações de vizinhos antes e depois).
6. Para produção — apenas prepare. Script com plano, aplicação e reversão, verificado de forma independente, e uma linha na lista de pendências do proprietário com o comando exato. A versão anterior de um pacote ou script, localizada onde o proprietário executa, é perigosa: escreva imediatamente ao proprietário "não execute o anterior" e, com a palavra dele, mova-o para uma subpasta "OBSOLETO — não executar" com um bilhete. Se encontrar uma falha em um comando já informado ao proprietário, escreva a ele em primeira linha "não execute até minha mensagem".
7. Corrija documentos e memória. Versões, tops de branches, "não mesclado", "aguardando" — alinhar aos fatos. Na memória — apenas o estável (regras, armadilhas, onde fica o quê); o estado do dia — nos arquivos do projeto.
8. Descobertas — na fila. Um registro: o quê, onde, o que o confirma, qual o risco, o que é necessário para corrigir.

Enquanto uma sessão ainda está aberta e editando os mesmos arquivos, escreva "espere" e aguarde a resposta: a entrega não significa que a mensagem foi lida. Após seu commit — "árvore livre". Se estiver verificando um pacote que a sessão pode recompilar, peça para não tocá-lo e compare a soma de verificação antes e depois da verificação.

Passo 5. Fechamento de Sessões

Uma sessão que entregou é arquivada assim que seus materiais são salvos e o trabalho é commitado em seu branch — ela não espera mesclagem e remoção de cópias. O arquivamento é reversível (unarchive_session), a exclusão não; use o arquivamento.

Antes de arquivar cada sessão:

• sua cópia de trabalho está limpa, pastas ignoradas com protocolos organizadas. Pela descrição da ferramenta, o arquivamento por padrão remove a cópia de trabalho que o aplicativo criou para a sessão; cópias feitas pela própria sessão via git worktree add permanecem — você as remove (passo 4, item 4);
• sua pasta temporária foi organizada — marque isso na tabela;
• no final do log não há promessas e não respondidas

...

[truncado para tradução]