⏰ Tempo: agendamento e loops

Boa parte das tarefas repetitivas do dia a dia — checar e-mail, revisar um número, atualizar uma planilha — dependem só da sua memória e da sua disposição pra lembrar. Quando o dia aperta, elas somem da lista.

Reconhecer esse padrão é o gatilho pra perguntar "isso devia rodar sozinho?" — a pergunta raiz desta trilha inteira.

Tarefa repetitiva, carga mental, esquecimento por sobrecarga.

Toda vez que você pensar em automatizar algo, faça essa pergunta em três partes: preciso disso agora (uma vez só)? Preciso neste projeto (acompanhar por um tempo curto)? Ou preciso toda semana (pra sempre, num ritmo fixo)?

É a bússola da trilha inteira. Cada resposta aponta pra um caminho técnico diferente, e escolher errado custa tempo — ou pior, gera automação rodando sem controle.

Pergunta-guia, escopo temporal, decisão antes da ferramenta.

Se a resposta é "só preciso disso uma vez, hoje", a resposta certa não é agendar nada — é simplesmente pedir direto pro Claude Code, na hora, como você já vem fazendo desde a Trilha 0.

Muita gente automatiza cedo demais uma coisa que só ia acontecer uma vez. Isso desperdiça esforço de configuração num trabalho que não vai se repetir.

Tarefa única, execução direta, sem automação.

Tarefa agendada — novo aqui? É um pedido que você configura uma vez, com um horário fixo (todo dia às 8h, toda segunda, todo mês), e que roda sozinho, sem você abrir o Claude Code de novo. Se a resposta pra pergunta-guia é "toda semana" (ou todo dia, ou todo mês), esse é o caminho.

Rotina de verdade — a que se repete pra sempre no mesmo ritmo — é exatamente o que uma tarefa agendada resolve. O módulo 6.2 detalha como ela funciona por dentro.

Tarefa agendada, horário fixo, repetição indefinida.

Loop — novo aqui? É o Claude Code ficando de olho em algo, verificando de tempos em tempos, dentro da mesma conversa — mas só por um período curto, não pra sempre. Se a resposta é "só enquanto esse projeto durar" ou "só nos próximos dias", esse é o caminho.

Loop resolve o meio-termo: nem uma execução única, nem uma rotina eterna. É pra acompanhar algo vivo — um deploy, uma resposta que está demorando, um arquivo que ainda vai chegar.

Loop, sessão viva, acompanhamento temporário.

A trilha usa uma tabela comparativa (você já viu ela no topo desta página) cruzando onde cada um roda, se guarda memória, quanto tempo dura, o que acontece se o PC desligar, e pra que serve cada um.

Ter essa tabela de cabeça evita o erro mais comum da trilha: configurar uma tarefa agendada pra algo que devia ser um loop rápido, ou vice-versa.

Comparação estruturada, referência de decisão, tabela de bolso.

É um pedido configurado uma única vez — com instrução, horário e frequência — que o aplicativo desktop do Claude Code dispara sozinho, sem você precisar abrir nada nem digitar nada naquele momento.

Entender a mecânica por trás (e não só o "ela roda sozinha") ajuda a configurar direito e a prever quando ela vai (ou não vai) disparar.

Configuração única, disparo automático, aplicativo desktop.

Tarefa agendada vive dentro do aplicativo desktop do Claude Code — não é algo que você configura digitando comando no terminal, como no módulo 0.2. É uma tela própria, com lista de tarefas e horários.

Saber onde procurar evita a frustração de tentar achar essa configuração no lugar errado (o terminal, onde ela não existe).

Aplicativo desktop, interface própria, fora do terminal.

Cada vez que a tarefa dispara, é como se fosse a primeira conversa: ela não lembra o que fez ontem, nem o que você conversou com o Claude Code noutra hora. Só executa a instrução que você deixou configurada.

Esse é o ponto que mais confunde quem vem do loop (módulo 6.3): a tarefa agendada não acumula contexto. Se ela precisa "lembrar" de algo, esse algo tem que estar escrito num arquivo que ela lê de novo toda vez.

Sessão isolada, ausência de memória entre execuções, instrução autocontida.

Diferente do loop, uma tarefa agendada não expira sozinha. Uma vez configurada pra rodar toda segunda às 9h, ela continua rodando toda segunda às 9h até você mesmo pausar ou apagar.

Isso é exatamente o que torna a tarefa agendada certa pra rotina de verdade — mas também por que ela exige mais cuidado na configuração: um erro ali se repete pra sempre, não só uma vez.

Sem expiração automática, repetição perpétua, responsabilidade de desligar.

Se o computador estava desligado (ou sem internet) no horário programado, o app não simplesmente pula aquela execução — ele recupera e roda assim que possível, quando o computador volta a ficar disponível.

Essa é uma diferença prática importante frente ao loop, que simplesmente morre se a sessão fecha. A tarefa agendada é resiliente a interrupções do seu computador.

Recuperação de execução perdida, resiliência a desligamento, reagendamento automático.

Objetivo: configurar uma tarefa que roda toda manhã às 8h e resume os itens pendentes de um arquivo de notas.
Cole no Claude Code (app desktop, tela de tarefas agendadas):
Todo dia às 8h, leia o arquivo <caminho do seu arquivo de notas> e me mande um resumo em 3 linhas dos itens ainda não marcados como feitos.
Como verificar: espere o próximo horário configurado (ou use a opção "rodar agora" se o app tiver) e confira se o resumo chegou.

Ver o prompt de verdade, com o horário e a ação escritos por extenso, tira o medo de configurar a primeira tarefa sozinho.

Prompt copiável, variável marcada, verificação do resultado.

Um loop é o Claude Code repetindo uma verificação de tempos em tempos, dentro da mesma conversa em que você pediu — por exemplo, "fica checando esse site a cada 10 minutos até o preço cair" — sem precisar de você reabrir nada.

É a ferramenta certa pra acompanhar algo que está "em andamento" agora, sem virar uma rotina permanente que você teria que lembrar de desligar depois.

Verificação periódica, mesma sessão, acompanhamento ativo.

Ao contrário da tarefa agendada (presa ao app desktop), o loop roda em qualquer lugar onde você já está conversando com o Claude Code: no terminal, dentro do VS Code, ou no próprio app desktop.

Isso o torna mais flexível pro trabalho do dia a dia — você inicia um loop no meio de uma sessão normal de trabalho, sem trocar de ferramenta.

Multiplataforma, mesma interface de conversa, sem app separado.

Diferente da tarefa agendada, o loop continua dentro da mesma sessão — então ele lembra o que você pediu, o que já checou antes, e pode ajustar o comportamento com base nisso, sem você repetir tudo.

Essa memória viva é o que torna o loop bom pra situações que evoluem: "continua tentando até der certo", "me avisa se mudar".

Continuidade de contexto, sessão única, ajuste ao longo do tempo.

Um loop tem prazo de validade — em torno de três dias. Depois disso, ele para sozinho, mesmo que a condição que você pediu ainda não tenha acontecido.

Esse limite existe de propósito: evita que um "fica de olho" configurado num momento de pressa vire uma automação esquecida rodando pra sempre sem supervisão.

Expiração automática, prazo curto, prevenção de automação órfã.

Se você fecha o terminal, fecha o VS Code, ou desliga o computador antes do loop terminar, ele simplesmente para — e não recupera sozinho como a tarefa agendada faz.

Saber essa fragilidade evita usar loop pra algo crítico que precisa sobreviver a um desligamento. Pra isso, o caminho certo é a tarefa agendada (módulo 6.2).

Interrupção definitiva, ausência de recuperação, dependência da sessão aberta.

Objetivo: pedir pro Claude Code acompanhar um arquivo de log e avisar se aparecer um erro, sem você ficar checando manualmente.
Cole no Claude Code (terminal, VS Code ou desktop):
Fica checando o arquivo <caminho do log> a cada 15 minutos pelos próximos 2 dias. Se aparecer a palavra "ERROR", me avisa na hora com a linha completa.
Como verificar: force um erro de teste no arquivo (ou espere um real) e confira se o aviso chegou dentro da janela de 15 minutos.

Um loop real, com prazo explícito e condição de disparo clara, mostra como escrever um pedido que o Claude Code consegue manter sozinho.

Prompt copiável, condição de disparo, janela de tempo explícita.

"Aprender", aqui, não é a IA ficando mais esperta sozinha — é você (ou a própria rotina, seguindo instrução sua) guardando o que funcionou e o que não funcionou num arquivo, pra próxima execução ler e ajustar o comportamento.

Esse esclarecimento evita expectativa irreal. A rotina melhora porque acumula informação escrita, não porque "entende" você com o tempo.

Ajuste guiado por dados, arquivo de memória, expectativa realista.

Como vimos no módulo 6.2, tarefa agendada não lembra nada entre execuções — a não ser que você dê a ela um arquivo pra ler e escrever. É esse arquivo que vira a "memória" da rotina.

Esse é o truque que resolve o maior limite da tarefa agendada: dar a ela um lugar fixo pra anotar o que precisa lembrar.

Arquivo de preferências, leitura e escrita persistente, memória externa.

Um exemplo prático: se toda vez que a rotina te avisa de algo você responde "ignora isso, não é importante", você pode pedir pra ela anotar esse tipo de aviso numa lista de "não repetir" — e parar de te incomodar com aquilo.

Esse ciclo de correção e aplicação é o que torna a rotina cada vez mais útil (e menos irritante) sem exigir que você reconfigure tudo do zero.

Ciclo de feedback, lista de exclusão, refinamento incremental.

Um script de automação tradicional (fora do Claude Code) faz sempre exatamente a mesma coisa, do mesmo jeito, pra sempre. Uma rotina com memória em arquivo consegue mudar de comportamento sem você reescrever nada — só editando o arquivo, ou deixando a própria rotina editar.

Entender essa diferença ajuda a decidir quando vale a pena montar essa camada extra de memória, e quando um pedido simples e fixo já resolve.

Comportamento fixo × comportamento ajustável, custo de configuração, ganho de flexibilidade.

É importante deixar claro: a rotina não sai por aí desenvolvendo julgamento próprio nem tomando decisões fora do que está escrito na instrução e no arquivo de memória. Todo "aprendizado" tem uma origem rastreável — um texto que alguém (você) decidiu guardar.

Esse limite protege contra dois erros: confiar demais numa rotina achando que ela "entende" contexto que nunca foi escrito, e ter medo dela agir fora do combinado.

Comportamento rastreável, ausência de julgamento autônomo, previsibilidade (ver módulo 6.5).

Objetivo: uma tarefa agendada que, além de avisar você, guarda num arquivo se o aviso foi útil ou não, pra ajustar depois.
Cole no Claude Code:
Toda segunda às 8h, leia <caminho do arquivo de preferências>. Se ele tiver um item marcado "ignorar", não me avise mais sobre esse tipo de coisa. Depois de cada aviso, pergunte se foi útil e anote a resposta nesse mesmo arquivo.
Como verificar: responda "não foi útil, ignora" numa execução e confirme que a próxima execução não repete aquele tipo de aviso.

Colar esse prompt e ver o arquivo de preferências crescer com o tempo é a prova concreta de que "aprender" aqui é escrita e leitura, não mistério.

Prompt copiável, arquivo de preferências nomeado, verificação por repetição.

Determinismo — novo aqui? É a propriedade de um processo sempre dar o mesmo resultado pra a mesma entrada. O oposto — quando o resultado pode variar mesmo com a mesma entrada — chama-se não-determinismo.

Como toda a trilha gira em torno de automação rodando sem você olhar, entender esse conceito é o que separa uma rotina confiável de uma que te pega de surpresa.

Determinismo, não-determinismo, resultado previsível.

Numa conversa ao vivo, se o Claude Code interpreta algo de um jeito inesperado, você corrige na hora. Numa tarefa agendada ou num loop, ninguém está olhando — então uma interpretação estranha pode se repetir (na tarefa agendada) ou passar despercebida (no loop) até causar um problema maior.

Esse é o motivo pelo qual instrução vaga funciona bem numa conversa mas é perigosa numa rotina: o espaço pra interpretação livre precisa encolher quando ninguém está checando em tempo real.

Supervisão ausente, amplificação de erro, instrução vaga vs. instrução precisa.

Antes de deixar qualquer instrução rodando sozinha (agendada ou em loop), peça pro Claude Code executar ela uma vez, na hora, com você olhando. Só depois de ver o resultado correto é que vale configurar pra rodar sem supervisão.

Esse passo simples evita o erro mais caro da trilha: descobrir que a instrução estava mal escrita só depois que ela já rodou sozinha várias vezes.

Execução de teste, validação manual, antes de automatizar.

Mesmo com a mesma instrução, o modelo de IA por trás do Claude Code pode, ocasionalmente, formular a resposta de um jeito levemente diferente entre execuções — não porque "mudou de ideia", mas porque é da natureza estatística de como o modelo gera texto.

Saber disso evita dois erros opostos: confiar cegamente que vai ser sempre idêntico, e desistir da automação achando que é tudo aleatório demais pra confiar.

Variação estatística do modelo, natureza probabilística, nível aceitável de variação.

Instruções específicas (formato exato de saída, passos numerados, exemplos do resultado esperado) reduzem o espaço de interpretação. Pedir pra sempre seguir um modelo fixo de resposta — em vez de "me conta o que achou" — é uma trava simples e eficaz.

Essas travas são a ferramenta prática que você tem nas mãos pra tornar uma rotina mais confiável, mesmo sabendo que 100% de determinismo não existe.

Instrução específica, formato fixo, exemplo de saída esperada.

Objetivo: validar uma instrução manualmente antes de transformar ela numa tarefa agendada ou num loop.
Cole no Claude Code, antes de agendar qualquer coisa:
Antes de eu agendar isso, roda a instrução agora, uma vez, exatamente como ela vai rodar sozinha depois: <cole aqui a instrução que você quer automatizar>. Me mostra o resultado exato que você geraria.
Como verificar: compare o resultado com o que você esperava. Só agende depois de rodar esse teste pelo menos duas vezes e ver resultado consistente.

Esse checklist de teste manual é o hábito prático que sustenta tudo o que os módulos 6.2 e 6.3 ensinaram sobre configurar tarefa agendada e loop.

Prompt de validação, repetição de teste, consistência antes de confiar.

Notificação é o aviso que a tarefa agendada ou o loop manda pra você quando termina (ou quando encontra algo relevante) — sem isso, uma rotina rodando sozinha vira uma caixa preta que você não sabe se funcionou.

Toda automação desta trilha só é útil se você souber o que ela fez. Notificação é a peça que fecha esse ciclo de confiança.

Aviso de conclusão, visibilidade do resultado, caixa preta evitada.

Permissão restritiva — novo aqui? É configurar o Claude Code pra só poder fazer um conjunto limitado de coisas — por exemplo, só ler arquivos, nunca apagar nada — especialmente quando ele vai rodar sem você supervisionando em tempo real.

Numa conversa ao vivo (Trilha 0.6), você vê cada ação antes de acontecer e pode parar na hora. Numa rotina automática, essa rede de segurança desaparece — por isso a permissão precisa ser mais apertada, não mais solta.

Escopo de permissão, ausência de supervisão em tempo real, redução de risco.

Nunca deixe uma rotina automática ter permissão pra apagar arquivos em massa, mexer em configurações do sistema, gastar dinheiro (compras, transferências) ou publicar algo em nome seu sem revisão prévia sua.

Essa lista existe porque o custo de um erro sem supervisão é muito maior do que o custo de um erro numa conversa — e uma rotina mal configurada pode repetir o mesmo erro várias vezes antes de alguém perceber.

Ações irreversíveis, exclusão em massa, publicação sem revisão.

As formas mais comuns de aviso: um e-mail automático, uma mensagem (num app de chat que você já usa) ou, no mínimo, um arquivo de log que registra cada execução — pra você conferir depois, mesmo sem aviso ativo.

Ter pelo menos um canal configurado, mesmo o mais simples (o arquivo de log), é o piso mínimo de responsabilidade ao deixar algo rodando sozinho.

Canal de aviso, arquivo de log como registro mínimo, redundância de aviso.

Se uma tarefa agendada ou um loop fizer algo inesperado, o primeiro passo é pausar ou apagar aquela rotina imediatamente (no app desktop, ou fechando a sessão do loop), depois revisar o log pra entender o que aconteceu antes de reconfigurar.

Ter esse plano decorado — pausar primeiro, investigar depois — evita que um erro pequeno vire um erro repetido, já que tarefas agendadas continuam rodando até você intervir.

Pausa imediata, investigação via log, reconfiguração só depois de entender.

Objetivo: garantir que, se a rotina falhar por qualquer motivo, você seja avisado — não só quando ela funciona.
Cole no Claude Code, ao configurar a tarefa:
Toda vez que essa rotina rodar, escreva uma linha em <caminho do arquivo de log> dizendo se deu certo ou se deu erro, com data e hora. Se der erro, me avise por e-mail imediatamente com o motivo. Você só tem permissão de leitura nos arquivos, nunca de exclusão.
Como verificar: force um erro de propósito (aponte pra um arquivo que não existe) e confira se o aviso de falha chegou.

Esse prompt junta as duas partes do módulo — notificação e permissão restritiva — num único pedido pronto pra usar em qualquer rotina sua.

Prompt copiável, permissão explícita no texto, teste de falha proposital.

Este módulo final monta, passo a passo, uma rotina matinal completa: algo que resume o que importa no seu dia (agenda, pendências, um número que você acompanha) e te entrega pronto, sem você pedir nada.

É a prova de que os seis módulos anteriores — pergunta-guia, tarefa agendada, loop, memória, determinismo, permissões — se juntam num resultado prático, não só teoria isolada.

Projeto integrador, rotina de produção, aplicação de todos os conceitos da trilha.

Aplicando o módulo 6.1: uma rotina matinal roda todo dia, sempre — então a resposta é "toda semana" (todo dia, no caso), o que aponta direto pra uma tarefa agendada, não um loop.

Esse passo mostra a pergunta-guia sendo usada de verdade, não só como exemplo teórico — reforçando por que o loop (que expira em dias) seria a escolha errada aqui.

Aplicação da pergunta-guia, escolha justificada, tarefa agendada como gatilho certo.

Aplicando o módulo 6.5: a instrução da rotina precisa pedir um formato fixo de resultado (por exemplo, sempre 3 tópicos: agenda, pendências, um número específico) — não "me conta como está meu dia", que abre espaço demais pra variação.

Ver a instrução escrita com essa disciplina de formato é o exemplo prático mais completo de determinismo aplicado da trilha inteira.

Instrução com formato fixo, redução de variação, resultado consistente todo dia.

Aplicando o módulo 6.6: a rotina só tem permissão de leitura (nunca de apagar ou alterar nada), e o resultado chega por um canal fixo — e-mail ou mensagem — mais um registro em log pra você conferir quando quiser.

Fechar essa peça garante que a rotina matinal, mesmo rodando todo dia sem supervisão, continue segura e visível.

Canal de entrega diário, permissão de leitura apenas, log de acompanhamento.

Antes de ativar o agendamento de verdade, rode a instrução manualmente pelo menos duas vezes, em horários diferentes, e confira se o formato do resultado se manteve igual nas duas vezes.

Esse passo de teste é o que separa uma rotina matinal confiável de uma que vai te dar susto na primeira semana.

Teste manual repetido, verificação de consistência, ativação só depois da validação.

Depois de ativar, deixe a rotina rodar sozinha por sete dias sem mexer — mas marque um momento fixo (por exemplo, no domingo) pra abrir o log e conferir se tudo saiu como esperado, ajustando a instrução se algo precisar de correção.

Esse ritmo de "ativar, confiar, revisar uma vez por semana" é o comportamento saudável com automação que a trilha inteira ensinou — nem microgerenciar, nem esquecer que ela existe.

Confiança com checkpoint, revisão periódica, ajuste iterativo pós-ativação.