Add composer attachments with upload and recovery states

[morgmart]

Rework in progress — attachments on the existing composer

Keep file selection, previews, upload/retry/remove and attachment-only sending, but reconnect them to the existing source-backed editor. No rich-text replacement or formatting commands are part of this PR's new scope. Preserve source text, selected notification recipients, scoped drafts and existing editing behavior.

The published code is still the old stack at e35435d73f05c24a3a5a1a24ae4a64f9c70eda69; it has not yet been rebuilt on the appearance/prompt changes. #119 and #121 are being reworked independently. #118 is retired, with its branch preserved for reference.

Current blocker and approved behavior

Standalone new sessions try to upload before the conversation exists; the existing session access check rejects that upload. Child-session composition currently passes the parent channel as the upload destination.

Approved by Morgan on September 23, 2026: keep files local until the user presses Send across all composer destinations, including existing conversations, threads, and new sessions. Selecting, previewing, or removing a file must not upload it. For new conversations, create/confirm the conversation after Send, then upload against its actual access-checked destination and publish. Reuse the created conversation and successful uploads on retry, allow attachment-only first messages, and cancel rather than redirect pending work when the destination changes. Preserve existing same-event retry for uncertain publication. Do not weaken permission checks or create conversations merely on file selection.

Agreed smaller delivery sequence

Extract attachment-only work onto current main, preserving the shipped source-backed editor and inline mention chips. Do not carry forward the old editor replacement, formatting, or unrelated styling changes.

1. Safe upload/download support, without exposing new composer controls yet. Extracted into draft Add safe attachment upload groundwork #150 on current main (499 changed lines including tests); composer enablement remains separate.
2. Attachments in existing conversations: file selection, previews/removal, upload on Send, attachment-only sending, and failure recovery as one complete user-facing slice.
3. Attachments in the first message of new conversations, including destination-correct uploads and retry without duplicate conversations.

Paste/drop and automatic media-metadata cleanup are separate follow-ups. Permission checks, cancellation, and failure handling ship with the relevant slice, not as later hardening. This records the agreed direction, not completed implementation or validation.

Failure recovery while the composer remains open is distinct from persistence across application restart. Local file recovery after restart is not implemented or promised.

Validation status

No new implementation or test results are claimed by this scope update. Previous results below cover the old stack, not the planned rework. Required gates include new-session creation/upload/send and failure recovery, permission rejection/cancellation, source/recipient preservation, responsive layouts and independent review. Deployed uploads and native packaged behavior remain unverified. No merge is authorized.

Historical implementation and validation notes (old stack)

What changes

Adds file selection, compact attachment chips and image thumbnails to the composer. Upload failures expose Retry and Remove; attachment-only messages can send. Upload availability gates selection/retry, and destination changes cancel pending work. Includes broker upload/download support and catalogue examples.

This is 5/5 of the preserved composer split, based on contextual prompts morganm/composer-contextual-prompts (#121), not main. Review only this attachment delta. Original source is preserved; capability correction remains a separate commit.

Known blocker — not merge-ready

First attachment in a new standalone session fails permission checks before the conversation exists. Selecting a file can disable Send until removal. The correction touches protected session lifecycle ownership and awaits Morgan’s explicit guidance. It has not been disguised by the passing catalogue fixture. Independent review cleared only the separate unsupported-connection capability repair, not this whole slice.

Validation

At clean published e35435d73f05c24a3a5a1a24ae4a64f9c70eda69, based on prompts 6fc1712:

• All 195 unit files / 2,082 tests pass.
• Complete emoji/GIF/typing/catalogue/typeahead files pass72/72 across Chromium/WebKit (1.4m), including14 catalogue cases with real file picking, failure/retry, attachment-only send, wrapping chips and image thumbnails.
• Normal mandatory push hooks pass: units, types, design types/guards; no bypass, retries or increased timeouts.
• Both attachment commits are patch-identical after restacking onto the reviewed editor/controls fixes.
• Two attachment browser cases cover native file selection and layout; queue, upload admission and capability states remain at lower layers. Catalogue success does not prove real new-session permissions.

Remaining gates

First-message defect above; hosted CI/native/tool checks; inherited composer-link presentation decision. Real deployed upload/native packaged acceptance unverified. The inherited broker timing assertion, typing-layout repair and fixture corrections are independently approved; Carl cleared inherited integration at e35435d using exact patch comparison and validation logs; first-session P2 remains open, so this is not whole-PR approval. Fresh CI: https://github.com/block/buzz-app/actions/runs/35697568185. No merge authorized and no whole-stack readiness claimed.

Latest hosted findings — not ready

Fresh hosted browser runs exposed an interaction missed by the bounded typing review: the form-anchored typing indicator overlaps the agent-activity accessory and intercepts hover/clicks. Owner has traced the actual failure; placement repair is pending. Do not treat the earlier typing/catalogue checks as full acceptance.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes required: one P2 attachment-lifecycle blocker, already acknowledged in the PR description. This review confirms the published implementation, not the planned rework. The queue/UI and transport/security lanes found no additional independently substantiated blocker in the attachment delta.

Reviewed head e35435d73f05c24a3a5a1a24ae4a64f9c70eda69; current base 33272e5ed137896af9ff4d4662bef68851d241ee. Isolated the 18-file attachment delta against historical stack parent 6fc1712964a8c59273e21025fbd7b12783fd75c4 rather than treating the superseded editor stack as new attachment work.

Exit criteria: implement the approved Send-owned lifecycle on the existing source-backed composer, preserving recipients and drafts, destination cancellation, successful-upload/conversation reuse, and same-event uncertain-publication retry. Prove the real new-session create/confirm → upload → publish path with completed roster discovery, including failure/retry and attachment-only submission. Do not weaken the permission check.

Validation limits: source review plus existing CI, no local test rerun or live/native upload claim. The two added attachment catalogue cases passed in Chromium and WebKit, but bypass real new-session admission. Run 35697568185 tested historical merge bb6d62ba872e5d5af939fdda8da2b10ab7aa3c57 (tree identical to the reviewed head), not the rewritten current base. Both engines failed the activity-tooltip and composer-link-rendering journeys; these remain separate old-stack integration gates, not newly attributed attachment defects. The PR is still draft and conflicting.

[wesbillman]

[P2] Keep selection local and let Send own destination creation and upload

add() calls pump() immediately, so choosing a file uploads before Send. Besides violating the approved local-until-Send contract in existing conversations/threads, this prevents a normal standalone new session from sending its first attachment: NewSessionComposer passes its fresh UUID as channelId (line 283), MessageComposer uploads against that ID (lines 135–139), and session.attachments.upload rejects it after completed roster discovery (session.ts:784–786, discovery.ts:73–77). The failed file keeps attachments.blocked true, so Send cannot reach the creation step (NewSessionComposer.ts:127–135). Retrying the file repeats the denial; removing it is the workaround. Child-session composition instead checks/uploads against the parent ID before the child exists.

Keep file selection/preview/removal local. On Send, use the existing new-session owner to create/confirm the actual destination, then upload and publish; reuse the conversation and completed uploads on retry. Retain the permission boundary and same-event publication retry. Add a real-session regression with completed roster discovery, not only the permissive catalogue fixture. This is the already-recorded blocker, not a separate new issue.