PLAN: the Docker tab's polish and retiring Dockhand are one item

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

PLAN.md

@@ -534,26 +534,44 @@ something long in one, switch away and back, refresh — it's all still there.
     `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
+- **Grow the Docker tab until Dockhand can go** — asked for 2026-09-23 and widened
-  (migrating every stack off Dockhand's data dir, then removing the container) is
+  2026-09-24 to take in Docker tab polish and feature work, on the same reasoning as the
-  `hamlet`'s `docs/pending.md` → "Retire Dockhand; Ham Lab becomes the orchestrator",
+  Files item: it is one tab, and the gaps that block retiring the old tool and the things
-  agreed 2026-09-20. This entry is the *app* half only: what Ham Lab must do before that
+  that would simply make it better are the same body of work. The *homelab* half —
-  migration can start. Its Stacks page already creates, edits, deploys, updates, restarts,
+  migrating every stack off Dockhand's data dir, then removing the container — is `hamlet`'s
-  stops, downs and deletes stacks on every machine, so the gaps are Dockhand's extras:
+  `docs/pending.md` → "Retire Dockhand; Ham Lab becomes the orchestrator", agreed
-  - **Git-sourced stacks.** Dockhand's `stack_sources` table points a stack at a repo and
+  2026-09-20. This entry is the *app* half.
-    pulls it. Ham Lab has no equivalent. Decide whether to build it or to drop it — most
+  Where it stands: Stacks already creates, edits, deploys, updates, restarts, stops, downs
-    stacks here have no row in that table anyway, so dropping it may be honest.
+  and deletes stacks on every machine, and Containers does start/stop/restart, logs that
-  - **Scheduled image updates.** Ham Lab checks for new images only when asked (a registry
+  follow, inspect, and the images/volumes/networks tables. So this is not a rewrite.
-    request Docker Hub counts) and never updates by itself. If anything relies on Dockhand
+  - **What Dockhand still does that Ham Lab does not.**
-    updating on a schedule, that must move here or be dropped on purpose.
+    - *Git-sourced stacks.* Dockhand's `stack_sources` table points a stack at a repo and
-  - **Webhooks / per-host environments**, if either is in use — inventory before deciding.
+      pulls it. Ham Lab has no equivalent. Decide whether to build it or drop it — most
-  - **Deploying from a host path without an orchestrator container.** Ham Lab already runs
+      stacks here have no row in that table anyway, so dropping it may be the honest answer.
-    compose inside `dockhand` because that is how the stacks were deployed; once they move
+    - *Scheduled image updates.* Ham Lab checks for new images only when asked, since each
-    to a neutral home the "via" path is unused for them, but a stack deployed to `grid` or
+      check is a registry request Docker Hub counts, and never updates by itself. If
-    the Mac still goes over `tcp://<node>:2375` from the hub. Decide whether Ham Lab should
+      anything relies on Dockhand updating on a schedule, that must move here or be dropped
-    instead ask the node's own Ham Lab to deploy locally, which would end the `*:2375`
+      on purpose. Note the Jobs tab and the ZFS schedules already show the shape this would
-    exposure (its own item in `docs/pending.md`).
+      take: a cron line Ham Lab owns, not a ticker in the daemon.
-  - *Not app work, but the trigger:* nothing here blocks starting the migration except the
+    - *Webhooks and per-host environments*, if either is in use. Inventory before deciding.
+  - **Known gaps in the tab itself**, worth closing whether or not Dockhand goes:
+    - *Removing networks* — volumes and images can be pruned and removed, networks cannot.
+    - *Container detail is thin next to the stack view.* No per-container resource limits,
+      restart-policy editing, or exec-into-container from the tab (the Terminal tab is the
+      workaround). Decide which of these belong here at all.
+    - *Logs are polled with `--since` rather than followed over a held connection.* That was
+      deliberate and works, but a long tail is choppier than the Services tab's live tail,
+      which does hold a connection. Worth reconciling the two.
+    - *Image update checks are remembered six hours and asked for per stack*, so there is no
+      one view of "what is out of date across the fleet".
+  - **The `*:2375` question, which this is the moment to settle.** Ham Lab runs compose
+    inside `dockhand` because that is how the stacks were deployed; once they move to a
+    neutral home that 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 the hub should instead
+    ask the node's own Ham Lab to deploy locally, which would end the unauthenticated
+    Docker socket exposure — its own item in `docs/pending.md`, currently filed under
+    "decided, no action", and this is the change that would make closing it free.
+  - *Not app work, but the trigger:* nothing above blocks starting the migration except the
     inventory. Do that first.
 
 - **A Virtualization tab** — asked for 2026-09-23, not started, and **large**. Run and