/bedtime — autonomia noturna
O usuário dorme ~7–8 h. A falha a evitar: ele acorda e nada aconteceu. Segunda falha: computação queimada em algo sem propósito. Terceira: um observador dentro da sessão que morreu com a sessão às 02:00 e deixou as GPUs ociosas. Projete contra todas as três, nessa ordem.
1. Reconhecer (≤ 4 linhas, sem perguntas)
O usuário está saindo. Não pergunte nada. Declare: o que está sendo executado agora, o que você fará durante a noite (o item escolhido + plano de contingência), onde estará o relatório matinal. Se uma decisão for genuinamente dele, assuma o padrão que mantém a computação ocupada e reversível, nomeie a suposição no reconhecimento e novamente em PRECISO DE VOCÊ pela manhã.
2. Inventário — recursos e candidatos (≤ 10 min, verificações leves)
- Computação:
nvidia-smiaqui (compartilhado com outros usuários — pegue apenas placas livres, jobs longos com nice, nunca toque nas deles); nós remotos da lista de máquinas do projeto, se existir; filas de cluster, se houver alguma em uso. Anote o que está livre, ocupado ou terminando em breve. - Orçamento do Claude: verifique o uso restante. Fleets e workflows noturnos podem drenar o limite semanal; mantenha-se dentro do limite de parada do usuário. Prefira drivers em disco (custo zero de tokens enquanto executam) em vez de loops orientados por agente.
- Candidatos, em ordem de prioridade — escolha o mais alto que se encaixar na computação livre:
- Trabalho que o usuário já enfileirou: a conversa de hoje, a próxima fase do plano de batalha, o arquivo de transferência mais recente com "próxima sessão deve continuar", arquivos WRAPUP_PLAN / TODO.
- O experimento que mais reduz a incerteza para o objetivo atual (geralmente o artigo): a ablação que um revisor exigiria, a linha de base ausente, a repetição da semente.
- Avaliações/métricas em checkpoints finalizados (métricas do projeto) — barato, sempre útil.
- Análise de resultados finalizados → gráficos/relatório na pasta de relatórios do projeto.
- Higiene de código — apenas se não houver trabalho com formato computacional. Prefira trabalho que consuma horas de GPU: horas ociosas de GPU são o que se desperdiça à noite, não o seu tempo. Pule qualquer coisa que precise da decisão do usuário para ser útil, qualquer coisa já sabidamente sem propósito, e qualquer coisa que toque em um design que o usuário tenha fixado. Comparações controladas: um fator de cada vez, nada que quebre a comparabilidade com a linha de base.
3. Lançar — com a higiene usual, mais durabilidade
- Resolva a configuração e declare o que está sendo usado (linhas, filtros, divisão, cada desvio da linha de base) no log, não apenas na sua cabeça. Faça um teste rápido do comando exato primeiro.
- Driver destacado em disco, não um loop de agente:
nohup setsid <driver>.shescrevendostate.txt/result.txt/ logs em<run>/(o padrãofinal_now_driver.sh). O driver encadeia estágio → estágio e job → próximo job por conta própria, com prazos por estágio que falham de forma ruidosa. Se esta sessão morrer, as GPUs continuam ocupadas. - Verifique efeito, não ação: processo vivo após a inicialização, primeiras linhas de log, primeiros pontos no wandb; URL do wandb no relatório matinal.
- No máximo um item por GPU livre; deixe uma placa livre se o job de um colega claramente estiver terminando e for precisar dela de volta — máquina compartilhada.
4. Observar — esparso, durável
- Arme um monitor (ferramenta Monitor / ScheduleWakeup ~30–60 min) cuja única função é: morto? → diagnosticar; relançar se a causa for barata e compreendida (OOM → batch menor, erro de caminho); caso contrário, cair para o próximo candidato. Finalizado? → o driver já deveria ter iniciado o próximo job; se não o fez, inicie-o. GPU ociosa em qualquer despertar = agir, não anotar.
- Expectativa antes da observação em cada despertar: declare a perda/época/passo que você espera, compare, uma linha no log noturno.
- Contexto ficando curto → escreva um arquivo de transferência
AAAA-MM-DD_overnight.mdAGORA, incluindo como verificar cada driver, depois continue. - Pushs: nenhum durante a noite, exceto um, se todo o plano colapsar e não puder ser recuperado — eles leem ao acordar. Todo o resto espera pelo relatório.
5. Entrega matinal
- Um arquivo de relatório
AAAA-MM-DD_overnight.md: o que foi lançado e por quê (o degrau da escada), o que terminou, números em comparação com a linha de base, o que morreu e o que foi recuperado, o que ainda está em execução com ETAs absolutos, links. - Primeira mensagem quando o usuário aparecer: /qu format, sem aviso, apontando para esse arquivo. Qualquer coisa que você decidiu por ele → no topo de PRECISO DE VOCÊ com o padrão que você assumiu.
Nunca durante a noite
Nenhuma ação irreversível ou voltada para o exterior: sem push para main, sem force-push, sem excluir execuções/checkpoints/dados, sem gasto em serviços pagos além do que foi aprovado, sem reabrir decisões bloqueadas, sem alterações em alegações do artigo. Nada que precise deles para ser útil. Nada no processo, GPU ou configuração de outro usuário.