PLAN: seven more to do — tab overlap, two renames, ZFS scheduling, virtualization, Files polish

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

PLAN.md

@@ -487,6 +487,76 @@ something long in one, switch away and back, refresh — it's all still there.
   - *Not app work, but the trigger:* nothing here blocks starting the migration except the
     inventory. Do that first.
 
+- **Keep Processes or Top, not both** — asked for 2026-09-23, not started. They answer the
+  same question and read the same data: `Top.tsx` already fetches `/api/procs` for its
+  process panel, the same endpoint `Procs.tsx` is built on, and both draw the same CPU,
+  memory, load and network numbers. Top is the btop-style whole-machine screen; Processes
+  is the sortable table with filter, kill and signal. Decide which survives and fold the
+  other's worth into it — most likely Top stays and gains Processes' sorting, filtering and
+  signal actions, since one screen beats two. Whichever goes, its rail entry, its `View` id
+  and its hash route go with it, and any saved rail order naming it must degrade quietly
+  (`railorder.ts` already ignores ids it does not recognise).
+
+- **Rename the Space tab** — asked for 2026-09-23, not started. "Space" is vague; the tab
+  is WizTree for a disk or pool. Candidates: **Usage**, **Disk Usage**, **Storage**. Note
+  `Disks` already exists and `Storage` would muddle with it, so Usage is probably the one.
+  The rename touches the rail label, the `View` id, the hash route (`#/<machine>/space`,
+  which people may have bookmarked — decide whether to keep `space` as the id and change
+  only the label), the footer's page name and `Space.tsx`'s own strings.
+
+- **ZFS gets its own tab, under Disks** — asked for 2026-09-23, not started. Today ZFS is a
+  section inside `Disks.tsx`: pools with health, capacity, fragmentation, scrub controls, a
+  dataset tree and per-dataset snapshot lists with "Snapshot now". Moving it out makes room
+  for what is actually wanted: **scheduled snapshots with a retention policy**, configured
+  from the console rather than by hand. What exists to build on — `grid` runs `zfSnap`
+  nightly at 02:30 from root cron with 6-week expiry (`zfsnap-cron-6w-daily.sh`, predates
+  this repo), and Ham Lab's Cron tab can already read, write and run root crontabs, so the
+  job can be managed rather than reinvented. Decide: does Ham Lab drive `zfSnap`/`zfs-auto-
+  snapshot` if present, or write and own its own timer? Per-dataset policies or one for the
+  pool? And it must show what a retention rule *will* delete before it runs.
+
+- **Rename Cron to something generic** — asked for 2026-09-23, not started. Mitchell's
+  reasoning: the Services tab is systemd but "Services" is the right generic name for it,
+  so the scheduling tab should be named for the job it does, not the tool. **Scheduled** or
+  **Jobs**. The tab already covers more than cron — `/etc/crontab`, `/etc/cron.d`, user
+  crontabs, `run-parts` directories *and* systemd timers — so the generic name is the
+  honest one. Same rename surface as the Space tab: rail label, `View` id, hash route,
+  footer name.
+
+- **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 —
+  which is the comparison Ham Lab has invited since its first line. Nothing exists yet.
+  What a future session has to settle before writing code: which stack (libvirt/KVM +
+  `virsh` is the obvious one for VMs; LXC or Incus for containers, and Incus covers both);
+  whether it manages what is already installed or installs it; where disk images live
+  (`tank` on `grid`, local NVMe elsewhere); console access (SPICE/VNC proxied through the
+  daemon, or a serial console over the existing terminal machinery, which would reuse
+  `internal/term`); snapshots and clones; and what it does on a host with no virtualisation
+  at all, which is every host here today. Worth scoping as its own plan before starting.
+
+- **Deprecate the Dashboard tab** — asked for 2026-09-23, not started. Mitchell: it is nice
+  but the app repeats itself, and this goes together with choosing between Processes and
+  Top. Dashboard is the customisable module list (CPU, memory, load, uptime, temps, fans,
+  network, disks, filesystems, UPS) plus custom sensor widgets; Top shows most of the same
+  numbers on one screen. **Widgets stays**, reframed: its page should say plainly that the
+  widgets there are for **external dashboards** (Glance, Home Assistant, a wall display)
+  via `/embed/widget` and read-only sensor tokens, not a second copy of this console's own
+  screens. Care needed on the way out: the dashboard layout is per-user in `state.json`
+  (`users.<name>.dashboard`) and carries `intervalMs`, which the server reads in
+  `applyPrefs` to set the sampler — that wiring has to move or the sampling rate loses its
+  source. `dashboard` is also the default view after login and after switching machines.
+
+- **Files explorer: cleanup and ease of use** — asked for 2026-09-23, not started.
+  Specifically named: **the mouse's back button must go up a directory**. Why it does not
+  today — `hashsel.ts` navigates with `history.replaceState`, which deliberately leaves no
+  history entry, so there is nothing for the browser (or the mouse's back button, which is
+  just `history.back()`) to return to. Fixing it properly means Files pushing a history
+  entry per folder and answering `popstate`, which `useHashSel` already listens for; doing
+  it in `hashsel.ts` would change every page that uses it, so decide whether history is
+  per-page opt-in. Beyond that the ask is general polish, and the **Deprecate copyparty**
+  item names the heavier pieces (multi-select and bulk actions, folder download, resumable
+  uploads, a gallery, search) — worth doing the two together, since they are the same tab.
+
 ## Open questions
 
 - Idle-session reaping policy (never / after N days) — leaning never; it's a