feat: board ⌘V lands clipboard files and screenshots (goal 0255) - #533
Merged
Conversation
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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):
clipboard.ReadFileURLs(JXApublic.file-urlper pasteboard item) feedsAtlasService.ReadPasteboardFilePaths(fail-closed nil, undo-exempt read door); the paste door routes real paths throughlandFilesfor 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).NSFilenamesPboardType-only registration — deferred with a home (BACKLOG 0P0-PROMISE).Rider fix the commit gate itself caught:
clipboard.WatchChangesfired 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