plan: the Docker tab's Dockhand gap is closed; the cutover is homelab work

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

PLAN.md

@@ -571,41 +571,40 @@ something long in one, switch away and back, refresh — it's all still there.
   2026-09-24 to take in Docker tab polish and feature work, on the same reasoning as the
   Files item: it is one tab, and the gaps that block retiring the old tool and the things
   that would simply make it better are the same body of work. The *homelab* half —
-  migrating every stack off Dockhand's data dir, then removing the container — is `hamlet`'s
+  the cutover itself, then moving every stack off Dockhand's data dir — is `hamlet`'s
   `docs/pending.md` → "Retire Dockhand; Ham Lab becomes the orchestrator", agreed
   2026-09-20. This entry is the *app* half.
-  Where it stands: Stacks already creates, edits, deploys, updates, restarts, stops, downs
+
-  and deletes stacks on every machine, and Containers does start/stop/restart, logs that
+  **Done 2026-09-24 — the eight Mitchell picked from the inventory**, all in the Docker tab:
-  follow, inspect, and the images/volumes/networks tables. So this is not a rewrite.
+  per-container **Stats**, **Health** (with the last few probe outputs), **Events** (Ham Lab
-  - **What Dockhand still does that Ham Lab does not.**
+  keeps its own 4000-entry ring, since `docker events` forgets after about a minute),
+  **Shell** (`docker exec`, handed to the Terminal tab) and **Limits** (`docker update` for
+  memory, CPU and restart policy); an **updates** tab giving the whole machine at once with
+  a per-container indicator in the list; the same across every machine, asked of the hub;
+  and **schedules**, which write `/etc/cron.d/hamlab-docker` and call
+  `hamlab docker-update <id>` — the shape the ZFS schedules already use.
+  Also done: Ham Lab keeps working when `dockhand` is removed. It remembers where a
+  container's bind mounts pointed (`mounts` in `state.json`) and resolves a stack through
+  that record when no running container explains its path, running compose on the host
+  instead; `repoint` does the same for a schedule at run time. Without this, removing the
+  container would have made 17 stacks on `core` and 5 on `grid` unfindable at once.
+
+  - **Left from the Dockhand inventory, both to decide rather than build.**
     - *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 drop it — most
+      pulls it. Its `git_repositories` and `git_stacks` tables are **empty**, so nothing
-      stacks here have no row in that table anyway, so dropping it may be the honest answer.
+      here uses it — dropping it is the honest answer unless Mitchell says otherwise.
-    - *Scheduled image updates.* Ham Lab checks for new images only when asked, since each
+    - *Webhooks, OIDC, LDAP, vulnerability scans.* All four tables empty. Nothing to move.
-      check is 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. Note the Jobs tab and the ZFS schedules already show the shape this would
-      take: a cron line Ham Lab owns, not a ticker in the daemon.
-    - *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
+  - **The `*:2375` question, which this is the moment to settle.** A stack deployed to
-      one view of "what is out of date across the fleet".
+    `grid` or the Mac still goes over `tcp://<node>:2375` from the hub. Decide whether the
-  - **The `*:2375` question, which this is the moment to settle.** Ham Lab runs compose
+    hub should instead ask the node's own Ham Lab to deploy locally, which would end the
-    inside `dockhand` because that is how the stacks were deployed; once they move to a
+    unauthenticated Docker socket exposure — its own item in `docs/pending.md`, currently
-    neutral home that path is unused for them, but a stack deployed to `grid` or the Mac
+    filed under "decided, no action", and this is the change that would make closing it
-    still goes over `tcp://<node>:2375` from the hub. Decide whether the hub should instead
+    free.
-    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
   manage **LXC containers and virtual machines** from the console, the way Proxmox does —