feat(server): accept PDF, ZIP, and other file uploads up to 50MB - #8235

💭 I want to check the in-scope web files—types.ts, ChatView.logic.ts, ChatView.tsx, and MessagesTimeline.tsx—since the changes are purely type-level, adding an isImageAttachment guard and filtering, with no UI changes. I need to verify removing TimelineEntry/TimelineMessage types doesn't break anything else in MessagesTimeline.tsx.

1. git_tools — TimelineMessage|TimelineEntry

2. git_tools — isImageAttachment|attachment.type

💭 I should check other places in the web codebase that read image-only fields on attachments without guarding, like ChatView, composer, and attachment previews. Since the union type has an open string member, a simple literal comparison won't properly narrow the type, so TypeScript might not catch unguarded reads unless the code explicitly casts. I also want to know whether other components rendering message attachments would now let non-image attachments slip through and get rendered as broken images instead of being filtered out — I should search apps/web/src for other spots referencing attachments beyond the ones already filtering.

3. git_tools — attachments

💭 I want to check ChatView.tsx around lines 2490–2670 for any unguarded reads, like the map at line 2532 or the loop near 2499.

4. browse_code — apps/web/src/components/ChatView.tsx

💭 I'm checking whether attaching previewUrl to every attachment, including non-image types, causes a typecheck issue with the ChatAttachment union when spread into an object literal — excess property checks might flag it since non-image members don't declare previewUrl. Now I'm verifying whether the imageIndex logic at 2645 correctly increments only for image attachments, and confirming that clearAttachmentPreviewHandoff's length comparison at 2563 holds up since it only collects preview URLs from images. Next I want to check MessagesTimeline around lines 980-1040 and 1700-1740 to see if the annotation card or preview logic assumes indices align with the unfiltered attachments array.

5. browse_code — apps/web/src/components/chat/MessagesTimeline.tsx

💭 This button is a pre-existing raw element with cursor-zoom-in tied to an image target, so it's excluded by the rules. The actual web changes are type-only additions—a guard and a union—with no visual impact; the practical effect is that file attachments in user messages simply won't render on web yet, which matches the documented intent in types.ts since web can't upload files until composer support catches up. Now I want to check historyBootstrap.ts, where it filters attachments by comparing type to "image" directly rather than using the new guard, and see whether that still typechecks and what it does with the resulting image attachments.

6. browse_code — apps/web/src/historyBootstrap.ts

💭 This filtering behavior is pre-existing and still correct for image-only summaries, though the patch could make file attachments relevant since they won't appear in the bootstrap transcript—but that's a product decision beyond UI consistency scope. I'm now checking whether the isImageAttachment guard is used consistently everywhere image-only fields are read, starting with historyBootstrap. ts, and confirming the ChatAttachment type change doesn't break other consumers like attachmentUploadQueue.ts before grepping for other previewUrl reads in the web source.

7. git_tools — previewUrl

💭 Everything checks out consistent - no UI violations in the scoped files, and the changes remain minimal and type-level without touching styling or environment routing. I want to double-check that ChatView.logic.ts's use of isImageAttachment aligns properly with the attachment types, so I'm looking at lines 274-305 to confirm. Let me also check whether a similar guard already exists elsewhere, like in contracts, so I'm not duplicating logic - I'll grep repo-wide for isImageAttachment rather than limiting to web.

8. git_tools — isImageAttachment|type === "image"

💭 There's a tension between the plain-text instruction to output exactly "All clear" and the system's JSON schema requirement. I'll resolve this by following the schema, marking the state as success since there are no findings, and including "All clear" as the summary content.