PLAN.md: previews are cached in thumbs.db

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

PLAN.md

@@ -652,16 +652,23 @@ something long in one, switch away and back, refresh — it's all still there.
     0.7 s on the CPU; the 8K Osmo HEVC 1.0 s against 2.9 s. `grid`'s two GPUs are listed in
     node order and both decode the same set (h264, hevc, vp9, mjpeg, mpeg2 — **no AV1 on
     either**, per vainfo, so AV1 is dav1d on the CPU).
-  - **Cached under the machine's data dir**, `<data dir>/thumbs/<xx>/<sha256>.jpg`, keyed by
-    path, size and mtime — a changed file gets a new preview, an unchanged one is never
-    decoded twice, and the URL carries `v=<mtime>-<size>` so the browser's own cache is
-    right too (7 days, ETag, 304). A file ffmpeg could not decode is remembered beside the
-    JPEGs as `.err` with ffmpeg's reason, answered as 422, and retried only when the file
-    changes; a timeout is not remembered. Nothing expires: a preview is a few KB, and only
+  - **Cached in one database file under the machine's data dir**, `<data dir>/thumbs.db`
+    (bbolt — pure Go, so the binary stays static; v0.1.0-202, the first build kept them as
+    a tree of hash-named JPEGs under `thumbs/`, replaced the same day when Mitchell asked
+    where they were kept: "stored in hamlab, maybe under a DB, up to you"). An entry is
+    keyed by path, size and mtime — a changed file gets a new preview, an unchanged one is
+    never decoded twice — and carries the engine, codec, source size and time beside the
+    picture; a count rides in the file so the previews button's tooltip can say "N kept
+    (M MB)" without walking anything. The URL carries `v=<mtime>-<size>` so the browser's
+    own cache is right too (7 days, ETag, 304). A file ffmpeg could not decode is kept with
+    ffmpeg's reason and no picture, answered as 422, retried only when the file changes; a
+    timeout is not kept. A miss never creates the file, so a machine nobody browses with
+    previews on never has one; a cache that cannot be opened is logged and previews are
+    still made and served, just not kept. Nothing expires: a preview is a few KB, and only
     files somebody scrolled past are ever made. At most 2–4 ffmpegs at once per machine
     (half the cores, clamped), one per file however many rows ask, and a preview's work
     runs on a clock of its own so the row that asked first leaving does not cancel it for
-    the rest. Each ffmpeg runs under `nice -n 10`. `hamlet`'s backup job skips the folder.
+    the rest. Each ffmpeg runs under `nice -n 10`. `hamlet`'s backup job skips the file.
   - **Root mode makes them as root** (`hamlab thumb`, the sibling of `hamlab fs`, caps on
     stdin, JSON out), so a file only root can read gets a preview, and the probe runs as
     root too — root opens every render node whatever groups the daemon has. Which matters: