Ship nothing pre-kept

The keep_all capability stays at library level, but no library is marked by
default. KEEP_ALL_LIBRARIES defaults to empty rather than naming Family
Videos, and the design says plainly that every keep in the system got there
because a person put it there.

A keep the application invented would be indistinguishable in the database
from one the user made, which undermines the audit trail the Kept view
exists to provide.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GVbG48GAXfCZatcmX123Ra

.env.example

@@ -43,7 +43,8 @@ SCORE_REJECTED_AT=2
 SCORE_SOLITUDE_AT=3
 SCORE_GRACE_DAYS=30
 
-# Libraries kept wholesale, seeded on first run only (comma-separated).
+# Optional: libraries to mark keep_all on first run only (comma-separated).
-# Editable in the UI afterwards; this value is not re-applied on later starts.
+# Empty by default — nothing is ever kept unless you say so, in here or in the UI.
-KEEP_ALL_LIBRARIES=Family Videos
+# e.g. KEEP_ALL_LIBRARIES=Family Videos,4K Movies
+KEEP_ALL_LIBRARIES=
 SCORE_RECENT_DAYS=90

docs/design.md

@@ -132,10 +132,12 @@ film twice. Cross-library duplicate detection moves from "later candidate" to a
 concern (§6.5).
 
 **Some content must never be a deletion candidate, and no data can tell you which.**
-*Family Videos* is 63 items and 38 GB of irreplaceable home video, 86% of it "never
+*Family Videos* is 63 items and 38 GB of what looks like home video, 86% of it "never
-played", which a naive reclaim score ranks highly. The same is true for reasons the tool
+played" and therefore ranked highly by a naive reclaim score. The same applies for reasons
-cannot see: content kept deliberately in case someone wants it later, or held at 4K
+the tool cannot see at all: content kept deliberately in case someone wants it later, or
-because re-acquiring it is expensive. Keep marks are a first-class concept (§6.6).
+held at 4K because re-acquiring it is expensive. Keep marks are a first-class concept
+(§6.6) — and because the tool cannot infer any of this, it does not try: nothing is kept
+until a person says so.
 
 ---
 
@@ -988,8 +990,15 @@ visible rather than silent. Nothing removes a keep mark except an explicit human
   guardrail, before any confirmation dialog. Removing the keep mark is a separate,
   deliberate act — deletion never offers to do it for you as part of the same click.
 
-Seeded from the measured library, `Family Videos` ships with `keep_all` set. `Sports` and
+**Nothing ships kept.** No library is pre-marked, in seed data or in configuration — every
-anything else self-recorded is worth the same treatment (§15).
+keep in the system got there because a person put it there. The `KEEP_ALL_LIBRARIES`
+environment variable exists so a library *can* be marked from configuration when that is
+convenient, but its default is empty and it stays empty unless someone sets it.
+
+That is a deliberate choice rather than an omission. A keep mark's value is that it
+records a human judgement; one the application invented on the user's behalf would be
+indistinguishable in the database from one they actually made, and would undermine the
+audit trail that makes the Kept view worth reading.
 
 #### The number that keeps this honest
 
@@ -1327,7 +1336,7 @@ All via environment variables, so the Portainer stack is the single source of tr
 | `SCORE_POPULAR_AT` | `3` | |
 | `SCORE_REJECTED_AT` | `2` | abandoned views for a full `rejection` score |
 | `SCORE_SOLITUDE_AT` | `3` | distinct watchers before `solitude` reaches zero |
-| `KEEP_ALL_LIBRARIES` | `Family Videos` | comma-separated; seeds `library.keep_all` on first run only, editable in the UI afterwards (§6.6) |
+| `KEEP_ALL_LIBRARIES` | *(empty)* | optional comma-separated library names to mark `keep_all` on first run. **Empty by default** — no library is ever kept unless someone says so (§6.6) |
 | `SCORE_GRACE_DAYS` | `30` | |
 | `SCORE_RECENT_DAYS` | `90` | |
 | `TZ` | `America/Regina` | so cron times mean what they look like |
@@ -1642,11 +1651,13 @@ cross-library duplicates (§6.5), keep marks (§6.6), and two new seed views (§
 
 1. **Registry or image upload?** (§11.2) A registry is the better long-term answer but is
    infrastructure that doesn't exist yet. A preference, not a measurement.
-2. **Which other libraries should be kept wholesale?** *Family Videos* is unambiguous and
+2. **Which libraries, if any, should be kept wholesale?** Deliberately left unanswered —
-   ships with `keep_all` set. *4K Movies* is the obvious next candidate — 72.9% never
+   nothing ships kept (§6.6), and this is a judgement to make against a real report rather
-   played and the most expensive content in the library to re-acquire — but that is a
+   than in advance. The candidates the measurements suggest are *Family Videos*
-   judgement call, not a measurement. *Sports* (2 UFC items) looks like personal capture.
+   (irreplaceable home video), *4K Movies* (72.9% never played and expensive to
-   Worth settling before the first real report is trusted (§6.6).
+   re-acquire, though marking it removes 5 TB from consideration permanently), and
+   *Sports*, which looks like personal capture. All three are equally well served by
+   explicit marks on the items that actually matter.
 3. **What should the 18.8% partial-view band mean?** Four times the abandoned share and
    genuinely ambiguous (§6.1). v1 stores and displays it without scoring it; a month of
    looking at real rows should settle whether it earns a component.