feat(episode): TRAZA_qu-pas-y-qu-cambi_S20260902.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 1 — MEMORIA: Qué pasó y qué cambió

episodes/TRAZA_qu-pas-y-qu-cambi_S20260902.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,40 @@
+---
+episode_id: "e498748d-cab5-4d3d-ba60-974ad514ad5d"
+puente_flat: "TRAZA_qu-pas-y-qu-cambi_S20260902.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260902.SID80EF6E909F98"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "NONE"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 1 — MEMORIA: Qué pasó y qué cambió"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-09-06T18:35:11.440791+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+Listo. Puedes volver a lanzar la rotación **con la misma clave** — es válida.
+
+## Qué pasó y qué cambió
+
+Tu ejecución falló por un permiso, no por la clave. El directorio `/home/johnember/stacks/litellm/` es de `root`, y mi escritura atómica necesitaba crear un fichero temporal ahí dentro. **Arreglando el truncamiento introduje una dependencia de un permiso que no tenemos** — la misma trampa que ya me había mordido con los respaldos en este mismo arco: verifiqué presencia, no capacidad.
+
+Lo bueno: **falló sin destruir nada**. `93 bytes / 1 variable` y `2068 bytes / 29 variables`, ambos intactos. El 3 y el 6 de septiembre este mismo paso dejaba el fichero en 0 bytes.
+
+Antes de escribir el tercer arreglo lo sometí a un panel de 8 agentes. Devolvió **37 defectos, 21 de severidad alta o crítica**, y los cuatro veredictos coincidieron en `NECESITA_CAMBIOS`. Los que más me preocupan, ya cerrados:
+
+| Defecto | Consecuencia real |
+|---|---|
+| Criterio de éxito **negativo** | Un contenedor caído devolvía cadena vacía, que tampoco empieza por el prefijo viejo → se leía como **rotación exitosa**, y el script llegaba a recomendarte **borrar una credencial viva** |
+| `open(p,"w")` aplica `O_TRUNC` | El `.env` de LiteLLM pasaría por **0 bytes en cada rotación** — y no como rama rara, sino como único camino posible |
+| La verificación vivía dentro del proceso que puede morir | No podía ver el fallo que justifica su existencia |
+| El `Ctrl+C` decía «no se cambió nada» | Mentía si la escritura ya había empezado |
+
+Ahora escribe **en sitio** con `O_RDWR` sin `O_TRUNC`: nunca vacía el fichero, no necesita permisos sobre el directorio y conserva inodo, permisos y dueño. La verificación es **positiva** (huella `sha256` contra la clave que teclees, no «ya no es la vieja»), hay una segunda conexión que comprueba el disco de forma independiente, y la restauración automática cuelga de **todas** las ramas de error.
+
+**Verificado, no declarado:** probé el escritor en el servidor MEMORIA contra ficheros de usar y tirar, incluido un directorio en modo `555` que reproduce exactamente la restricción que te falló → **7/7**: escribe pese al directorio cerrado, conserva inodo y permisos, nunca deja 0 bytes, detecta el «no sustituyó» y respeta todo-o-nada. Y el modo diagnóstico en vivo: `HTTP=200 · DIMS=3072`.
+
+## Un hallazgo nuevo que no te esperabas