Remove the face carousel — one card presentation

03's resettlement reverses the pathfinder carry-over: the
selection-keyed dual presentation proved undesirable, so a card has one
presentation — selection changes styling, never geometry, and the
masonry never reflows on click. Deleted the carousel view (page dots,
glass underlay, scroll-tick monitor), the QuickLook thumbnail cache
(sole consumer), the pure paging/suppression rules, and the
sole-selected animation key — Motion now keys transactions on the
search query and the drop proposal only. The attachment chip stays as
the face's whole attachment story; viewing media is the card window's
job. No carousel state had leaked beyond the view layer.

Claude-Session: https://claude.ai/code/session_01SR4XGjmBE16ZUYWpfFHXwY
This commit is contained in:
2026-07-28 08:11:59 -04:00
parent 3f4125e324
commit 1020d9fca4
14 changed files with 47 additions and 1143 deletions
+6 -6
View File
@@ -180,12 +180,12 @@ public struct Card: Identifiable, Sendable, Equatable {
/// empty when it has one that couldn't be listed the field is cosmetic, so a
/// directory-listing race degrades to "nothing to show" rather than failing a load.
///
/// Names, not URLs: the two board-window consumers only need to know *whether*, *how many*,
/// and in *what order* the face's quiet paperclip indicator (03-board-ui.md § Card face)
/// and the sole-selected card's attachment carousel. The card window's sidebar does its own
/// listing through `BoardWriter.listAttachments`, since it acts on the files rather than
/// showing them; that call answers through the very same enumeration
/// (`BoardLoader.attachmentNames(in:)`), so the two surfaces agree by construction.
/// Names, not URLs: the board-window consumer only needs to know *whether*, *how many*, and
/// in *what order* the face's quiet paperclip indicator (03-board-ui.md § Card face). The
/// card window's sidebar does its own listing through `BoardWriter.listAttachments`, since it
/// acts on the files rather than showing them; that call answers through the very same
/// enumeration (`BoardLoader.attachmentNames(in:)`), so the two surfaces agree by
/// construction.
///
/// Freshness is the watcher's, by construction: it reloads on any change anywhere under the
/// board root, so an attachment added in Finder rebuilds the snapshot exactly like an edited