Agendar execução não é o mesmo que ter um editor autônomo
“Pega o Markdown original, corrige e publica.”
Parece simples.
Até você tentar automatizar.
É preciso ler o Markdown, decidir se está pronto, conferir 12 idiomas, remover títulos estranhos, validar links, publicar, abrir a página real, voltar se der erro, descobrir a causa, corrigir, rodar de novo e confirmar que a correção não quebrou outra coisa.
De repente, a esteira também virou editora-chefe.
O problema não é que Cloudflare Workers, tarefas agendadas ou GitHub Actions sejam ruins.
Eles foram feitos para outro tipo de trabalho.
Automação tradicional é ótima para repetir procedimentos conhecidos. Uma fábrica de conteúdo recebe textos diferentes e problemas diferentes. Muitas vezes alguém — ou algum agente — precisa ler, interpretar, corrigir e verificar.
Isso é mais um problema de agente do que de cron.
1. A mesma esteira não significa o mesmo trabalho
Uma fábrica de artigos parece produção em massa.
Entrada: Markdown. Saída: artigo publicado.
Então parece natural repetir o mesmo processo cem vezes.
Só que texto não é parafuso padronizado.
O artigo A tem um título ruim. O B perdeu um dos 12 idiomas. O C foi traduzido, mas usa termos que ninguém daquele mercado pesquisaria. O D publicou uma nota interna de SEO no corpo. O E tem um link de afiliado válido, porém colocado num lugar editorialmente sem sentido. O F foi publicado, mas o registro ainda diz “em execução”.
Tudo aconteceu dentro da mesma etapa de publicação.
Mas cada problema pede um conserto diferente.
Se a entrada muda sempre, o formato da falha também muda.
2. Agendadores são ótimos para executar trabalho conhecido
GitHub Actions executa fluxos pré-definidos quando ocorre um evento, quando alguém dispara manualmente ou em um horário programado.[1]
ChatGPT Scheduled Tasks também executa tarefas em horários escolhidos ou em eventos compatíveis.[2]
Cloudflare Workers é excelente para requisições, execuções periódicas e integração entre serviços.
Esses sistemas respondem muito bem a:
“Quando roda?” “Qual script executa?” “O comando terminou com sucesso?” “Se esta condição for verdadeira, qual é o próximo passo?”
Mas não é a mesma coisa que perguntar:
“Esse título parece tradução automática?” “Essa seção está correta, mas ajuda o leitor?” “O link funciona, mas por que está aqui?” “O erro de hoje é realmente igual ao de ontem?”
Um agendador tem relógio.
Ele não recebe intuição editorial de brinde.
3. A parte difícil é fechar o ciclo inteiro de melhoria
O problema não é apenas fazer uma alteração.
É completar o ciclo:
detectar a falha, diagnosticar a causa, corrigir, executar novamente, verificar o resultado real, procurar efeitos colaterais, e testar outra hipótese se a primeira estiver errada.
Uma pessoa faz isso quase automaticamente.
Num sistema, cada transição precisa existir de forma explícita.
E os piores casos são os “meio sucessos”.
A página foi publicada, mas o status não mudou.
A tradução terminou, mas um idioma ficou vazio.
O repositório foi atualizado, mas o site em produção não.
Se você simplesmente repetir tudo, pode duplicar publicação ou trabalho.
Por isso a meta de uma automação resistente não é só “nunca falhar”.
É:
poder repetir sem estragar o resultado final.
Cloudflare Workflows oferece passos duráveis, persistência de resultados e novas tentativas, e sua documentação recomenda operações seguras quando executadas mais de uma vez.[3][4]
4. Cloudflare é bom em recuperação, mas recuperação não é julgamento editorial
Cloudflare Workflows pode manter o estado de processos com vários passos, repetir somente etapas que falharam e continuar a partir de partes já concluídas.[3]
Cloudflare Queues pode repetir entregas e mandar mensagens que falham várias vezes para uma Dead Letter Queue.[5]
Isso resolve muito bem:
erro temporário de rede, falha de API, timeout, mensagem que falha repetidamente, processo que precisa continuar mais tarde.
Mas existe outro tipo de problema:
“O espanhol dá para entender, mas ninguém busca assim.”
“O texto está certo, mas este subtítulo piora a leitura.”
Aumentar o número de tentativas de três para dez não cria julgamento editorial.
Só pode repetir o mesmo erro dez vezes com uma eficiência admirável.
Repetir não é raciocinar.
5. GitHub Actions é uma ótima bancada de trabalho, não um editor autônomo
GitHub Actions é excelente para tarefas determinísticas.
Rodar testes. Validar arquivos. Fazer build. Publicar quando condições claras forem atendidas. Executar scripts periodicamente.
Esse é o território dele.[1]
Mas Actions não lê um artigo e conclui:
“O problema real está na introdução, não no título.”
Dá para chamar uma IA dentro de um workflow.
Só que aí o problema difícil muda de lugar.
Passa a ser:
que contexto mostrar, o que a IA pode alterar, como confirmar o resultado, e como retomar quando algo falhar.
É meio injusto entregar a pauta da reunião editorial para uma furadeira e depois reclamar que ela não moderou o debate.
6. Melhor separar caminho normal e exceções do que perseguir 100% de automação
Uma fábrica prática precisa de duas rotas.
Caminho normal: automatize o que é objetivo
A máquina consegue conferir:
- arquivos obrigatórios
- 12 idiomas presentes
- campos não vazios
- formato de URL
- IDs únicos
- comando de publicação bem-sucedido
- página final acessível
Workers, scripts e Actions são ótimos nisso.
Caminho de exceção: isole o problema e continue
Um artigo ruim não deveria parar o lote inteiro.
Registre o motivo. Tire aquele item da fila principal. Continue com o próximo.
Categorias úteis:
- idioma ausente
- estrutura inválida
- erro de link
- erro de publicação
- revisão semântica necessária
- causa desconhecida
Se 90 de 100 passam automaticamente, publique os 90.
Não precisa deixar 90 artigos saudáveis de castigo porque dez ficaram esquisitos.
Pule a exceção e continue.
7. Entregue as exceções a um agente que consiga ler o repositório
Exceções costumam exigir leitura, raciocínio, edição e verificação.
É aí que um agente de programação faz sentido.
A documentação do Codex Cloud descreve tarefas em um ambiente preparado onde é possível investigar bugs, alterar código, executar testes e continuar a mesma tarefa em dispositivos compatíveis.[6]
Na fábrica de conteúdo, ele pode funcionar como oficina:
pegar o artigo com falha, ler o Markdown original, examinar a saída, ler o registro de erro, ver código se for necessário, corrigir, rodar verificações, publicar novamente, e conferir a página real.
Não faz sentido gastar raciocínio avançado com todos os casos normais.
Deixe a máquina cuidar do repetitivo.
Use o agente para o estranho.
8. Quando uma exceção vira comum, transforme-a em regra automática
A fila de exceções também não pode virar depósito permanente.
Se o mesmo erro aparece muitas vezes, ele deixou de ser exceção. Virou padrão.
Se um idioma vive faltando, crie uma verificação automática.
Se um mesmo subtítulo indesejado aparece sempre, bloqueie-o.
Se a publicação funciona mas a atualização de status falha, primeiro confira o site e depois repare o estado automaticamente.
A ordem mais saudável é:
colocar a fábrica para rodar, coletar falhas reais, usar agentes nos casos raros, detectar padrões, automatizar apenas os padrões recorrentes.
Tentar prever todos os problemas antes de publicar é uma ótima forma de construir a fábrica para sempre e nunca produzir nada.
Conclusão: o agendador é a esteira; o agente é a oficina
Cloudflare, tarefas agendadas e GitHub Actions parecem frustrantes quando esperamos que funcionem como editores autônomos.
Mas são papéis diferentes.
O sistema agendado deve:
iniciar, fazer verificações objetivas, empurrar casos normais, isolar falhas, manter a linha andando.
O agente deve responder:
“Por que este artigo ficou estranho?” “O que precisa mudar?” “A correção realmente funcionou?”
A arquitetura útil é simples:
Automatize o caminho fácil. Não deixe uma exceção bloquear o lote. Mande as exceções para o agente. Transforme erros repetidos em regras automáticas depois.
A fábrica não precisava de uma esteira capaz de pensar sobre tudo.
Precisava de uma esteira que não parasse e de uma oficina inteligente para as caixas que saíssem da linha.
- GitHub Docs, Workflows docs.github.com
- OpenAI Help Center, Scheduled tasks in ChatGPT help.openai.com
- Cloudflare Docs, Build your first Workflow developers.cloudflare.com
- Cloudflare Docs, Rules of Workflows developers.cloudflare.com
- Cloudflare Docs, Dead Letter Queues developers.cloudflare.com
- OpenAI Help Center, Using Codex Cloud help.openai.com
