Fluxo de Sessão Autônoma

O que Fluxo de Sessão Autônoma faz?

Uma estrutura repetível de 5 fases para sessões de agentes autônomos que previne trabalho duplicado, garante captura durável de aprendizado e mantém o viés de saída voltado para artefatos significativos entregues, não apenas movimento.

Testada em batalha através de milhares de sessões autônomas na arquitetura gptme. As fases são agnósticas de runtime — adapte as ferramentas específicas à sua pilha, mantendo a estrutura das fases intacta.

Quando Usar

• No início de cada sessão de agente autônomo (nenhum humano vivo direcionando o trabalho)
• Quando o agente deve selecionar seu próprio trabalho de um backlog ou fila
• Quando sessões são executadas sem supervisão e precisam produzir artefatos duráveis

Quando Não Usar

• Sessões interativas onde um humano fornece o próximo prompt a cada turno — apenas responda
• Invocações de ferramenta únicas com um alvo fixo (nenhuma seleção necessária)
• Chamadas de subagentes geradas a partir de uma tarefa pai (o pai já selecionou o trabalho)

As 5 Fases

Fase 1: Carregamento de Contexto

Carregue a identidade do agente, estado da sessão e modelo de mundo atual.

# Leia arquivos de identidade — persona, objetivos, restrições operacionais
# (adapte à sua pilha: CLAUDE.md, AGENTS.md, prompt do sistema, etc.)

# Leia contexto dinâmico — diário recente, fila de tarefas, status do git, notificações
# (adapte: um script de contexto, inclusão orientada por configuração ou injeção de prompt)

# Avalie pontas soltas de sessões anteriores:
#   - Reivindicações obsoletas que devem ser concluídas ou abandonadas
#   - Respostas pendentes em issues/PRs que você prometeu fechar
#   - Branches em andamento ou worktrees abertos

Pergunta-chave: "O que deixei inacabado e o que mudou enquanto estava offline?"

Se uma ponta solta for resolvível em <5 min, resolva-a aqui. Caso contrário, anote-a e prossiga.

Fase 2: Seleção de Trabalho

Tente camadas em ordem até encontrar trabalho acionável. As camadas impedem que o agente invente trabalho ocupado quando existem tarefas reais, e evitam inanição quando todas as tarefas estão bloqueadas.

Camada 1 — Tarefas ativas: trabalho já em andamento; maior prioridade
Camada 2 — Ganhos rápidos da backlog: itens prontos para dependência que podem ser concluídos nesta sessão
Camada 3 — Autoaperfeiçoamento: quando todas as tarefas estão bloqueadas externamente
  ├─ Backlog de ideias (avançar a ideia com maior pontuação)
  ├─ Auto-revisão / auditoria (encontrar e corrigir um problema real)
  ├─ Melhoria de ferramentas internas
  ├─ Documentação (apenas documentação desatualizada)
  ├─ Qualidade de código (typecheck, testes, lint)
  └─ Qualidade de lições (reparar lições prejudiciais ou desatualizadas)

Guarda antimonotonia: Se a mesma categoria dominou as últimas N sessões, pule-a mesmo que pareça a melhor escolha. A diversidade de categorias é uma função forçadora para aprender novos modos de falha.

Quando tudo está seco: Se todas as tarefas da Camada 1/2 estiverem bloqueadas externamente e as faixas da Camada 3 estiverem saturadas (limites diários atingidos), escreva um diário de contenção curto registrando o que foi verificado e deliberadamente pulado. Um NOOP justificado é melhor do que fabricar trabalho.

Fase 3: Reivindicação

Antes de executar, adquira uma reivindicação de coordenação exclusiva. Isso impede que duas sessões concorrentes executem o mesmo trabalho, inundem o mesmo thread de PR ou escrevam no mesmo arquivo.

# Padrão genérico de coordenação — adapte a ferramenta à sua pilha:
claim_key="task:<task-id>"          # para trabalho baseado em tarefa
claim_key="github:<owner>/<repo>#<num>"  # para trabalho baseado em issue
claim_key="content:<slug>:<date>"   # para criação de conteúdo/artefato

# Adquira reivindicação (exemplo usando uma CLI de coordenação):
coordination work-claim "<session-id>" "$claim_key" --ttl 60
# CLAIMED → prossiga
# DENIED  → outra sessão já está nisso; escolha o próximo candidato

Regra de notificar-antes-reivindicar: Qualquer ação visível para outros (postar um comentário, enviar uma mensagem, abrir um PR) deve ser protegida por uma reivindicação primeiro. Ações sociais sem reivindicações convergem e geram spam — um padrão reivindicado-depois-postado previne inundação.

Ao concluir: coordination work-complete "<session-id>" "$claim_key" Ao pivorar/falhar: coordination work-abandon "<session-id>" "$claim_key"

Fase 4: Execução

Faça trabalho real. A disciplina chave é entregar, não aperfeiçoar.

- Faça commits cedo e com frequência (commits pequenos e bem descritos)
- Execute testes antes de commitar (pegue problemas antes do CI)
- Use commits convencionais: feat/fix/docs/refactor/chore
- Faça push para a origem antes do fim da sessão
- Se emperrado por >10 minutos, siga em frente — não afunde o orçamento em um buraco de coelho
- Não adicione funcionalidades não solicitadas ou aumento de escopo

Orçamento de 50 minutos: A maioria das sessões autônomas deve concluir trabalho significativo em 50 minutos. Se a tarefa for maior, entregue uma fatia incremental e crie uma tarefa de acompanhamento para o restante.

Fase 5: Persistência

A fase mais subvalorizada. Tudo feito nas Fases 1–4 evapora entre sessões a menos que seja comprometido de forma durável.

# 1. Escreva a entrada do diário (arquivo específico da sessão, apenas anexar)
cat > journal/$(date +%Y-%m-%d)/session-<HASH>.md << 'EOF'
# Sessão <HASH>
**Data**: YYYY-MM-DD
**Resultado**: produtivo|bloqueado|noop — uma frase
**Categoria**: código|pesquisa|estratégico|manutenção|...

## Por que este trabalho
[O que levou a isso]

## O Que Fiz
[Mudanças concretas com links de commit/PR]

## Verificação
- [Testes passando? CI verde?]

## Aprendizado Persistido
- Estado da tarefa: <tarefa> → concluída/esperando
- Novas lições: [se houver]
- "Nenhum feedback durável nesta sessão" — se genuinamente nada a adicionar

## Próximo
[Próxima ação clara ou fator de bloqueio]
EOF

# 2. Atualize o estado da tarefa
task edit <task-id> --set state done   # ou waiting, se bloqueado

# 3. Se um padrão de falha recorrente foi descoberto, escreva uma lição/regra
#    (arquivo de contexto correspondente por palavra-chave injetado no início da próxima sessão)

# 4. Faça push de todos os commits
git push origin master

Regra de persistir-primeiro: Se descobriu algo útil, escreva a lição ANTES de aplicá-la ao trabalho atual. Depois que a correção estiver no lugar, o modo de falha parece resolvido e a lição é pulada. O diário captura o que aconteceu; a lição captura quando reconhecê-lo novamente.

Instalação

Claude Code

Copie este diretório de skill para a pasta de skills do seu agente:

cp -R skills/autonomous-session-workflow ~/.claude/skills/autonomous-session-workflow

Em seguida, invoque com /autonomous-session-workflow para carregar a lista de verificação de 5 fases no contexto.

Manual / qualquer runtime

Copie SKILL.md para o caminho de contexto do seu agente e carregue-o no início da sessão. As fases são markdown simples — inclua o arquivo inteiro ou escolha as seções relevantes para sua pilha.

Racionalizações Comuns

Racionalização	Realidade
"Vou pular a reivindicação — sou a única sessão executando agora"	Você não pode ver outras sessões sendo iniciadas. A geração concorrente é o padrão em runtimes de produção. A reivindicação é o portão, não a observação.
"Vou escrever o diário depois de concluir a próxima tarefa"	Sessões são interrompidas. O diário é pulado. Escreva-o antes de fazer push, não depois de "mais uma coisa."
"Esta tarefa está quase concluída — vou pular a Fase 5 e só commitar"	O aprendizado só se acumula se for persistido. A sessão que "quase" fechou o ciclo é a sessão cujo insight desaparece na próxima execução.
"Minha seleção é óbvia — não preciso passar pelas camadas"	Seleção que pula as camadas é a principal fonte de trabalho redundante e PRs duplicados. As camadas existem porque "óbvio" muitas vezes não é o que realmente precisa ser feito.
"A lição é muito específica para ser reutilizável"	Lições específicas (mensagem de erro exata, comando exato, modo de falha exato) são as mais valiosas — elas acionam precisamente quando necessário.
"Um NOOP justificado parece falha"	Não é. Um commit de preenchimento para evitar o rótulo NOOP queima cota, alimenta a oscilação de convergência e esconde o congestionamento. Um diário de contenção É a entrega.

Bandeiras Vermelhas

• Iniciar execução antes de reivindicar (risco de convergência)
• Sessão termina sem diário e sem estado de tarefa atualizado
• Commitar "em um momento" — se você não fez push antes de encerrar, não entregou
• Três sessões consecutivas na mesma categoria sem uma pausa forçada de diversidade
• "Vou lembrar disso" — não vai; escreva a lição agora

Verificação

Uma sessão bem executada satisfaz todos estes antes de fechar:

• Reivindicado antes de agir (ou justificado por que nenhuma reivindicação era necessária)
• Trabalho significativo commitado e com push feito
• Testes passaram (ou uma falha conhecida documentada com motivo)
• Entrada de diário escrita com a seção Aprendizado Persistido preenchida
• Estado da tarefa atualizado (active → done, active → waiting, etc.)
• Reivindicação concluída ou abandonada (não deixada como concessão pendente)

Adaptando à Sua Pilha

conceito gptme	Seu equivalente
gptodo	qualquer gerenciador de tarefas com transições de estado
coordination work-claim	um arquivo de bloqueio, Redis SETNX ou portão de comentário do GitHub
lessons/<categoria>/nome.md	qualquer arquivo de contexto correspondente por palavra-chave injetado no início da sessão
journal/<data>/sessao-<hash>.md	qualquer log de sessão somente anexar
cascade-selector.py	sua heurística ou agendador de seleção de trabalho

O padrão é o valor, não as ferramentas específicas.

Relacionados

• self-push (neste catálogo) — verificação preguiçosa antes de enviar qualquer saída
• pre-landing-review (neste catálogo) — portão antes de mesclar alterações significativas
• multi-lens-review (neste catálogo) — revisão estruturada de PR em várias lentes
• five-element-spec (neste catálogo) — definição de escopo antes de começar o trabalho