1.9 KiB
Album proposals
← Documentation index · Guided first pass
What it is for. Turning a folder of analysed photographs into a name a person would have chosen, before any folder is touched.
What you decide. The final name. The proposal is a starting point with its reasoning attached; you edit it, accept it, or ignore it.
What it changes. A row per album: proposed name, rationale, confidence, and your final name, with a version. Approving renames nothing. Not one file moves at this stage — approval only marks a name as agreed, and the rename stage is where it becomes a plan you have to confirm separately.
What it refuses. A name containing / \ : * ? " < > |, a reserved device name, or
one that collides with an existing folder is rejected while you type and again on the
server. Approval is refused when the evidence changed since the proposal was
generated — the proposal is stale, and regenerating is the honest fix. Editing with a
stale version returns a conflict and shows you the server's truth rather than
overwriting it.
Reading the view
The left pane lists albums with their state: none, proposed, edited,
approved, error, or stale. The right pane shows the evidence the name was built
from — date range, dominant tags, locations, counts — then the suggested name, the
rationale, the confidence, and an editable final name.
The default naming shape is predictable and sortable:
YYYY-MM — Place — Event
YYYY — Event
Place — Event
While a rename is unresolved
Generating and approving proposals is blocked while an interrupted rename is
outstanding, with 409 rename_recovery_required. Resolve the rename first: building
new names on top of a half-applied move is how a library becomes hard to reason
about.
Next: renames.