afx cleanup cannot remove an orphaned builder worktree, so orphans accumulate forever

[pseudoseed]

Problem. A worktree under .builders/ whose global.db row is gone can be seen by every surface and removed by none.

Measured in codev-1455, 13 of them:

air-14  air-22  air-78  bugfix-1455  experiment-39  experiment-62
experiment-63  experiment-74  experiment-77  pir-12  pir-2  pir-4  spir-52

• afx cleanup -p 78 → Builder not found for project: 78. Same for 62, 63, 74, 77.
• git worktree remove is forbidden by CLAUDE.md's irreversible-acts rule: "Never destroy builder worktrees."
• So there is no documented path that removes them, and nothing prunes them on its own.

Why they are visible. discoverBuilders finds worktrees Tower has no row for — deliberate, and useful for recovery. GET /v2/events therefore reports all 13 as builders with status: offline, parented to the workspace because a row-less worktree has no spawnedByArchitect.

That is honest — the directories are on disk. It is also permanent. The v2 site view will show 13 dead builders above 2 live ones, forever, and the ratio only gets worse.

How this already cost time. I filed #97 claiming FR-3 was unmet, having measured parentId at a moment when the workspace had zero live builders — so every row I saw was an orphan, and a missing DB row read as a missing feature. Re-measured with live builders present: 2 of 15 parent correctly to architect:<path>#uiv2. FR-3 works. The orphans produced a false bug report against a working feature, and they will do it again.

Scope of a fix. afx cleanup should be able to act on what it can see. Resolving a target by worktree directory when no project row exists — with the merged/unmerged check still applied, and the same confirmation any destructive path gets — closes the gap without weakening the rule that a human decides what is expendable.

Worth deciding separately: whether a row-less, session-less worktree should still be reported as a builder by discoverBuilders, or reported as something else. The current answer makes recovery possible, so it should not be changed casually.

Testing. Create a worktree under .builders/ with no global.db row. Assert afx cleanup can target it, that it refuses when the branch is unmerged without --force, and that GET /v2/events stops reporting it afterwards.

Note on the 13 in this workspace: 6 are merged and hold nothing but Agent Farm scaffolding (.builder-prompt.txt, .builder-role.md, .builder-start.sh, opencode.json, node_modules). 7 are unmerged. Nothing is decided about them here — that is the human's call.

[pseudoseed]

Root cause is sharper than filed: afx cleanup creates orphans

Measured today, and it reframes this issue.

I ran afx cleanup -p 112 and afx cleanup -p 83 after both PRs merged. Both reported success:

[info] Branch preserved: builder/air-112
[info] To delete: git branch -d "builder/air-112"
[ok] Builder builder-air-112 cleaned up!

What it actually removed: the global.db row. What it left behind:

• the worktree directory — 931 MB for air-112, 910 MB for spir-83
• the git worktree registration (git worktree list still lists both)
• the branch (deliberate, and it says so)

So a successful cleanup converts a tracked builder into an untrackable orphan and reports "cleaned up." Every future cleanup does it again. Orphans do not accumulate through neglect — they are manufactured by the command whose job is to prevent them.

Current cost in this workspace

Worktrees on disk	17
With a global.db row	2
Orphans	15
.builders/ total	8.5 GB
Reclaimable	~8.4 GB

Nine of them are ~900 MB each (air-14, air-112, spir-52, pir-4, pir-2, pir-12, air-22, spir-83, bugfix-1455) — full node_modules per worktree.

What this changes about the fix

Two defects, not one:

1. afx cleanup must remove the worktree directory and deregister it, not just delete the row. Deleting the row first is what makes the directory unreachable by every later command — the order guarantees the orphan.
2. Resolving a target by worktree directory when no row exists, so the existing 15 can be removed at all.

Fixing only (2) leaves the command generating new orphans as fast as they are cleared.

Also wanted

A visible count, so this is actionable instead of invisible: orphan count and reclaimable bytes surfaced where the numbers are already read — afx status, and worth considering for the v2 site view since those 15 are the majority of the builders it renders.