El blog que no podía publicar según lo programado

Tengo cientos de borradores de blog triados y programados con meses de anticipación, y hasta esta semana el proceso solo podía publicar más o menos uno por sesión. Este issue debía resolver el problema de rendimiento con una skill por lotes. En gran parte lo logró, pero lo interesante es lo que encontré antes de escribir una sola línea de la skill: el blog era estructuralmente incapaz de publicar según un cronograma, y no lo sabía.

El error que no estaba en el plan

El diseño por lotes parecía sencillo: escribir las publicaciones con anticipación, con sus fechas de publicación programadas, hacer commit, y dejar que se publicaran en sus fechas. Antes de planificar sobre esa base, revisé cómo trata el sitio en realidad una publicación con fecha futura. La respuesta: no la trata de ninguna forma. Las rutas del blog se prerenderizan, y el código de generación de páginas filtra cualquier publicación cuya pubDate todavía no haya llegado. Una publicación con fecha futura no queda oculta, directamente nunca se construye. Da error 404.

Eso solo estaría bien si algo reconstruyera el sitio todos los días. Nada lo hacía. Los despliegues corren con git push y solo con git push. Entonces una publicación con commit hecho hoy y fecha para el próximo martes se queda en 404 después de ese martes, y el martes siguiente, hasta que algún push sin relación reconstruye el sitio por casualidad. Todo el modelo de escritura anticipada sobre el que estaba a punto de construir era un generador de 404. Ninguna cantidad de trabajo en la skill arregla eso, hacía falta infraestructura: un cron diario que activa los build hooks de ambos sitios para que las publicaciones en espera pasen a estar en vivo en sus fechas. Veinte líneas de YAML de workflow, y es la pieza que sostiene toda la función.

La lección que sigo reaprendiendo: verificar el sustrato antes de diseñar sobre él. Una verificación de cinco minutos del código de rutas invirtió toda la conversación de diseño, y pasó antes de que se aprobara el plan, no después de que se publicara la skill.

Letra chica que me alegra haber leído

Dos detalles del disparador de reconstrucción que vale la pena registrar. Los deploy hooks de Cloudflare solo se crean desde el dashboard, sin API, y la URL misma es la credencial, lo que los convierte en la opción de privilegio mínimo frente a guardar un token de API más amplio en los secrets del repo. Y las fechas de frontmatter que solo tienen fecha se interpretan como medianoche UTC, así que una reconstrucción al mediodía UTC hace que una publicación con fecha de martes salga en vivo a las 6am del martes hora local. Es razonamiento de zona horaria sobre una expresión de cron de dos líneas, pero decide si las publicaciones aparecen la mañana de su fecha o la noche anterior.

El proceso por lotes en sí

La skill despliega un agente de preparación por cada publicación: cada uno redacta a partir del material fuente del issue, corre las mismas verificaciones previas y la verificación de datos que usa el proceso de una sola publicación, elige candidatos de imagen destacada, y devuelve una tarjeta de estado. Después hay una sola revisión consolidada: todas las tarjetas en una vista única, y una sola respuesta publica el lote entero. La restricción de diseño que más me importaba era no debilitar ningún control, cada verificación que antes corría por publicación sigue corriendo por publicación, lo que cambió es que las decisiones se agruparon en lugar de llegar goteando a lo largo de sesiones separadas.

La prueba en seco validó la estructura y detectó dos cosas. Primero, la página de revisión se renderiza en un sandbox que bloquea imágenes remotas, así que las miniaturas destacadas aparecían solo como leyendas, ahora la skill las incorpora como data URIs. Segundo, y más satisfactorio: una de las dos publicaciones de prueba volvió marcada con una superposición importante. El agente de preparación notó que la historia que estaba redactando ya se había publicado, meses atrás, bajo un issue distinto. Eso es exactamente el tipo de decisión de criterio que la instancia de revisión existe para sacar a la luz, y se activó en el primer lote. Un proceso que solo demuestra casos ideales en su primera corrida en realidad no fue puesto a prueba.

Lo que sigue

La primera sesión real a fondo contra la cola real. Del lado de imperfectsystems.com todavía queda un cabo suelto: los PR ahí necesitan un merge manual hasta que llegue el auto-merge (registrado por separado), así que los primeros lotes serán solo de vdaluz.com.