0067 — The Supervisor is deleted

Why

The Supervisor was switched off at 2026-10-18 01:35:46Z after a late-boot kill loop (fixed in #405, recorded in ADR-0066). Gera then decided it should not come back as a running service. Sessions stay up on their own now, a daemon that polls every minute is a standing cost, and the code is still in git if it is ever wanted. The Driver stays.

So this removes the code instead of leaving a disabled service and a build on disk that someone could start by accident.

What was deleted

What the relay now refuses, and why

Each of these routes used to write one request file under ~/.claude/jobs/ and answer ok: true. The Supervisor was the only thing that read those files. If the routes kept writing them, they would keep reporting success for work that will never happen. So each one now answers 410 Gone with a plain sentence saying what stopped and what to do instead (relay/src/retired.ts), and writes nothing:

Route What it did What it says now
POST /api/intake filed a job; the Supervisor minted a Driver for it filed jobs are no longer started; start the work from a Claude session
POST /api/adopt filed a job for a session that already existed; the Supervisor minted only its Driver nothing assigns a Driver to an existing session; start one from inside that session
POST /api/preview/dev asked the Supervisor to start or stop a worktree's dev server previews are no longer started or stopped from the page
POST /api/audit asked the Supervisor to run a headless deep check deep checks are no longer run from the page; run the agent-audit skill in a session

The routes stay registered rather than returning 404, because a 404 looks like a typo or an outage and doesn't say why. relay/tests/routeEnumeration.test.ts lists them apart from the real write routes, and relay/tests/retired.test.ts calls each one over HTTP and checks the 410 response and that nothing was written.

One more relay behaviour changed. A Supervisor alarm tied to a condition (a ledger row carrying supervisor_alarm_condition, such as dock-frozen or task-repo-unusable) used to be acknowledged by a click on /agents and left open. The Supervisor would close it once the condition ended. Nothing re-checks a condition now, so an acknowledged row would stay open forever. A click now resolves it like any other block (relay/src/blocks/resolve.ts). On 2026-10-18 the mini's ledger held 5 open sup-* rows (2 of them condition-backed). They can be answered on /agents to clear them.

The relay keeps reading what the Supervisor used to write, because those files are still on disk and other things still write to them: task.json and task events (Drivers write them), the block ledger including old agentflow-supervisor rows, compaction markers (the context-budget hook writes them), the red-main claim file (now normally absent, so it reads "nobody holds it"), past deep-check results, and the last dev-server state.

What keeps working

What is gone for good

Where the code is

Nothing is lost. The last commit on main that contains supervisor/ is d77b030, the merge of #406, which is this PR's base. If another PR touching supervisor/ merges first, it is the parent of this PR's merge commit instead. git show d77b030:supervisor/src/index.ts reads it, and git log -- supervisor/ has its full history.

On the mini, supervisor/dist/ and supervisor/node_modules/ are gitignored, so they stay on disk when the deploy checkout moves past this PR. They are safe to delete. start-operator --adopt reads CRITERION_UNSET from supervisor/dist/tasks.js, but it has a built-in fallback for when that file is missing. The launchd label is still disabled, and on 2026-10-18 the plist was no longer in ~/Library/LaunchAgents.

Bringing it back

  1. Revert this PR. That restores supervisor/, its CI and deploy steps, the relay's four write routes, and the condition-backed alarm rule together. Don't restore only part of it: the relay would then accept work nothing does, or a Supervisor would re-raise alarms the relay had closed.
  2. Follow ADR-0066's "Turning it back on" order. Build before you bootstrap, prove the new build is the one on disk, then launchctl enable and bootstrap. If the plist is not in ~/Library/LaunchAgents, copy it there first from supervisor/deploy-com.propflow.agentflow-supervisor.plist.
  3. Put the supervisor loaded signal back on the agentflow entry in SYSTEMS.md, mark the red-main entry active again, and write an ADR that supersedes this one.

Options not taken