manage purge is unreachable after manage uninstall (all three installers)

[nedtwigg]

manage uninstall prints:

Use "manage purge" separately to delete those irreversibly.

…and then deletes the directory holding manage. So the command the banner points at no longer exists: purge after uninstall is not merely out of order, it is unreachable. Recovering config/ and state/ afterwards means deleting them by hand, or reinstalling purely to get bin/manage back so it can be purged.

All three installers have it. Verified at f48c07f4:

	banner says "use manage purge"	deletion that removes bin	manage written to
Linux	install-linux.sh:1216	:1238	:741 (BIN_DIR at :466)
macOS	install-macos.sh:965	:986	:562 (BIN_DIR at :266)
Windows	install-windows.ps1:1750	:1779	:1841

Linux and macOS delete "$ROOT/releases" "$ROOT/current" "$ROOT/previous" "$ROOT/bin" "$ROOT/run"; Windows removes releases, bin, run via Remove-Tree. bin is manage's own home in each.

Why this isn't a one-line reorder

The closing install banner advertises

manage:  "<root>/bin/manage" <status|verify|logs|restart|show-password|serve|rollback|uninstall>

and omits purge — on all three (install-linux.sh:1343, install-macos.sh:1343, install-windows.ps1:2185; same omission in manage's own usage text at install-linux.sh:1609). The uninstall message is therefore the only place a user ever learns purge exists.

That makes the fix a judgment call rather than mechanical:

• Reorder the message to "purge first, then uninstall" — trades the dead end for a discoverability gap, since the only mention of purge now appears after the point where it is still usable.
• Preserve manage across uninstall (keep bin/, or leave a standalone purge shim) — keeps both reachability and discoverability, at the cost of uninstall no longer being a clean sweep of the install root.
• Add purge to the advertised subcommand list — orthogonal to the above, and arguably wanted either way, though it does raise the prominence of the irreversible command.

Not proposing one here; it wants a call from someone who owns the operator-experience intent.

Notes

• docs/specs/server.md -> "Installing it (behind Tailscale)" describes the operator surface as … uninstall, and the separately-confirmed purge, which is accurate about intent and silent about the ordering constraint. Whichever fix lands, that sentence and SELF_HOST.md checkpoint 5 ("manage uninstall … manage purge is the separate, irreversible operation") should say the order explicitly.
• Since the three installers are bound together by scripts/deploy-lint.mjs, a fix touches all three and may warrant a lint rule so the banner and the deletion cannot drift apart again.
• Found while running SELF_HOST.md end to end on Linux, in the same session as fix(deploy): make the Linux operator preflight actually detect the role #472 (which fixes an unrelated preflight bug). The teardown there only succeeded because purge happened to be run first.

🤖 Generated with Claude Code

https://claude.ai/code/session_01J1jDWEh3MTRaFTqmKPoJkK

[dormouse-bot]

Confirmed on the current default branch (01d1328c) — all three installers point at manage purge and then delete the directory manage lives in. No fix PR: the three options are an operator-experience call, and you asked for that call rather than a pick.

Two corrections/additions from re-verifying against 01d1328c:

manage's own usage text does list purge — on all three, not just Linux (install-linux.sh:1231, install-macos.sh:1024, install-windows.ps1:1834). The omission is only in the closing install banner. That narrows the discoverability gap the reorder option trades into: pre-uninstall, purge is discoverable — though only via an invalid subcommand, since bare manage dispatches to status ("${1:-status}", and the $args.Count equivalent on Windows), so there is no manage help path to it. Post-uninstall every mention is gone with bin/, which is the part that actually bites.

Windows may not behave like the other two. Invoke-Uninstall deletes bin via Remove-Tree while cmd.exe is still executing bin\manage.cmd (the shim at :1856 that launches manage.ps1), and manage's embedded Remove-Tree calls Remove-Item -Recurse -Force with no -ErrorAction (:1130). If cmd.exe holds the handle for the duration — the usual reason the shim ends in & exit, but I can't test it from a Linux runner — the delete raises a non-terminating error, Invoke-Uninstall prints uninstalled. and returns 0 anyway, and bin survives in whatever partial state the sweep reached. Worth confirming on a Windows box before a fix assumes the three platforms share the failure.

Verified line anchors at 01d1328c (the issue's numbers were against f48c07f4)

	banner says "use manage purge"	deletion that removes bin	manage written to	closing banner omitting purge
Linux	:1170	:1192	:695 (BIN_DIR at :420)	:1557
macOS	:965	:986	:562 (BIN_DIR at :266)	:1343
Windows	:1750	:1779	:1841 (BIN_DIR at :551)	:2185

One detail for costing the "reinstall to get manage back" recovery path: it is at least non-destructive to what you'd then be purging — a reinstall over an existing install preserves config/server.env rather than regenerating it (install-linux.sh:630), so the password and VAPID key you're about to delete are still the originals. It does mean a full release download, unit registration, and health check to run one rm -rf.