Checklist de retomada no vibe coding: o que escrever no fim do dia

Na noite em que o Fumava, o app de parar de fumar de Martin, abriu pela primeira vez no emulador, o pedido de encerramento foi banal:

só faz aqui um pequeno resumo de tudo o que fizemos hoje

Junto do resumo do dia veio outra coisa, escrita na segunda pessoa e começando por "O seu passo a passo": um roteiro de como ligar o ambiente inteiro de novo, do PC recém-ligado até o app rodando na tela. O que se perde entre uma sessão e a seguinte é a ordem de subir as coisas. O código fica salvo em disco e versionado, enquanto a sequência de ligar não fica em lugar nenhum.

Você lembra do que estava construindo. Esquece qual programa abre primeiro, qual comando roda em qual janela, e o que precisa continuar aberto para o resto funcionar.

O conhecimento de ligar o ambiente é o que menos sobrevive de um dia para o outro

Você descobre ambiente por tentativa e erro, e quase nunca escreve o que descobriu. Na noite do Fumava, sair do zero e chegar até a primeira tela passou por instalar o Java que faltava, deixar o ADB visível para o sistema, criar o telefone virtual, esperar a compilação e depois entender por que uma alteração no código não aparecia no emulador. Nada disso estava anotado. Ficou na cabeça de quem tinha acabado de fazer, e é nesse estado que a informação parece óbvia demais para merecer registro. Isso aparece também em harness engineering.

Você abre o projeto na sessão seguinte, tenta subir, alguma coisa não responde, e a primeira hora vai embora repetindo uma investigação que já tinha resposta.

O pedido foi um resumo, mas o roteiro já estava encomendado

Horas antes, ao despachar a tarefa de consertar a atualização automática do app, o agente orquestrador tinha listado o roteiro como entregável e descrito o que ele deveria conter. Pediu o fluxo padrão escrito, partindo da máquina recém-ligada:

PC acabado de ligar, o que abre, qual o comando que corre, o que deixa em aberto

A justificativa foi de operação: é coisa que vai se repetir nos próximos meses. Martin implicou com o prazo e respondeu, com um palavrão no meio, que espera ver o app pronto em 30 dias no máximo.

Quem escreveu o roteiro foi o agente, na segunda pessoa, endereçado a Martin. Ele pediu o resumo do dia; o roteiro veio no mesmo pacote porque o orquestrador tinha encomendado antes, com a justificativa de que aquilo ia se repetir por muito tempo.

O que um roteiro de retomada no vibe coding tem além dos comandos

O que apareceu junto do resumo é curto. Abrir o Android Studio e iniciar o emulador. Abrir a janela de terminal e rodar o comando do projeto. Esperar aparecer a mensagem de que o servidor está aguardando o emulador. Fechar e reabrir o app. A partir daí, nas palavras do próprio roteiro, "o código guardado aparece no ecrã".

Depois dos passos vêm duas regras de operação:

- "Deixa a janela do cmd aberto o tempo todo", porque fechar essa janela mata a atualização automática do app - o comando que recompila o app inteiro não é o do dia a dia: "Ele recompila a app toda, demora minutos", e só serve quando entra biblioteca nova que mexe na parte nativa

Tem ainda o atalho de recarregar por dentro do próprio emulador. E o roteiro fecha dizendo que, no dia seguinte, basta seguir os passos acima.

Uma lista de comandos entrega só os comandos. O roteiro diz o que esperar ver na tela em cada passo, e com isso você sabe se o ambiente ainda está subindo ou se parou de vez. Diz o que não pode ser fechado, então você não mata o servidor sem perceber. E separa o comando barato do comando caro, então você não dispara uma recompilação de minutos quando bastava reabrir o app. Sem essas informações, a retomada vira tentativa: você reexecuta o passo errado e fica esperando à toa.

O leitor desse roteiro não é a IA

Os dois documentos convivem na mesma pasta e são confundidos o tempo todo. O arquivo de contexto é escrito para a IA ler quando a sessão abre: o que é o produto, o que já foi decidido, o que ela não deve tocar. O roteiro de retomada é escrito para você executar com as mãos, fora de qualquer conversa, antes de existir sessão aberta. São leitores diferentes. Misturar os dois num arquivo só deixa o agente lendo instrução de teclado que não é para ele, e deixa você caçando o passo a passo no meio de um documento de produto. Cada um no seu lugar, e vale saber também o que escrever dentro do arquivo de contexto. O mesmo problema apareceu em checklist de tarefa manual no vibe coding.

O que escrever no fim da sua próxima sessão de vibe coding

O melhor momento de registrar como ligar o ambiente é no fim da sessão em que você acabou de descobrir, com o terminal ainda aberto e a sequência fresca. No começo da sessão seguinte já é tarde, porque aí você escreve de memória exatamente a coisa que está tentando lembrar.

Reserve os últimos minutos antes de fechar tudo e escreva, ou peça ao agente que escreva, o caminho de volta a partir do computador desligado. Cada passo com o que abre, o que aparece na tela quando dá certo, o que fica aberto e qual comando você não usa por engano. É um documento pequeno, e é ele que faz o vibe coding continuar amanhã de onde parou.

O mesmo problema reaparece um andar abaixo, dentro do produto que você está construindo: quem abandona um fluxo de várias etapas no meio também precisa voltar para o ponto exato onde parou, e o app só sabe disso se alguém tiver escrito o que já foi feito. Foi assim que o Fumava ganhou um marcador explícito de por onde o usuário passou para retomar o onboarding de onde parou, em vez de deduzir progresso pelos campos preenchidos. Você anota o seu checklist no fim do dia pelo mesmo motivo que a tela precisa gravar que foi vista. Dá para assistir à live inteira e ver de onde ele saiu.