La continuidad editorial empieza comprobando qué día está realmente en vivo

El calendario no es el producto. Una tarea puede figurar en el scheduler con la hora correcta y seguir sin producir noticias para el lector. La continuidad empieza leyendo el destino que consume la aplicación y comparando su feedDate con la fecha local. Si no coinciden, existe un hueco real aunque el sistema tenga tarjetas, logs o configuraciones aparentemente sanas. Esa comprobación debe ocurrir antes de investigar mañana, porque preparar el futuro mientras hoy sigue vacío solo acumula deuda editorial.

La fecha viva funciona como una señal de salud. Para un feed diario, una prueba simple responde mucho: ¿qué fecha tiene el archivo vivo?, ¿cuántos items contiene?, ¿sus IDs pertenecen al run esperado? Si la respuesta no coincide con el día actual, el sistema necesita entrar en recuperación. Esta regla evita depender de estados narrativos como “corrió” o “se intentó”. La operación se vuelve binaria y observable desde el mismo recurso que utiliza el producto.

Recuperar hoy tiene prioridad sobre preparar mañana. Cuando hay atraso, el orden correcto es cerrar el día actual primero. De lo contrario staging puede avanzar mientras vivo permanece congelado, y cada medianoche añade otra ambigüedad sobre qué edición debería promoverse. Un workflow robusto calcula la fecha objetivo desde la hora local, identifica el primer hueco pendiente y lo cierra con contenido verificado antes de continuar. La continuidad es secuencial porque el lector percibe días, no intentos.

La evidencia debe vivir fuera del scheduler. Después de publicar, hay que descargar el archivo vivo y comprobar fecha, cantidad, IDs y hash. Esa lectura posterior es la evidencia de que la mutación llegó al destino correcto. Un success:true de la escritura describe una llamada, no necesariamente el estado final. El principio parece pequeño, pero elimina una clase de falsos positivos que pueden dejar una aplicación mostrando información vieja durante días mientras las automatizaciones creen que terminaron.

Staging y vivo cumplen papeles diferentes. Staging permite preparar y verificar la edición siguiente sin cambiar lo que ve el usuario. Vivo representa lo que el producto entrega ahora. Esa separación funciona solo si ambos estados se comparan explícitamente: staging debe tener mañana y vivo debe tener hoy. Cuando la misma fecha aparece en ambos durante demasiado tiempo, o staging queda detrás de vivo, el sistema ya dispone de una señal clara para diagnosticar dónde se rompió la cadena.

El correo debe ser consecuencia y no esperanza. Una notificación de éxito solo tiene valor si se envía después de verificar vivo y backup. Mandarla antes convierte el correo en otra fuente de confusión, porque puede afirmar que una edición existe cuando el destino todavía no cambió. El mensaje final debería incluir runKey, fecha, tamaño y hash precisamente para que alguien pueda contrastar la afirmación con el archivo. La comunicación correcta nace de evidencia técnica ya cerrada.

Un health check puede mantener la regla simple. No hace falta un sistema de estados enorme para saber si NewsDesk está sano. Comparar hora local, fecha viva, fecha staging y existencia del correo del día cubre gran parte del problema. Si vivo está atrasado, recuperar; si staging está atrasado después del mediodía, preparar; si vivo está correcto pero falta correo, completar únicamente correo. Esa lógica reduce decisiones y hace que cada reparación tenga un objetivo concreto.

Continuidad significa no perder el orden de los días. La meta no es que una automatización nunca tenga errores, sino que un error no convierta un hueco en una cadena de días faltantes. Leer primero el destino, recuperar el día actual y solo después preparar el siguiente crea una disciplina que puede sobrevivir a fallos de conectores o scheduler. El feed deja de depender de que todo salga perfecto y empieza a depender de una regla sencilla: el día visible debe poder demostrarse antes de avanzar.