🛠️ Build: publicar uma automação agendada

Vamos publicar uma automação simples, mas real: todo dia às 8h da manhã, ela busca alguma informação (por exemplo, um resumo de notícias, ou o clima do dia, ou pedidos pendentes de um sistema) e te avisa — por e-mail, ou numa mensagem. O objetivo aqui não é a automação em si, é o processo inteiro de publicação, que vale pra qualquer automação futura sua.

Você não vai escrever código na mão. O Claude Code escreve; você lê o que ele propõe (lembra do modo plano, módulo 4.5?), aprova, testa e publica. O seu trabalho é orientar e revisar — exatamente como um gestor aprova o trabalho de um funcionário antes de ele sair pra rua.

Novo aqui? Trigger.dev é a plataforma de execução que este curso usa: você (ou melhor, o agente) escreve o código da task, entrega pra ela via repositório, e ela cuida de rodar, na hora certa, com retentativa e fila embutidas (módulo 4.5). Você não precisa saber como o Trigger.dev funciona por dentro — só precisa saber pedir a task certa e ler o que ela devolve.

Abra o terminal na pasta do seu projeto (módulo 0.3) e use o modo plano antes de pedir a task de verdade — assim você revisa o desenho (buscar separado de gravar, como no módulo 4.5) antes do código ser escrito.

Objetivo: pedir pro Claude Code criar uma task agendada que busca um dado simples e te avisa por e-mail, já seguindo as boas práticas dos módulos anteriores.

Quero uma automação agendada usando Trigger.dev, escrita em TypeScript.
Ela deve:
1. Rodar todo dia às 08:00 (horário de ).
2. Buscar  — essa etapa não grava nada, só lê.
3. Se a busca der certo, montar um e-mail resumido e enviar para
    — essa é uma etapa separada
   da busca, como aprendi no módulo 4.5.
4. Usar retentativa automática (3 tentativas) só na etapa de busca,
   já que repetir a busca é seguro.

Antes de escrever o código, me mostre o plano das tasks separadas e onde
ficam as variáveis de ambiente (chaves de API) que vou precisar cadastrar.

Como verificar: o Claude Code deve responder com um plano listando pelo menos 2 tasks (buscar e enviar), os nomes das variáveis de ambiente necessárias (sem valores reais) e o agendamento em formato de horário. Só depois disso você aprova a escrita do código.

Novo aqui? Dev (de "desenvolvimento") é o ambiente de teste — uma cópia da automação que roda separada da versão real que os usuários (ou você mesmo, no dia a dia) dependem, chamada de produção. É o assunto do módulo 4.3: dois "mundos" para você poder quebrar coisas sem medo no de teste.

Depois que o Claude Code terminar de escrever a task, rode-a localmente no modo de desenvolvimento do Trigger.dev, que executa a task na hora, sem esperar o horário agendado — assim você vê o resultado (ou o erro) em segundos, não no dia seguinte.

Objetivo: rodar a task manualmente em modo de desenvolvimento pra confirmar que ela funciona antes de publicar de verdade.

# dentro da pasta do projeto, com o CLI do Trigger.dev instalado
npx trigger.dev@latest dev

# noutro terminal, dispare a task manualmente (sem esperar o cron)
npx trigger.dev@latest test 

Como verificar: no terminal onde rodou dev, deve aparecer uma sequência de linhas mostrando a task iniciando, buscando o dado, e terminando com sucesso (normalmente em verde). Se aparecer em vermelho, é um erro — volte ao Claude Code, cole a mensagem de erro e peça pra ele investigar antes de seguir.

Novo aqui? Uma variável de ambiente é um valor secreto (uma chave de API, uma senha) que a automação usa mas que nunca fica escrito dentro do código — como o módulo 4.4 explicou, o arquivo local com esses valores nunca sobe pro repositório. Em vez disso, você digita esses valores manualmente no painel da plataforma.

Repare que você cadastra as chaves duas vezes: uma vez no ambiente de dev (só pra teste) e outra vez em produção — são caixas separadas. Isso evita que uma chave de teste (mais fraca, mais barata) acabe sendo usada sem querer no ambiente real.

Legenda: o arquivo local nunca vai pro repositório; você digita os mesmos nomes de chave, com valores diferentes, direto nos painéis de dev e de produção — cada ambiente com o seu conjunto isolado.

Novo aqui? Deploy é o ato de publicar: pegar o código que já testou em dev e colocá-lo rodando de fato em produção, disponível 24 horas por dia. Cron é a forma padrão de escrever "a que horas repetir" — um formato compacto tipo "todo dia às 8h" traduzido em símbolos, mas o Claude Code escreve isso pra você a partir do que você pedir em português.

O deploy leva o código do seu repositório até a plataforma, que passa a executá-lo sozinha, no agendamento definido — sem seu laptop precisar estar ligado (o assunto do módulo 4.1).

Objetivo: publicar a task testada em produção, depois de já ter cadastrado os segredos de produção no painel.

# confirma que está na branch principal e tudo commitado
git status

# envia o código pro repositório remoto (GitHub)
git push origin main

# publica a versão de produção na plataforma
npx trigger.dev@latest deploy --env production

Como verificar: o comando de deploy termina mostrando uma mensagem de sucesso com o nome da task publicada. Depois, abra o painel da plataforma (trigger.dev, na aba do seu projeto) e confirme que a task aparece listada como "ativa" com o agendamento correto (ex.: "todo dia às 08:00").

O deploy publicado não é o fim — é o começo de uma rotina de checagem. No dia seguinte (ou algumas horas depois, dependendo do horário agendado), volte ao painel (também chamado de dashboard — a tela onde a plataforma mostra tudo que rodou) e confirme que a execução apareceu, com status de sucesso.

Esse hábito de checar — sem precisar entender o código por trás — é exatamente o assunto do próximo módulo, o último desta trilha: ler o painel de execuções e, quando algo falhar, achar o motivo lendo o log, não o código.