A file copied in Finder becomes a card's attachment — ⌘V's reserved clause finally answers

The image branch's precedence ladder always had a second clause: a file URL on the pasteboard suppresses it, "a different gesture with a different answer" that the code deliberately declined rather than guessed at. This fills it in: one or more file URLs paste through the same `importAttachments` a Finder drop takes — one collision ladder, one folder refusal (`FinderDrop.partition`), one set of banners — outranking raw image data riding beside it (a Finder-copied image file carries both; the actual file lands, not a re-encoded copy of its bytes) while still deferring to the app's own clipboard type. Both ⌘V surfaces read the same `ClipboardStore.fileURLPayload`, so the board's fallback and the card window's own branch stay in step by construction rather than by two hand-kept-in-sync checks. Fixed a real leak in the body editor's paste yield along the way: `public.file-url` conforms to `public.url`, which `NSTextView` legitimately reads for a pasted hyperlink, and `NSPasteboard.availableType(from:)` matches by conformance rather than exact type — so a Finder copy carrying a generic URL representation beside its file URL would have been silently swallowed as text and never reached the window's attachment branch at all. The yield now declines outright on any file-URL pasteboard before the generic capability check runs. Claude-Session: https://claude.ai/code/session_014PtZdPwqZuqEDLc6wZMtEy
2026-08-09 08:38:07 -04:00
parent d0c546179f
commit 0fe92bdf38
9 changed files with 565 additions and 38 deletions
@@ -481,12 +481,12 @@ struct CardWindowHost: View {
            .onChange(of: placement.card.hero.value, initial: true) { _, hero in
                attachments.hero = hero
            }
-            // **⌘V in this window pastes a picture onto this card** (04-interactions.md ▸ Clipboard's
-            // image-data branch). Here rather than inside `CardWindowView` because the availability
-            // is the clipboard's observable reading and this is where a store, a card id and the
-            // app-wide clipboard are all in scope at once — the same join `configureAttachments`
+            // **⌘V in this window pastes onto this card** (04-interactions.md ▸ Clipboard's
+            // image-data and file-URL branches). Here rather than inside `CardWindowView` because the
+            // availability is the clipboard's observable reading and this is where a store, a card id
+            // and the app-wide clipboard are all in scope at once — the same join `configureAttachments`
            // makes for the other two writes.
-            .cardWindowImagePaste(
+            .cardWindowPaste(
                store: store,
                cardID: placement.card.id,
                clipboard: appModel.clipboard