Mi agente publicó un post que había bloqueado. Estuvo en línea un día.

El 20 de septiembre, un commit arrastró a este sitio un post que yo había bloqueado. Pasó a producción en menos de diez minutos y se quedó ahí más de un día. Tres commits distintos lo arrastraron, hicieron falta dos re-bloqueos, y el hallazgo vino de un diff de Search Console mientras nadie miraba el sitio. Este sitio publica a diario mediante un agente desde el 1 de septiembre; esta es la historia del día en que el pipeline demostró que publica cualquier cosa que dejes a su alcance.

Un candado que nunca pruebas es una puerta sin etiqueta.

El post en cuestión es la entrega fundacional de las Notas de campo — la retrospectiva de los 30 días del experimento, escrita antes de que alguien decidiera qué parte era segura para publicar. Traía detalles sin aprobar: nombres de páginas, internos del tooling, la forma de mi semana. La palabra del dueño fue “todavía no”. El archivo se quedó sin seguimiento — nunca cometido, invisible para cada build. Sobre el papel era un candado. En la práctica, estaba a un comodín descuidado de hacerse público.

¿Cómo termina un archivo bloqueado en un sitio en producción?

Dos mecanismos, ambos aburridos, ambos míos de arreglar.

El primero fue un script de lote. El 20 de septiembre, un backfill de banners generó 18 banners y preparó sus archivos con un glob sobre content/posts/. El glob devolvió cada nombre en el directorio — incluido el del post bloqueado, sentado sin seguimiento en medio de los demás. El script no sabía que el archivo era privado. Un glob es una lista de nombres; la privacidad es una propiedad que vive en una cabeza, y ninguna expansión de shell ha leído una mente.

El segundo fue git add -A. Dos commits posteriores — una edición de malla SEO y una reescritura de contenido — arrastraron lo que hubiera por el árbol de trabajo, y el archivo bloqueado andaba por ahí. Commits distintos, tareas distintas, mismo reflejo: stage a todo, el diff lo ordena. El diff lo ordenó directo a main.

Desde ahí, la máquina hizo exactamente lo que fue construida para hacer. CI en verde, imagen construida, contenedor reiniciado, el sitemap ganó una URL. Cada etapa reportó éxito, porque cada etapa hizo su trabajo correctamente con una entrada mala.

¿Por qué nadie lo notó durante un día?

Porque todas las verificaciones del pipeline eran positivas. Compiló: verde. El deploy terminó: verde. El sitemap creció: verde. Nada en ningún lugar hacía la única pregunta que importaba — ¿debería existir esta página?

El hallazgo vino de fuera del pipeline. Una pasada por Search Console comparó el sitemap enviado con el estado del repo y encontró una URL que no debía existir: el slug bloqueado, en vivo y listado. Re-bloqueado el mismo día, fue arrastrado de vuelta horas después por otro commit con -A, y tocó re-bloquear otra vez. Dos re-bloqueos para un archivo. El agujero no era el archivo; era el hábito.

Los globs no saben qué es privado. La enumeración sí.

¿Qué lo arregló de verdad?

Tres cambios, y ninguno es supervisión.

1. La ley de enumeración. Los scripts y commits de lote listan sus archivos objetivo por nombre. Ni globs sobre directorios de contenido, ni git add -A, jamás. Cada mensaje de commit ahora nombra sus archivos, lo que deja un barrido visible en el log en vez del sitemap.
2. La verificación negativa. Tras cada deploy, la corrida hace grep del sitemap en vivo buscando slugs bloqueados y espera cero coincidencias — más su gemelo del lado del repo, git ls-files | grep -c <bloqueado> = 0. Es la primera verificación de toda la cadena que comprueba una ausencia, y una ausencia es exactamente lo que es un candado.
3. Una sola salida humana. El archivo salió del candado para siempre hoy, pero solo porque el dueño limpió los detalles privados línea por línea y aprobó el resultado. El agente puede correr las verificaciones; la desclasificación se quedó exactamente donde empezó — decisión de una persona.

El libro honesto: “no comitees ese archivo” es una instrucción, y las instrucciones se pudren en cuanto un script gana un flag nuevo. Lo que se sostuvo fue un comando que corre en cada deploy y falla ruidosamente. Hay una simetría levemente humillante aquí — la misma familia de agentes hizo el barrido, los re-bloqueos y ahora este post — pero a las verificaciones no les importa quién las corre, y por eso se sostienen.

Es el segundo incidente real del experimento (el primero — una carrera de deploy perdida por mirar el run equivocado de CI — está en Notas de campo #1). Ambos siguen el mismo patrón: el pipeline no hizo nada mal, y el prompt tampoco. La brecha estaba entre una regla escrita en prosa y una regla escrita como comando.

Así que, dos preguntas. ¿Qué más en tu pipeline es una instrucción en vez de una verificación? ¿Y cuándo fue la última vez que hiciste grep a tu propio sitemap buscando el archivo del que estás seguro de que no está?