Skip to content

feat: board ⌘V lands clipboard files and screenshots (goal 0255) - #533

Merged
alicoding merged 1 commit into
mainfrom
feat/board-paste-clipboard-files
Aug 31, 2026
Merged

feat: board ⌘V lands clipboard files and screenshots (goal 0255)#533
alicoding merged 1 commit into
mainfrom
feat/board-paste-clipboard-files

Conversation

@alicoding

Copy link
Copy Markdown
Owner

Owner-reported on the installed build: screenshots and copied files never land on the Atlas board. Traced to three distinct causes (full trail in the goal file):

  1. Board paste of a files payload was an explicit no-op — fixed here. New clipboard.ReadFileURLs (JXA public.file-url per pasteboard item) feeds AtlasService.ReadPasteboardFilePaths (fail-closed nil, undo-exempt read door); the paste door routes real paths through landFiles for full drop parity (Finder ⌘C = drop), and falls back to the pasted bitmap's own bytes through the image tool's commit door (screenshot-to-clipboard ⌘V).
  2. File-promise drags (macOS post-screenshot floating thumbnail) are refused upstream by Wails3 darwin's NSFilenamesPboardType-only registration — deferred with a home (BACKLOG 0P0-PROMISE).
  3. Text-path paste already worked (⌥⌘C is the working Finder gesture) — verified live.

Rider fix the commit gate itself caught: clipboard.WatchChanges fired on pbcopy's transient empty pasteboard (measured live: baseline → "" → new value at the 20ms poll) — empty-text transitions no longer fire, which also stops spurious empty clipboard-history captures.

Proof: new board-level bitmap-paste e2e under the clipboard lock; PATH-stripped fail-closed unit; testing.md manual-registry entry for the OS-bound half; userdocs + SPEC + llms-full updated.

🤖 Generated with Claude Code

https://claude.ai/code/session_012im1JxQQV2ahnXzZDdVmZq

Board-level paste of a files payload was an explicit no-op, recorded
as 'real paths unreachable via the web Clipboard API'. True for the
web API -- but the host pasteboard has them: a new
clipboard.ReadFileURLs (JXA public.file-url per pasteboard item, same
bridge as Types) feeds AtlasService.ReadPasteboardFilePaths
(fail-closed nil on any error, undo-exempt read door), and the paste
door routes the answer through landFiles for full drop parity --
Finder ⌘C lands exactly what dropping the file would. With no paths
(a screenshot bitmap, a non-Mac host), the image File's own bytes
land as an image object through the image tool's existing commit door
at the pointer.

Rider fix the gate itself caught: clipboard.WatchChanges no longer
fires on a transition to empty text -- pbcopy's clear-then-set
exposes a transient empty pasteboard to a concurrent poll (measured
live at the watcher's own 20ms interval), and a non-text clipboard
reads as empty too; both were spurious captures.

e2e drives the bitmap branch window-level under the clipboard lock
(plain text written to the real pasteboard first so the host path
read honestly answers empty); a PATH-stripped unit pins the adapter's
fail-closed error. The OS-bound half (real pasteboard flavors, real
WKWebView ⌘V) enters testing.md's manual registry. Known-refused and
deferred with a home (BACKLOG 0P0-PROMISE): file-promise drags (the
post-screenshot floating thumbnail) are refused upstream by the
windowing layer's NSFilenamesPboardType-only registration.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012im1JxQQV2ahnXzZDdVmZq
@alicoding
alicoding enabled auto-merge (squash) August 31, 2026 00:21
@alicoding
alicoding merged commit 5aad980 into main Aug 31, 2026
30 checks passed
@alicoding
alicoding deleted the feat/board-paste-clipboard-files branch August 31, 2026 00:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant