O blog que não conseguia publicar num cronograma

Eu tenho centenas de rascunhos de blog triados e agendados para meses à frente, e até essa semana meu pipeline só conseguia publicar cerca de um deles por sessão de trabalho. Essa tarefa deveria resolver o problema de throughput com uma skill em lote. Ela resolveu, na maior parte, mas a parte interessante é o que eu encontrei antes de escrever uma única linha da skill: meu blog era estruturalmente incapaz de publicar num cronograma, e eu não sabia disso.

O bug que não estava no plano

O design do lote parecia direto ao ponto: escrever posts com antecedência com suas datas de publicação agendadas, dar commit, e deixar que fossem ao ar nas próprias datas. Antes de planejar em cima disso, checei como o site realmente trata um post com data futura. A resposta: não trata. As rotas do blog são prerenderizadas, e o código de geração de página filtra qualquer post cujo pubDate ainda não chegou. Um post com data futura não fica escondido - ele nunca é construído. Ele vira 404.

Isso sozinho seria tranquilo se alguma coisa reconstruísse o site todo dia. Nada reconstruía. Deploys rodam em git push e só em git push. Então um post commitado hoje com a data da próxima terça continua sendo um 404 depois da terça, e da terça seguinte, até que algum push não relacionado por acaso reconstrua o site. Todo o modelo write-ahead que eu estava prestes a construir em cima era um gerador de 404. Nenhuma quantidade de skill resolve isso; precisava de infraestrutura: um cron diário que aciona os build hooks dos dois sites para que os posts programados virem ativos nas próprias datas. Vinte linhas de YAML de workflow, e é essa a peça que sustenta a feature inteira.

A lição que eu continuo reaprendendo: verificar a base antes de desenhar algo em cima dela. Uma checagem de cinco minutos no código de rotas inverteu toda a conversa de design, e isso aconteceu antes do plano ser aprovado, em vez de depois da skill ir ao ar.

Letras miúdas que eu fiquei feliz de ter lido

Dois detalhes do gatilho de rebuild que vale registrar. Os deploy hooks da Cloudflare só podem ser criados pelo dashboard - sem API - e a própria URL é a credencial, o que os torna a opção de privilégio mínimo comparado a deixar um API token mais amplo parado nos secrets do repositório. E datas de frontmatter só com a data, sem hora, são interpretadas como meia-noite UTC, então um rebuild ao meio-dia UTC significa que um post datado de terça vai ao ar às 6h de terça no meu horário. Raciocínio de fuso horário numa expressão de cron de duas linhas, mas é isso que decide se os posts aparecem de manhã na própria data ou na noite anterior.

O pipeline em lote em si

A skill distribui um prep agent por post: cada um redige a partir do material de origem da issue, roda as mesmas checagens de pre-flight e o fact-check que o pipeline de post único usa, escolhe candidatos a hero image, e devolve um card de prontidão. Depois, uma revisão consolidada: todos os cards numa única visão, e uma resposta lança o lote inteiro. A restrição de design que mais me importava era não enfraquecer nenhum gate - toda checagem que antes rodava por post continua rodando por post; o que mudou é que minhas decisões passaram a ser em lote em vez de espalhadas gota a gota em sessões separadas.

O dry run validou o formato e pegou duas coisas. Primeiro, a página de revisão renderiza numa sandbox que bloqueia imagens remotas, então as thumbnails de hero apareciam só como legendas - a skill agora as embute como data URIs. Segundo, e mais satisfatório: um dos dois posts de teste voltou sinalizado com uma sobreposição importante. O prep agent percebeu que a história que estava redigindo já tinha sido publicada, meses atrás, sob uma issue diferente. Esse é exatamente o tipo de julgamento que o gate de revisão existe para revelar, e ele disparou já no primeiro lote. Um pipeline que só demonstra caminhos felizes na primeira execução não foi realmente testado.

O que vem a seguir

Primeira sessão de verdade contra a fila real. O lado do imperfectsystems.com ainda tem uma ponta solta: PRs lá precisam de merge manual até o auto-merge entrar, registrado à parte, então os primeiros lotes vão ser só do vdaluz.com.