A picture off the pasteboard becomes a card's file, its hero, or the board's backdrop

⌘V grows an image-data branch, below the app's own clipboard format and refused
outright while a file URL is on the pasteboard: a screenshot or a browser's Copy
Image lands as "Pasted Image.png" in the anchor card's attachments/, through the
very import path Finder file drops and ⇧⌘A take — one bracket, one Finder-style
collision ladder, one set of banners, and the same silence a drop's arrival has.
A card window's ⌘V pastes onto its own card; a focused text field still wins the
selector natively. A file-shaped flavor travels byte for byte, PNG preferred when
several are offered; TIFF and BMP are re-encoded to PNG, being interchange
encodings rather than files anyone wants in a folder.

The hero key gets the setter it was born owing: "Set as Hero" on any image row of
the attachment list, "Remove Hero" on the row that holds it, with menu-bar twins
so the context entry is nobody's only home. It writes as a restyle — one key, one
bracket, one invertible step on the window's own stack — and replaces rather than
refusing, because a card has one hero and the row that has it says Remove instead.

Edit ▸ Paste as Board Background is the same payload's other destination, taking
the existing background.image convention at its word: the picture into the board
folder as "Pasted Background.png", the colour subkey untouched, the generator's
overwrite-our-own-name rule inherited and its echo memo taught to tell the two
producers apart.

Claude-Session: https://claude.ai/code/session_014PtZdPwqZuqEDLc6wZMtEy

Kanban/UI/Board/ClipboardCommands.swift

@@ -45,9 +45,94 @@ extension View {
             .onCommand(#selector(NSText.copy(_:)), perform: clipboard.canCopy(from: store) ? {
                 clipboard.copy(from: store)
             } : nil)
-            .onCommand(#selector(NSText.paste(_:)), perform: clipboard.canPaste(into: store) ? {
-                clipboard.paste(into: store)
-            } : nil)
+            .onCommand(#selector(NSText.paste(_:)), perform: Self.pasteAction(store: store, clipboard: clipboard))
+    }
+
+    /// **⌘V's two branches as one optional handler** (04-interactions.md ▸ Clipboard, the image-data
+    /// branch ruled 2026-08-09).
+    ///
+    /// The precedence is expressed as the order of these two `if`s and nowhere else, which is the
+    /// same discipline the rest of this file states: availability *is* the handler's presence, so a
+    /// board payload winning over a picture is one expression rather than a condition on one item and
+    /// a matching negation on another. `ClipboardStore.refresh` has already made the two readings
+    /// mutually exclusive at the source (`imagePayload` is `nil` whenever a board payload is
+    /// readable), so this ordering is belt over braces — but it is the ordering a reader will look
+    /// for, and stating it here costs one line.
+    ///
+    /// `nil` — neither branch applies — greys the standard Paste row out exactly as before.
+    private static func pasteAction(store: BoardStore, clipboard: ClipboardStore) -> (() -> Void)? {
+        if clipboard.canPaste(into: store) {
+            return { clipboard.paste(into: store) }
+        }
+        if clipboard.canPasteImage(into: store) {
+            return { clipboard.pasteImage(into: store) }
+        }
+        return nil
+    }
+}
+
+// MARK: - The card window's ⌘V
+
+extension View {
+
+    /// **⌘V in a card window pastes a picture into that card** (04-interactions.md ▸ Clipboard, the
+    /// image-data branch; 05-card-window.md ▸ Attachments).
+    ///
+    /// The board's own responder shape, one window over and with one branch instead of two: there is
+    /// no board payload a card window could paste — cards and lanes land on a *board* — so the card
+    /// window answers `paste:` only for the image branch, and only while there is a picture to take.
+    ///
+    /// **A focused text field still wins, with nothing here doing the arithmetic.** `NSTextView`
+    /// consumes `paste:` natively, so ⌘V in the body editor, the comment composer or an inline
+    /// comment edit stays a text paste and this responder never sees the selector — which is the
+    /// board's own "focused-editor rule, twice over" arriving in the window where it matters most.
+    /// It is also why this hangs on the window's whole content rather than on the attachments
+    /// section: 05 makes the *window* the drop surface for files, and the paste is that sentence's
+    /// keyboard twin.
+    func cardWindowImagePaste(store: BoardStore, cardID: ItemID, clipboard: ClipboardStore) -> some View {
+        onCommand(
+            #selector(NSText.paste(_:)),
+            perform: clipboard.canPasteImage(intoCard: cardID, in: store) ? {
+                clipboard.pasteImage(intoCard: cardID, in: store)
+            } : nil
+        )
+    }
+}
+
+// MARK: - Edit ▸ Paste as Board Background
+
+/// **Edit ▸ Paste as Board Background** — the pasteboard's picture into the board folder, with
+/// `background.image` pointed at it (03-board-ui.md § Styling ▸ Capabilities; ruled 2026-08-09).
+///
+/// ### Why this is a row of its own rather than another ⌘V branch
+///
+/// ⌘V has a target: the anchor card, or the card window's card. A board's backdrop is not on that
+/// path at all — it is one value per board, reachable with nothing selected — so folding it into the
+/// paste selector would mean either a modifier nobody could discover or ⌘V meaning two different
+/// things depending on the selection. A named row says what it does, and the Nexus's "no default
+/// chord" posture covers the rest: it remaps like any other item.
+///
+/// **Board window only**, which needs no clause: the row reads `\.boardStore`, and a card window or
+/// the welcome window in front means there is no focused board store and the item is disabled.
+///
+/// The title is API (04-interactions.md ▸ Configurable bindings) and is unique across the menu bar.
+struct PasteBoardBackgroundCommand: View {
+
+    let clipboard: ClipboardStore
+
+    @FocusedValue(\.boardStore) private var store
+
+    var body: some View {
+        Button("Paste as Board Background") {
+            guard let store else { return }
+            clipboard.pasteBoardBackground(into: store)
+        }
+        .disabled(!isEnabled)
+    }
+
+    private var isEnabled: Bool {
+        guard let store else { return false }
+        return clipboard.canPasteBoardBackground(into: store)
     }
 }
 

Kanban/UI/Board/PasteTarget.swift

@@ -60,6 +60,25 @@ enum PasteTarget {
         return Cards(laneID: lane.id, index: index)
     }
 
+    /// **Which card an image paste lands on** — the anchor card, and only a card (04-interactions.md
+    /// ▸ Clipboard, the image-data branch ruled 2026-08-09: "paste targets a card … per the existing
+    /// paste-target grammar").
+    ///
+    /// `flattenAnchor` again rather than a rule of its own, because the ruling says "the existing
+    /// paste-target grammar" and this is it: the last selected card in flatten order, which is
+    /// already what a card payload anchors after and what ⌘N creates after.
+    ///
+    /// **`nil` wherever the anchor is not a card**, which is the whole of the difference from
+    /// `cards(selection:lastActiveLaneID:snapshot:)` — and the reason there is no last-active-lane
+    /// fallback here. A board payload can *append to a lane*, so "nothing selected" still has an
+    /// answer; a picture has to land in some card's `attachments/`, and there is no card the app
+    /// could pick without inventing one. So an empty selection, a lane selection and a trash
+    /// selection all answer `nil`, the menu greys out, and the user selects a card — rather than a
+    /// screenshot silently arriving on whichever card the app guessed at.
+    static func card(selection: ItemReferenceSet, snapshot: BoardModel) -> ItemID? {
+        NewCardTarget.flattenAnchor(selection: selection, snapshot: snapshot)?.anchorCardID
+    }
+
     /// The lane payload's slot among the board's live lanes — **always an answer**, zero-lane board
     /// included, because lane paste "stays enabled and lands at the board's right end" whatever the
     /// board holds. That is what makes it the other way out of a board with no lanes.