Cómo mantener un único FileId vivo sin perder historial

La aplicación necesita una referencia estable. Si el frontend conoce un FileId específico, crear un archivo nuevo cada día puede romper enlaces, permisos o cachés. El patrón más simple es mantener un único recurso vivo y reemplazar sus bytes. La identidad del archivo permanece; el contenido cambia. Esta separación permite que la app consuma siempre la misma URL sin descubrir diariamente dónde se publicó la edición.

Staging debe tener otra identidad fija. Un segundo FileId sirve para preparar mañana sin afectar producción. El sistema escribe allí, descarga y valida. Tener dos recursos estables evita confundir archivos temporales con destinos oficiales. Los nombres pueden ayudar a humanos, pero las automatizaciones deberían tratar los IDs como invariantes y fallar si reciben otro destino en lugar de improvisar una copia nueva.

Publica desde staging verificado. A medianoche descarga staging y usa esos bytes para actualizar el vivo fijo. Después vuelve a descargar vivo y compara. No uses un archivo local de una ejecución anterior, porque puede haber quedado obsoleto o provenir de otro run. La ruta staging descargado → vivo crea una cadena clara donde el artefacto promovido es exactamente el que pasó validación.

El histórico nace después del commit. Solo cuando vivo coincide con staging crea la copia histórica del día. Esa secuencia evita respaldar un artefacto que nunca llegó a producción. El backup debería llamarse latest-news-<runKey>.json, vivir en una carpeta por fecha y conservar el mismo hash. Si ya existe, se verifica en vez de duplicarse.

Los permisos deben preservarse. Actualizar el mismo archivo mantiene el modelo de acceso que ya usa la app. Crear otro vivo puede requerir volver a compartir, cambiar links o ajustar frontend. Esa es una razón adicional para tratar el FileId como configuración inmutable. Si una actualización falla, la recuperación debe arreglar la escritura, no sustituir la arquitectura creando otra identidad.

El backup resuelve la auditoría. Con copias diarias se puede reconstruir qué edición estuvo publicada, comparar cambios y recuperar una versión anterior si fuera necesario. El histórico no necesita ser la fuente activa del producto. Esta separación reduce riesgo: producción tiene un único punto estable y auditoría tiene una secuencia append-only de artefactos verificados.

Guarda hash y tamaño junto al correo. Incluir esos valores en la notificación de éxito facilita demostrar que vivo y backup correspondían al mismo contenido. Si más tarde alguien sospecha una modificación, puede volver a descargar y comparar. La trazabilidad no depende de recordar qué archivo se usó; la identidad y el hash forman una evidencia reproducible.

El patrón evita dos extremos. No hace falta elegir entre URL estable e historial. Un único FileId vivo resuelve estabilidad; copias posteriores resuelven memoria. La regla importante es el orden: preparar, verificar, promover, verificar, copiar. Cuando cada fase usa el recurso correcto, el sistema puede actualizar todos los días sin perder continuidad ni convertir Drive en una colección de archivos vivos competidores.

Añade una prueba de identidad antes de escribir. Antes de cualquier updatefile, compara el FileId recibido con el valor fijo configurado. Si no coincide, detén la mutación en lugar de crear una alternativa. Este guardrail evita que una recuperación bien intencionada termine publicando en un archivo nuevo que la aplicación nunca consulta. La estabilidad del identificador se protege mejor con una condición dura que con una instrucción recordada informalmente. Además, registra el ID observado en la evidencia de ejecución para que cualquier operador pueda comprobar que la mutación conservó la identidad esperada. Si una integración intenta redirigir la escritura, el run debe quedar incompleto y explicar esa divergencia sin cambiar el contrato de producción.