Estudo de Caso 3: Um Utilitário Pessoal de Automação

A ideia

Um puramente egoísta: um script que toda manhã pega os eventos da agenda do dia e o clima, monta um resumo de uma linha, e manda para um chat pessoal no Telegram. O objetivo era parar de abrir três apps antes do café.

A especificação

A scheduled job that runs at 7am my timezone. It reads today's
events from my calendar, fetches the forecast for my city, and
sends one Telegram message like: "3 events today, first at 9:30.
High 24C, rain after 4pm." If any source fails, still send what
you have and note what's missing.

Aquela última frase — degradar graciosamente em vez de quebrar — é o tipo de comportamento que você tem que pedir explicitamente. A IA não vai assumir isso sozinha. Se não for dito, o padrão que um modelo escolhe é "lançar erro", o que para um job de cron às 7h significa uma manhã silenciosa e nenhuma pista do motivo.

A stack

Uma única função serverless agendada (um Worker acionado por Cron) para que não haja máquina nenhuma para manter rodando. A coisa inteira é um arquivo mais um agendamento. Para um utilitário pessoal isso importa mais do que parece: qualquer coisa com um servidor para cuidar é algo que você eventualmente vai esquecer de pagar, e o projeto morre por negligência em vez de por falha.

Um gatilho se ramifica em duas fontes e converge de volta em uma mensagem. O try/catch ao redor de cada fonte é o que permite que uma única falha degrade graciosamente em vez de matar toda a execução:

                    ┌─────────────────┐
  7am cron ───────▶ │  WORKER         │
                    │                 │   try ┌──────────────┐
                    │  fetch sources ─┼──────▶│ WEATHER API  │
                    │  (each in       │       └──────────────┘
                    │   try/catch)    │   try ┌──────────────┐
                    │                 ┼──────▶│ CALENDAR API │
                    │  build summary  │       └──────────────┘
                    │       │         │
                    └───────┼─────────┘
                            ▼
                    ┌─────────────────┐
                    │  TELEGRAM BOT   │  "3 events today… High 24C"
                    └─────────────────┘
   one source fails → send what you have, note what's missing

Os prompts principais

Write a Cloudflare Worker triggered by cron at 7am Asia/Seoul.
It calls a weather API and a calendar API (I'll provide both
tokens as secrets), builds a one-line summary, and POSTs it to
the Telegram Bot API. Wrap each external call in try/catch so one
failure doesn't kill the message. Read every token from env.

Quando quisemos iterar no texto sem esperar até as 7h:

Add a manual trigger: if the Worker is hit with a GET request and
a ?test=1 query param, run the same logic immediately and return
the message text in the response instead of sending it. Keep this
behind a secret token so only I can trigger it.

Esse gatilho de teste nos salvou de um ciclo de feedback brutal — podíamos ver o resultado sob demanda em vez de uma vez por dia. É um movimento genérico que vale a pena roubar: sempre que seu código roda em um agendamento, construa para si mesmo um jeito de rodá-lo agora, sob demanda, antes de se comprometer a esperar pelo relógio.

O obstáculo

A mensagem do Telegram chegava, mas os horários estavam errados: os eventos apareciam em UTC, não no horário da Coreia. O clima estava certo. Isolamos o problema:

Calendar times are 9 hours off — showing UTC, not Asia/Seoul.
The weather time ("rain after 4pm") is correct. Here's how I
format both: [pasted]. Fix only the calendar formatting and tell
me why the weather path was already right.

A IA explicou que a API do clima (Application Programming Interface — a porta que um serviço expõe para que outro programa busque seus dados) já retornava strings localizadas, enquanto a API do calendário retornava carimbos de data/hora em UTC que estávamos imprimindo crus. Ela adicionou uma única conversão de fuso horário na etapa de formatação do calendário. Restringir o conserto a "apenas o caminho do calendário" impediu que ela reescrevesse o código do clima que já funcionava — um jeito comum de conserto de IA quebrar coisas que estavam boas. A segunda metade daquele prompt — "tell me why the weather path was already right" — fez dupla função: nos deu a causa raiz real em vez de um chute, e forçou a IA a articular a diferença para que seu conserto não "harmonizasse" acidentalmente os dois caminhos em um só, quebrado.

O lançamento

"Lançamento" aqui só significou implantar o Worker, definir o agendamento de cron, e adicionar os tokens de API como segredos criptografados. Batemos no endpoint ?test=1 algumas vezes para confirmar que a mensagem lia bem, e então deixamos correr. Está rodando toda manhã desde então — e a linha de degradação graciosa provou seu valor um mês depois, quando a API do clima teve uma queda e a mensagem ainda assim chegou, só sem a previsão.