feat: import project files into a chat session via drag-and-drop

[selloriwoo]

Overview

Adds an end-to-end flow for pulling project files into a chat session as attachments.
A shared-file browser lives in the session's right sidebar, and files/folders can be dragged from there (or from the Files page) to attach them to the next message.

Features

1. Sidebar shared-file browser — browse the project's shared files in the right sidebar with folder navigation (breadcrumb, back, home + project name).
   A bottom segmented toggle switches between Info ↔ Files; the active tab is accent-highlighted.
2. Drag-and-drop to attach
   • Sidebar browser → chat: adds to the next message's attachments (no upload — references the existing shared path).
   • Files page → a session row in the left nav: navigates to that session and attaches.
   • Dropping a folder expands it into the files it contains, recursively (skips .keep/dotfiles).
3. Marquee multi-select + bulk drag — rubber-band select files and folders from empty space, then drag the whole selection at once.
   Selection keeps up while scrolling mid-drag; the box is clamped to the list bounds.
4. Attachment cap — 30 on the frontend (overflow dropped with a toast) plus a server-side hard ceiling of 30 in validate_attachments (with a unit test).

Internal / refactor

• Extracted the marquee selection logic into a shared useMarqueeSelection hook (used by both the Files page and the sidebar browser).
• Dedupe/cap attachments inside the state updater so it's idempotent (prevents StrictMode double-attach).

UX polish

• Sidebar rows: color-chip icons + drag handle; long names ellipsize.
• Uniform accent drop-zone overlay on the chat while dragging (replaces the ragged text selection).
• Fixed file-row selection fill (cleaned up conflicting legacy CSS).

Verification

• Frontend tsc -b passes
• Backend cargo check passes
• Backend Attachment-cap unit test passes
• Core drag-and-drop flows exercised manually in local dev

Notes

• .keep is a placeholder the backend writes when an empty folder is created, so it's excluded from listings/attachments (consistent with the Files page).

[selloriwoo]

Follow-up

Sidebar preview — double-click a file in the sidebar shared-file browser to open it in the in-app preview.

Over-cap imports — attaching >30 files now rejects the whole batch (was: kept first 30) with a toast. Files→session drops pre-check the count and stay put instead of navigating then rejecting.

Attachment source marker — left of the file icon: accent folder = shared-file reference, muted clip = upload. In both the composer and message history.

[ljhh-0611]

The cap check moved out of the setPendingAttachments updater, so it now reads the stale closure pendingAttachments instead of the authoritative prev. Two imports that race before a re-render — most realistically the async attachShared effect path, which calls importSharedFiles after await fetchQuery — both read the same stale length, both pass the pre-check, and the updater only dedupes. Distinct-file batches can then push the total past MAX_ATTACHMENTS. Over the cap, send hits the backend 400, and since send() clears the composer/attachments before await, the draft is lost.

The pre-check above stays as the UX fast-path (early return + toast). Restore the hard clamp inside the updater so the invariant holds under the race — it's a no-op on the normal path (already <= MAX):

Suggested change

	const toAdd = fresh.filter((it) => !existing.has(it.globalPath));
	const toAdd = fresh
	.filter((it) => !existing.has(it.globalPath))
	.slice(0, Math.max(0, MAX_ATTACHMENTS - prev.length));

[ljhh-0611]

Out of this PR's strict scope, but the new backend attachment cap turns this pre-existing path into data loss:

• handleFileSelect appends every picked file with no client-side cap (unlike the shared-import path, which caps at MAX_ATTACHMENTS).
• send() clears composerText / pendingAttachments before await sendMessage(...) and the catch doesn't restore them — so any send failure (network, 403, 423, and now the 400 from >30 attachments) drops the user's typed text and attachment tray.

Pick one (or both):

• Light (in this PR): cap handleFileSelect like the shared-import path, so the UI can't reach the backend 400.
• Root (can be a follow-up): capture pendingAttachments before clearing and restore it (with setComposerText(text)) in the catch, so drafts survive any failed send.

Not blocking — flagging because the new cap is what makes the >30 case reachable.

[grf53]

In my personal opinion, regarding the inclusion of more than 10 files in a message, I believe it is more appropriate to encourage the use of alternative methods such as the following; however, the actual user requirements seem to be the most important factor.

• Encourage the AI ​​to directly find relevant files using methods such as glop, search (or grep) (~= encourage the use of Speedwagon first)
• Encourage requests to be received by dividing them into multiple messages in stages.

That said, blocking the inclusion of more than 10 files could lead to user inconvenience, and 30 seems to be an acceptable number in this regard.

[selloriwoo]

Applied the Light fix: handleFileSelect now caps at MAX_ATTACHMENTS (rejects the whole batch + toast, like the shared-import path) so the UI can't hit the backend 400.

[ljhh-0611]

Follow-up polish: shared-file panel, selection, and attachment chips

Pushed a few rounds of refinement on top of the base PR (642519b…f7272d2). What changed and why:

Marquee (rubber-band) selection — useMarqueeSelection

• Restored the screen-wide selection box. It had been clamped to the list view; the hit-test already used the full rect, so only the drawn box had regressed vs main.
• Fixed a listener leak — the post-marquee "swallow click" listener is now removed on unmount.
• Fixed selection getting dropped on release. Releasing the marquee with the cursor over the file view cleared the selection: the swallow listener was being torn down by the [dragRect] effect cleanup before the click it needed to swallow. Cleanup is now deferred to an unmount-only effect, so it survives the gesture (and still can't leak).

Sidebar shared-file browser — SharedFilesPanel

• shift+click now range-selects, meta/ctrl+click toggles — matching the Files page.
• Folder rows: single-click selects, double-click enters. File rows: double-click previews.
• Dropped the right-side child-count / kebab menu (felt noisy). Rows are just icon + name; the type icon swaps to a quick-add + on hover (neutral border that deepens on hover; the + glyph stays accent).
• Surfaced the previously-unused shared_files.drag_hint caption under the breadcrumb, and removed the 6-dot grip (it read as drag-to-reorder, which this list doesn't do).

Selection color — cowork-design-system.css / globals.css

• Unified the selected-row fill as an accent wash via --cw-selected-bg / --cw-selected-bg-2 (with a distinct selected+hover step), applied to the Files page rows/cards too.

Attachments

• Shared-source attachments now use a cloud glyph (was a folder) to read as "from project storage"; composer uploads keep the paperclip.
• Pending attachment chips: removed the × button — the whole chip is now click-to-remove and turns red on hover to signal the destructive action.

Frontend tsc -b passes; flows exercised in local dev (Vite).

🤖 Generated with Claude Code