Issue Reporting Form for Product Bugs and Problems

You are improving an existing product surface for this audience: Product, QA, support, and operations teams adding issue reporting to an existing app or web product.
Do not redesign the whole product. Add or refine only the form, survey, widget, or intake flow described here, and preserve the current brand, layout system, components, typography, color tokens, spacing scale, icon style, and content voice unless a change is required for usability or accessibility.

Goal:
Add or improve an issue reporting form inside an existing product so users can report bugs, broken links, incorrect data, or confusing behavior with enough context for the team to reproduce it.

Existing context to inspect first:
- Identify the current primary task, where the user has just come from, and what they still need to do after this form or feedback moment.
- Reuse existing form controls, buttons, field validation patterns, banners, sheets, dialogs, toasts, loading indicators, and analytics/event naming where available.
- Keep the visual treatment subordinate to the task. The enhancement should feel native to the current app or site, not like a pasted-in third-party widget.

Layout and content hierarchy:
- Start from an existing help, feedback, overflow menu, error boundary, or broken-state entry point and keep the current page context visible where possible.
- Use a structured first section for issue type, affected area, severity, and whether the problem blocks the user.
- Ask for expected behavior, actual behavior, and steps to reproduce as separate fields with short examples.
- Show captured metadata such as URL, browser, device, app version, and timestamp in a reviewable details area before submission.

Interaction behavior and states:
- Pre-fill environment and page context automatically but allow users to remove sensitive metadata or screenshots before submitting.
- Let users attach screenshots, logs, or files with visible progress and remove controls.
- If a matching known issue exists, show it after the user selects issue type or enters a title, but do not discard their draft.
- After submit, show issue ID, status expectations, and whether the user will be contacted.
- Include these states with explicit UI copy and behavior: blank, metadata detected, file uploading, known issue suggested, validation error, submitting, submitted, offline saved draft, failed retry.

Mobile and responsive behavior:
- Use stacked sections with short helper text and large radio targets for severity and issue type.
- Support mobile screenshot attachment and make metadata review collapsible after it is acknowledged.
- Keep save draft or retry visible when connectivity fails.

Accessibility requirements:
- Each textarea and file input must have persistent labels and concise examples.
- Validation must identify the invalid item in text and preserve user-entered reproduction steps.
- Attachment controls must be keyboard operable and expose progress, success, and remove actions to assistive technology.
- Severity must be described in words, not only by color labels.

Implementation constraints:
- Route reports by issue type and severity to existing bug tracker, support queue, or operations inbox.
- Define hidden metadata fields clearly and avoid collecting secrets, tokens, full payment data, or personal data not needed for debugging.
- Use duplicate detection as assistance, not as a blocking gate.
- Emit events for report opened, issue type selected, attachment added, duplicate viewed, submitted, and submission failed.

Quality checklist before finalizing:
- The form separates expected, actual, and reproduction steps instead of using one vague message box.
- Captured metadata is transparent and removable where privacy risk exists.
- Known-issue suggestions do not erase the draft.
- The confirmation state gives users a reference ID and next-step expectations.
- Failure and offline recovery states are specified.

Output format:
- Return the proposed UI as an implementation-ready brief or code update appropriate to the existing project.
- Include component structure, field labels, validation copy, success/error copy, analytics events, responsive behavior, and handoff notes.
- Do not use placeholder text, fake image boxes, a new design system, a new framework requirement, or broad phrases like "make it modern".