The wind-down playbook — what survives August 15Concept

Fourteen days out, the question flips from "what should I build" to "what survives me going back to work." Today's playbook: the keep/kill/mothball triage for your 26 LaunchAgents, using the Jul 21 languages decommission as the template for a clean kill.

A LaunchAgent is a standing promise: macOS will keep running this job on your behalf, forever, until you say otherwise. During the sabbatical that was free — you were here every day, so a silent failure got noticed within a morning or two. The moment consulting starts, that ambient supervision disappears, and every agent moves into one of three honest buckets. KEEP: it delivers value without you watching, and it has a witness — a failure path that files a 🚨 Things task or otherwise reaches you (your own automation-hygiene rule: verify the side-effect, not the trigger). KILL: it served a sabbatical-only purpose (a calibration window, a one-off watch) and its time is over. MOTHBALL: it might matter later, so you unload it but keep the plist and scripts in git — five minutes from revival, zero risk while dormant.

The failure mode is the un-decision: leaving all 26 loaded because deciding is work. That default is the worst bucket. An unwatched agent that half-works is worse than no agent — it burns cycles, files nothing when it breaks, and quietly corrupts the state files other jobs read. Your alert wall this summer was mostly this: jobs that failed, filed a task, and then kept failing after the task scrolled out of view. The triage test for each agent is one question: if this broke on a Tuesday in October, would I find out before November? If no witness exists and you still want to keep it, building the witness IS the remaining sabbatical work.

You already ran the template once. On Jul 21 the daily language lesson was decommissioned cleanly: unload the LaunchAgent, retire the sender, clean the output repo, one commit per layer — so git history reads as a sequence of deliberate removals, not one opaque "cleanup" blob. That commit sequence is the playbook. A clean kill is reversible by construction: every layer is in history, so mothball and kill differ only in whether you archive the plist or delete it.

Worked example

The full triage is three commands — inventory, health, and (per kill) the two-step clean retirement.

# 1. Inventory: every standing promise on disk
ls ~/Library/LaunchAgents | grep -E 'zorc|tom'        # 26 today

# 2. Health: column 2 is the last exit code — non-zero = failing NOW
launchctl list | grep -E 'zorc|tom\.'
#   - 1 app.zorc.hue-monitor        <- exiting 1, no 🚨 filed
#   - 1 app.zorc.plant-water-lights <- exiting 1, no 🚨 filed

# 3. Per kill/mothball: unload, then archive the plist (one commit per layer)
launchctl bootout gui/$(id -u)/app.zorc.gstack-calibration-week2
mkdir -p ~/Claude/PDB/launchagents/_retired
mv ~/Library/LaunchAgents/app.zorc.gstack-calibration-week2.plist \
   ~/Claude/PDB/launchagents/_retired/

• Inventory reads what exists; loaded state can differ from disk, which is why you check both.
• In `launchctl list`, the second column is the job's last exit status. `0` means the last run finished cleanly; anything else means it is failing right now — and if no 🚨 task exists for it, it has no witness.
• `bootout` is the modern unload — the agent stops firing immediately but nothing is deleted. Moving the plist into a git-tracked `_retired/` folder is what turns a kill into a mothball: the diff records exactly what was retired and when, and revival is `mv` + `bootstrap`.

Gotchas

• Exit code 0 in `launchctl list` proves the process exited cleanly, not that the work happened — the two RemoteTrigger silent failures in May both reported success. The witness has to check the side-effect (the commit, the file, the Things task), not the exit code.
• Don't delete plists outside git. The `_retired/` archive folder inside the PDB repo is the difference between a mothball you can revive in five minutes and a kill you have to reconstruct from memory.
• A `-` in the PID column just means the job isn't running this second (normal for interval jobs) — it is NOT a health signal. Only the exit-status column tells you about failure.