🟣 Alojamiento y deploy

Scripts que se ejecutan en internet por su cuenta, según una agenda (cron) o activados por un evento (webhook), sin que haya una persona para iniciarlos o supervisarlos.

La automatización activada por una persona solo escala a la velocidad con la que alguien aparece para hacer clic; alojarla es el salto hacia la autonomía.

Local → alojado; cron vs webhook; Trigger.dev como motor; GitHub como almacenamiento.

La brecha que surge cuando la tarea se ejecuta sola: la IA ya no está ahí para leer el error y autocorregirse, así que el sistema se ejecuta, pero no se adapta.

En producción, un fallo puede pasar desapercibido; hay que cerrar la brecha con recursos de la plataforma y mejores prompts.

Fin del ciclo de autocuración; entradas fijas, salidas estructuradas; errores y registros integrados desde el inicio.

Un patrón de temporización de 5 campos (minuto, hora, día del mes, mes, día de la semana). Ejemplo: 0 7 * * * = 7h todos los días.

Es el lenguaje universal de programación de tareas; saber leerlo te permite controlar cuándo se activa la automatización.

Cinco campos; * = cualquiera; horario recurrente; la palabra clave "se ejecuta solo".

GitHub es almacenamiento de código en la nube: el deploy lo obtiene de allí (no de una máquina local), con historial de versiones para rollback y troubleshooting.

Es la única fuente del código que va a producción, accesible desde cualquier computadora.

Repositorio = carpeta del proyecto; commit (instantánea) y push (envío); repo privado + README.

La herramienta de línea de comandos (gh) autentica y conecta el proyecto local con el repositorio; .gitignore enumera lo que nunca debe subirse.

La regla de oro: el archivo .env con las claves NUNCA va a GitHub.

gh auth login; .gitignore automático; secretos fuera del control de versiones.

El motor de ejecución en la nube: sin timeouts, con retries automáticos, traces completos de cada paso, compatibilidad con agendas y webhooks, y alertas de fallas.

Es lo que hace que la automatización sea confiable: como un asistente firme, no como un recordatorio pegado en el refrigerador.

TypeScript (la IA lo escribe); MCP oficial; dashboard como ventana a producción.

Instalar el MCP de Trigger.dev, ejecutar el init (crea trigger.config.ts y la carpeta de tasks), inicia el worker de desarrollo y conoce la anatomía del dashboard.

Sin el proyecto inicializado y el worker en ejecución, las tareas no se registran ni se ejecutan.

Project ID; inicio interactivo; dev vs producción; runs, traces, payload y output.

Variables de entorno almacenadas en el dashboard de Trigger.dev e inyectadas en runtime, con un .env.example seguro para versionar.

Trigger.dev no lee el .env local; sin secrets en la nube, la tarea falla en producción.

Inyección en runtime; nunca pegues la clave en el chat; verifica dev e prod por separado.

Una tarea programada que se ejecuta cada mañana: cron se activa, Firecrawl investiga un tema fijo, la IA sintetiza y se escribe una fila en Google Sheets.

Es el build programado completo, desde el prompt hasta el deploy, que se ejecuta sin que nadie lo supervise.

Tarea no supervisada; tema hard-coded; archivo único; trigger de prueba en el dashboard.

La configuración única del refresh token de Google (OAuth); cuando falla el Playground ("access blocked"), la alternativa es un script en la terminal que imprime la URL y devuelve el token.

Sin el refresh token, la tarea no puede escribir en Sheets de forma autónoma.

Client ID + secret; refresh token; OAuth (no service account); .env + variables de entorno de la nube.

Un fallo real: la API devuelve un formato inesperado (resultados en web, no en data); copia el trace para que la IA diagnostique y corrija el parsing.

Algunos errores solo aparecen con datos reales en producción; saber leerlos y devolverlos a la IA es la habilidad central.

Formato de respuesta diferente; traza roja; redeploy + retrigger; error como insumo.

Una tarea activada por webhook: un payload JSON con campos (empresa, sector, meta, desafío) genera un informe .docx guardado en Google Drive.

Es el build activado por eventos, el complemento del programado, que se inicia cuando llegan datos.

Normalizar los campos del formulario; ID de carpeta opcional; prueba local antes del formulario.

Un webhook es una URL que escucha los datos entrantes y activa la tarea, pasando el payload —una "campanilla digital"—.

Sin autenticación, cualquiera puede ejecutar tu tarea; el header Authorization: Bearer protege el endpoint.

URL con el ID de la task; cuerpo JSON; Bearer + clave de API; URL para compartir.

Iterar en el editor envía el código a GitHub, que hace el deploy automático en Trigger.dev: los archivos más recientes siempre están disponibles.

Cierra el ciclo de iteración: haces cambios, haces push y la producción se actualiza sola.

Repository Secret (TRIGGER_ACCESS_TOKEN); GitHub Actions; commit → push → deploy.

Un enfoque por capas: logs significativos en cada paso, try/catch alrededor de cada llamada externa, retries con backoff y alertas por correo electrónico/Slack.

Sin autocorrección en producción, el manejo de errores es lo que cierra la brecha agéntica.

Registro específico (no «task failed»); reintentos para fallas transitorias, no errores de código; alertas configuradas.

El ciclo en producción: abrir el trace rojo en el dashboard, copiar el error, pegarlo en la IA y dejar que lo diagnostique, corrija y vuelva a hacer deploy.

La IA todavía depura, pero ya no lo hace sola: una persona tiene que llevarle el error.

Trace + IA = diagnóstico rápido; una persona como puente; iterar hasta que pase.