🛠️ Build: publicar una automatización programada

Vamos a publicar una automatización sencilla, pero real: todos los días a las 8 de la mañana, busca alguna información (por ejemplo, un resumen de noticias, el clima del día o pedidos pendientes de un sistema) y te avisa — por correo electrónico o con un mensaje. El objetivo aquí no es la automatización en sí, sino todo el proceso de publicación, que sirve para cualquier automatización futura tuya.

No vas a escribir código a mano. Claude Code lo escribe; tú lees lo que propone (¿recuerdas el modo plan, módulo 4.5?), apruebas, pruebas y publicas. Tu trabajo es orientar y revisar, exactamente como un gerente aprueba el trabajo de un empleado antes de que salga a la calle.

¿Eres nuevo aquí? Trigger.dev es la plataforma de ejecución que usa este curso: tú (o, mejor dicho, el agente) escribes el código de la task, se lo entregas mediante un repositorio y la plataforma se encarga de ejecutarla en el momento adecuado, con reintentos y una cola integrados (módulo 4.5). No necesitas saber cómo funciona Trigger.dev por dentro; solo tienes que saber pedir la task adecuada y leer lo que devuelve.

Abre la terminal en la carpeta de tu proyecto (módulo 0.3) y usa el modo de planificación antes de pedir la task de verdad: así revisas el diseño (buscar por separado de guardar, como en el módulo 4.5) antes de que se escriba el código.

Objetivo: pedirle a Claude Code que cree una tarea programada que busque un dato sencillo y te avise por correo electrónico, siguiendo ya las buenas prácticas de los 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.

Cómo verificar: Claude Code debe responder con un plan que enumere al menos 2 tareas (buscar y enviar), los nombres de las variables de entorno necesarias (sin valores reales) y la programación en formato de horario. Solo después de eso apruebas la escritura del código.

¿Eres nuevo aquí? Dev (de «desarrollo») es el entorno de prueba: una copia de la automatización que se ejecuta por separado de la versión real de la que dependen los usuarios (o tú en el día a día), llamada producción. Es el tema del módulo 4.3: dos «mundos» para que puedas romper cosas sin miedo en el de prueba.

Después de que Claude Code termine de escribir la task, ejecútala localmente en el modo de desarrollo de Trigger.dev, que ejecuta la task de inmediato, sin esperar la hora programada; así ves el resultado (o el error) en segundos, no al día siguiente.

Objetivo: ejecutar la tarea manualmente en modo de desarrollo para confirmar que funciona antes de publicarla de verdad.

# 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 

Cómo verificar: en la terminal donde se ejecutó dev, debería aparecer una secuencia de líneas que muestre la tarea iniciándose, buscando el dato y terminando con éxito (normalmente en verde). Si aparece en rojo, hay un error: vuelve a Claude Code, pega el mensaje de error y pídele que lo investigue antes de seguir.

¿Eres nuevo aquí? Una variable de entorno es un valor secreto (una clave de API, una contraseña) que la automatización usa, pero que nunca queda escrito dentro del código. Como explicó el módulo 4.4, el archivo local con esos valores nunca se sube al repositorio. En su lugar, escribes esos valores manualmente en el panel de la plataforma.

Observa que registras las claves dos veces: una vez en el entorno de desarrollo (solo para pruebas) y otra en producción — son espacios separados. Así se evita que una clave de prueba (más débil y más barata) termine usándose por accidente en el entorno real.

Leyenda: el archivo local nunca va al repositorio; escribes los mismos nombres de clave, con valores diferentes, directamente en los paneles de desarrollo y de producción: cada entorno con su propio conjunto aislado.

¿Eres nuevo aquí? Deploy es el acto de publicar: tomar el código que ya probaste en dev y ponerlo a funcionar de verdad en producción, disponible las 24 horas del día. Cron es la forma estándar de escribir «a qué hora repetir»: un formato compacto como «todos los días a las 8 h», traducido en símbolos, que Claude Code escribe por ti a partir de lo que le pidas en portugués.

El deploy lleva el código de tu repositorio a la plataforma, que pasa a ejecutarlo por su cuenta, según el horario definido, sin que tu laptop tenga que estar encendida (el tema del módulo 4.1).

Objetivo: publicar en producción la tarea probada, después de registrar los secretos de producción en el panel.

# 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

Cómo verificar: el comando de deploy termina mostrando un mensaje de éxito con el nombre de la task publicada. Después, abre el panel de la plataforma (trigger.dev, en la pestaña de tu proyecto) y confirma que la task aparece en la lista como «activa» con la programación correcta (p. ej., «todos los días a las 08:00»).

El deploy publicado no es el final: es el comienzo de una rutina de verificación. Al día siguiente (o algunas horas después, según el horario programado), vuelve al panel (también llamado de dashboard — la pantalla donde la plataforma muestra todo lo que se ejecutó) y confirma que la ejecución aparezca con estado de éxito.

Este hábito de revisar — sin necesidad de entender el código que hay detrás — es exactamente el tema del próximo módulo, el último de esta trilha: leer el panel de ejecuciones y, cuando algo falle, encontrar el motivo leyendo el log, no el código.