O problema
A operação dependia de rotina manual: abrir terminal, lembrar o comando certo, rodar o script de ronda de notícia, copiar o resultado, mandar pro grupo. E tudo isso só existia enquanto o Mac estava ligado. Precisava rodar sozinho, todo dia, sem operador.
A arquitetura: três peças que se conectam
Painel web como hub de comando. Um servidor local em Python puro (http.server da stdlib, sem framework, porta 8765, só acessível em 127.0.0.1) com uma interface de botões. Em vez de abrir terminal e lembrar comando, clico. O painel orquestra disparo de rondas, geração de copy, download de vídeo/áudio, lições extraídas de YouTube via Whisper, publicação no WordPress e histórico de execução lendo um log JSONL append-only.
A decisão central aqui é arquitetural: cada botão carrega uma camada de custo por complexidade de tarefa. Script puro (baixar vídeo, gerar redirect, rodar lint) não gasta um centavo de IA. Tarefa de linguagem leve — filtrar notícia relevante, resumo — roda em Gemini Flash ou Groq, ambos grátis. Groq substituiu o Gemini nas rondas sem tocar no resto do pipeline — troquei o motor mantendo a mesma assinatura de função.
VPS na Oracle Cloud como execução 24h. Os processos precisavam rodar com o Mac desligado, então hospedei de graça na Oracle em vez de pagar hospedagem ou depender de agendamento local como única via. Três crons rodam lá: ronda política às 06:30, digest consolidado às 08:00 e 14:30, e rondas de Tech&IA e Futebol&F1 às 09:00 — script separado porque o contexto de poda do CLI principal era hardcoded pra política e descartaria notícia de outro tema por engano. Deploy é turnkey: um script sobe código, chaves e os três crons de uma vez, pensado pra reconstruir a VM do zero se precisar.
Telegram como canal de entrega. WhatsApp foi descartado de propósito: a API oficial não manda mensagem espontânea fora de janela de 24h sem template aprovado, e a alternativa não-oficial arrisca banir o número usado na operação. Telegram resolveu sem os dois riscos. A camada de envio nunca levanta exceção — uma falha de notificação não pode derrubar o script que a chamou — e tem log próprio.
Duas decisões que sustentam o sistema em produção
Idempotência por data. O digest e as rondas gravam um arquivo-marcador (notify-digest-AAAA-MM-DD.done) antes de rodar. Se o cron disparar duas vezes no mesmo dia — reboot, retry — a segunda chamada não reenvia nada. Padrão clássico de “at-most-once” sem precisar de fila ou banco.
O bug de timezone que só aparece em produção. A VM nasce em UTC. Sem corrigir (timedatectl set-timezone America/Sao_Paulo), um cron marcado pra 08:30 dispara às 05:30 no horário de Brasília — sem erro nenhum, só o horário errado. É o tipo de coisa que nenhum teste local pega; só rodando de verdade.
O resultado
Três rondas por dia, digest consolidado e alerta de qualquer falha — tudo chegando no Telegram sem eu tocar em nada, rodando numa infraestrutura que custa zero. Quando um botão do painel dispara download de vídeo/áudio, se o arquivo cabe no limite do Telegram ele sobe direto; se não cabe, manda só o aviso com o caminho — compressão automática ficou documentada como próximo passo, não como problema resolvido antes da hora.
Como eu trabalho nisso
Especifiquei e dirigi a arquitetura inteira via Claude Code — as camadas de custo, a escolha Telegram em vez de WhatsApp, o padrão de idempotência — revisando e validando cada decisão. E tenho posse real sobre a configuração de infraestrutura: Oracle Cloud, timezone, cron, Cloudflare/DNS. Não escrevi o Python à mão; sei exatamente por que cada peça existe e sei operar o que está no ar.