PLAN: to do — deprecate copyparty, deprecate Dockhand

The Dockhand entry is the app half only; migrating the stacks stays in hamlet's
docs/pending.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

PLAN.md

@@ -427,6 +427,52 @@ something long in one, switch away and back, refresh — it's all still there.
     Downgrades are already refused by the installer's `vnum()` comparison; the updater
     should use the same rule.
 
+- **Deprecate copyparty** — asked for 2026-09-23, not started. `copyparty` on `grid`
+  (`copyparty.service`, `:3923`, `/etc/copyparty.conf`, serving all of `/tank` as user
+  `core` with one account behind NPM) overlaps the **Files** tab almost entirely. The aim
+  is to stop the service and keep only Ham Lab. What Files must gain first, in the order
+  that matters:
+  - **Multi-select and bulk actions.** copyparty selects many rows and moves, deletes or
+    downloads them together; Files acts on one row at a time.
+  - **Download a folder**, and a multi-file download, as a streamed zip or tar — the thing
+    copyparty is reached for most.
+  - **Resumable uploads.** copyparty's up2k chunks a file, survives a dropped connection
+    and skips what is already there; Files streams one PUT, so a phone upload that drops at
+    90% starts over.
+  - **A gallery.** Thumbnails for a folder of images and video, and play audio/video in
+    place — `/tank/media` and `/tank/immich` are most of what is browsed.
+  - **Search** below the current folder by name, since `find` in a terminal is the fallback
+    today.
+  - *Decide when built:* whether share links (copyparty's public per-path links) are wanted
+    at all — they are the one feature that hands out access without a login, and Ham Lab has
+    no notion of that; if not, say so in the docs rather than leaving a gap unexplained.
+  - *After:* `systemctl disable --now copyparty`, remove its NPM host, keep
+    `/etc/copyparty.conf` until a rollback is clearly not needed, then update
+    `hamlet`'s `docs/hosts.md` bare-metal list, `docs/gotchas.md` (the "`docker ps` is not
+    the inventory" note names it) and the `grid` row in `CLAUDE.md`.
+
+- **Deprecate Dockhand** — asked for 2026-09-23, not started; the *homelab* half of this
+  (migrating every stack off Dockhand's data dir, then removing the container) is
+  `hamlet`'s `docs/pending.md` → "Retire Dockhand; Ham Lab becomes the orchestrator",
+  agreed 2026-09-20. This entry is the *app* half only: what Ham Lab must do before that
+  migration can start. Its Stacks page already creates, edits, deploys, updates, restarts,
+  stops, downs and deletes stacks on every machine, so the gaps are Dockhand's extras:
+  - **Git-sourced stacks.** Dockhand's `stack_sources` table points a stack at a repo and
+    pulls it. Ham Lab has no equivalent. Decide whether to build it or to drop it — most
+    stacks here have no row in that table anyway, so dropping it may be honest.
+  - **Scheduled image updates.** Ham Lab checks for new images only when asked (a registry
+    request Docker Hub counts) and never updates by itself. If anything relies on Dockhand
+    updating on a schedule, that must move here or be dropped on purpose.
+  - **Webhooks / per-host environments**, if either is in use — inventory before deciding.
+  - **Deploying from a host path without an orchestrator container.** Ham Lab already runs
+    compose inside `dockhand` because that is how the stacks were deployed; once they move
+    to a neutral home the "via" path is unused for them, but a stack deployed to `grid` or
+    the Mac still goes over `tcp://<node>:2375` from the hub. Decide whether Ham Lab should
+    instead ask the node's own Ham Lab to deploy locally, which would end the `*:2375`
+    exposure (its own item in `docs/pending.md`).
+  - *Not app work, but the trigger:* nothing here blocks starting the migration except the
+    inventory. Do that first.
+
 ## Open questions
 
 - Idle-session reaping policy (never / after N days) — leaning never; it's a