yrtria/MediaShelf
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Ship nothing pre-kept

Browse source 
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
This commit is contained in:
Jess Hallsworth 2026-09-07 05:44:48 +00:00
parent 1ba03dca70
commit 58c2883492
No known key found for this signature in database
2 changed files with 27 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

7
.env.example
View file

@ -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).
# Editable in the UI afterwards; this value is not re-applied on later starts.
KEEP_ALL_LIBRARIES=Family Videos
# Optional: libraries to mark keep_all on first run only (comma-separated).
# Empty by default — nothing is ever kept unless you say so, in here or in the UI.
# e.g. KEEP_ALL_LIBRARIES=Family Videos,4K Movies
KEEP_ALL_LIBRARIES=
SCORE_RECENT_DAYS=90

35
docs/design.md
View file

@ -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
played", which a naive reclaim score ranks highly. The same is true for reasons the tool
cannot see: content kept deliberately in case someone wants it later, or held at 4K
because re-acquiring it is expensive. Keep marks are a first-class concept (§6.6).
*Family Videos* is 63 items and 38 GB of what looks like home video, 86% of it "never
played" and therefore ranked highly by a naive reclaim score. The same applies for reasons
the tool cannot see at all: content kept deliberately in case someone wants it later, or
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
anything else self-recorded is worth the same treatment (§15).
**Nothing ships kept.** No library is pre-marked, in seed data or in configuration — every
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
ships with `keep_all` set. *4K Movies* is the obvious next candidate — 72.9% never
played and the most expensive content in the library to re-acquire — but that is a
judgement call, not a measurement. *Sports* (2 UFC items) looks like personal capture.
Worth settling before the first real report is trusted (§6.6).
2. **Which libraries, if any, should be kept wholesale?** Deliberately left unanswered —
nothing ships kept (§6.6), and this is a judgement to make against a real report rather
than in advance. The candidates the measurements suggest are *Family Videos*
(irreplaceable home video), *4K Movies* (72.9% never played and expensive to
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.