[ergofobe]

Closes #38.

imogen trash --album "$ALBUM" with the variable unset trashed a library's worth of
photographs and exited 0: contains("") is true of every name, so an empty reference
resolved to whichever album the server listed first. find_album did not trim either, so
" " behaved the same way.

The three defects #38 names are fixed together, because the empty-reference guard cannot
land on its own:

• album_or_create matched on Err(_), so a refused empty reference would have made
  an album literally called "" — and an ambiguous name was already making a duplicate
  rather than asking which of the two was meant.
• The exact-name tier was not uniqueness-checked. Album names have no unique index, so
  two called "Holiday" resolved to whichever the server listed first. The same shortcut was
  attempted for people in the PR closing An empty --to resolves to the first named person instead of failing #30 and reintroduced the bug it was closing; the
  tier now requires the name to be unique, exactly as find_person's whole-name tier does.

Both lookups now go through albums_for, which trims the reference and refuses an empty
one before anything reaches the wire — the trim and the guard live together so neither can
be done without the other — and then through named_album, the exact tier: an id, or a
name exactly one album carries. The stored name is compared trimmed as well, so an album
called " Trip " is still the album somebody filing into "Trip" means.

What the two do with a name nothing carries exactly is where they part, and review changed
this after the first commit:

• find_album widens to partial names, as a lookup should.
• album_or_create makes that name. Filing into an album is a name, not a search:
  settling for "Holiday 2024" when asked for "Holiday" puts photographs somewhere nobody
  named, and refusing "Holiday" as ambiguous between "Holiday 2024" and "Holiday 2025"
  would leave an album of that name impossible to make.

A transport failure listing the albums is no longer mistaken for "not there yet" either,
and both ambiguity refusals name each album with its id — two albums called "Holiday"
printed as "Holiday, Holiday" said nothing.

Tests

Thirteen in src/context.rs, against a stub answering GET/POST /api/v1/albums and
recording what it was asked. Those that fail on main:

• an empty and a whitespace-only --album are refused, and nothing reaches the wire
• an empty reference makes no album either (on main it creates one called " ")
• a name two albums share is refused rather than resolved, and the refusal names the ids
• an ambiguous name adds no third album of that name
• a partial name matching several albums names them by id too
• filing into an album does not settle for a longer name
• a library that cannot be listed makes nothing
• a new album is created under the trimmed name

And the regression guards, which pass on main and pin what the fix must not break: an
exact name still beats the longer one it is a prefix of, a name with a stray newline still
finds its album, an album whose stored name is padded is still the album of that name, and
a new name is still creatable beside the names it is part of.

Verify

cargo test --locked && cargo fmt --check && cargo clippy --all-targets --locked -- -D warnings && cargo build --release --locked — green (153 tests).

Found, not fixed

• album update -d with --clear-description silently drops the description #41 — imogen album update -d "new text" --clear-description is
  accepted and silently drops the description. --location and --clear-location together silently clear #32's contradiction in another command;
  AlbumCommand::Update declares no conflicts_with.
• imogen album create "" makes an album no name can reach #43 — imogen album create "" makes an album no name can reach. This
  PR hardens reading a reference that cannot pick an album; writing one is the other half.

🤖 Generated with Claude Code