Support pasting images into the 'Report Feedback' copilot window

[danthebaker]

Resolves danthebaker/gatewaze-roadmap#28

Gates

• adversarial review: pass
• security: pass
• blast radius: needs_human

Spec

Let me explore the actual code to ground the spec.I have a complete picture. Let me verify one portal detail — whether the portal already renders remote images (for the thumbnail lint concern) and confirm the module widget's UI imports.I now have everything needed. Writing the spec.Spec written to SPEC-issue-28-paste-images-report-feedback.md. Summary:

Memory check

Searched project memory first. Found and read three relevant pages:

• specs/issue-7 — paste images into the live run chat (built uploadChatImage + the reusable downloadAttachmentUrls).
• specs/issue-16 — images silently dropped on issue create (built the honest attachmentsAttached/attachmentsDropped response + client warnings).
• The SE-module project page (bucket, SSRF, §10.5 feedback surfaces).

This spec builds on #7 and #16 and does not contradict them: their server + upload machinery already exists; #28 just wires it into the two feedback widgets that never sent attachments.

Resolving the blocking review

Every objection is addressed:

• Server is complete → spec is explicitly client-only; no admin-routes.ts/attachments.ts change.
• se-feedback/ prefix passes SSRF → confirmed isAllowedAttachmentUrl is host/origin-only; answers the "where stored" question (existing media bucket, new path).
• The portal twin has the identical defect → spec targets two writable repos: gatewaze-modules (admin widget) and gatewaze (packages/portal/components/admin/ReportFeedbackWidget.tsx, live-mounted in app/(main)/layout.tsx). It states plainly that fixing only the module leaves portal reporters broken — correcting the earlier "no change in gatewaze" claim.

The change

Port the existing IssuesView paste→upload→thumbnail→attachments pattern into both widgets. Open questions answered inline (public media bucket / se-feedback/ prefix; 15 MB, image/*; up to the server's cap of 8). Flags portal-specific rules (next/image not raw <img>, hooks above the return null guard, no direct @radix-ui/themes), a test plan for both widgets, mandatory /security-review, and the localhost-drop UX carried from #16.

I explored read-only and did not implement anything. Verify the acceptance criteria against the file before implementation kicks off.