Mocked reporting-session interface#

Question: which layout makes the edge-launcher capture, review, settings and ticket-playback flow easy to use before real adapters are implemented?

Owner: Prototype the mocked in-page reporting interface before adapter implementation, within the modular reporting map. The user explicitly selected UI-first sequencing. This is an evolutionary prototype under the repository's full production quality policy. Q13 selected the compact direction, refined as a smaller right-side drawer with separate Capture, Replay and Settings tabs; final flow acceptance remains pending.

Run pnpm dev:examples and open the printed URL with playground/branding/?page=reporting. Alternatively pnpm prototype:theming serves the verification host at branding/?page=reporting. For local-network access, set SNAGBADGER_HOST=0.0.0.0 before starting and use this computer's LAN IP with the printed port.

The user selected C and removed D/E. The compact drawer is the only layout; old variant URLs render C, and there is no variation switcher. Its 400px right-side panel has separate Capture/Replay/Settings tabs. Capture and Replay use a maximum 680px height, vertically centered with at least32px space above/below on small screens. Settings remains content-sized and capped at680px. The badger launcher becomes a close tab attached to the drawer’s left edge and travels with its slide animation. Hover reveals the launcher; clicking slides the drawer and attached button out together. The drawer reserves56px on the left for this tab so both fit narrow screens. Replay guidance appears beneath the picker and disappears after loading; Capture has no introductory paragraph. Enabled-method settings have modest inner padding; nested checkboxes indent at each level without vertical bars. Exclusive choices with at most three options use keyboard-operable rectangular text selectors on a shared track; larger sets use a dropdown. The tabs and Start remain visible as options scroll. Narrow screens fit the available page width; reduced-motion preferences skip the slide.

The drawer retains the accepted warm styling, caped badger and mono reporting typography. Capture methods and harvesters have small gadget illustrations with smiling sidekicks. Checkbox inputs retain their native accessible semantics with rectangular switch-style tracks and checked knobs on the left with a check mark and unchecked knobs on the right. The tabs form a flush header with an active underline; the drawer has a continuous outline and thin themed scrollbars. The edge launcher inherits its host-style font, reveals on hover/focus, and remains usable with touch and keyboard. The top SNAGBADGER/BUG CATCHER and MOCKED strip is removed; the host prototype banner and fixture previews still identify mocked behavior.

Try the flow#

The reporter is a non-modal fixed drawer with a default z-index of40. Developers can set demoConfig.ui.zIndex or pass zIndex to the prototype component; Developer fixture configuration also exposes Drawer z-index for live stacking experiments. It does not use the browser’s modal top layer or make the host inert, so higher host/T3 overlays stay interactive. Escape closes the reporter only when keyboard focus is inside it; the close tab restores launcher focus. The final production configuration contract remains separate implementation work.

1. Open the right-edge launcher and choose screenshot, interaction steps and screen recording. Screen recording reveals a method selector for Visual replay or Screen video, exclusively, with settings beneath the selected methods. Disabling/re-enabling recording retains the selected method. Screenshot method selection represents both required mechanisms. Pre-recording is off by default. Checking it reveals a notice that it requires a page reload; this prototype only displays the notice.
2. Start. Screenshot-only opens review immediately; recording selections close the dialog and make the launcher Stop. The host stays usable. Pause/resume/cancel change only demo state.
3. Stop and review the report template. Preview attachments, exclude evidence, draw/highlight on the illustrative screenshot or use the keyboard-accessible Mark problem/Undo controls. Try the mock replay/video timeline.
4. Select a destination and use Demo login for Jira/Linear. Shared-device mode requires a selected account's mock PIN (Morgan: 1234, Alex: 2468) before creating a demo ticket. Switching accounts, closing the reporter or submitting locks access again. Completion states exactly what would be included and excluded; nothing is submitted or downloaded.
5. Use Replay. Provider toggles, URL/ID/title autocomplete and Load share one row. Suggestions extend left from the search field to stay inside the drawer, including on phones. Load starts enabled for QA-42. Load displays a plan; Play stays above the separately scrollable steps and preview. QA-43 represents missing recording and QA-44 access denied. Unknown tickets show a no-match state; empty search disables Load. Local replaces search with a file picker; selecting a file enables Load. This UI mock uses only the filename and shows a fixture plan, without parsing or importing its contents. URLs are never fetched.
6. Settings expose master HTTP/WebSocket/browser/app switches with nested subsettings and multi-level checkboxes. Turning a parent off hides its children and stops that branch; re-enabling preserves child choices. Disabled payload settings cannot be enabled. Connected provider sections collapse after demo login.
7. Open Developer fixture configuration in Settings to compare Jira-only versus Jira + Linear registration, or single-account versus shared-device multiple accounts with PIN. Provider menus and connection sections follow this fixture registry.

Prototype state and a simulated display-permission failure are available below the host. Stop/cancel resets pre-recording. Escape closes the dialog and restores the launcher focus. C's tabs support Left/Right and Home/End keys; choices survive switching tabs.

Mocked boundaries#

No real screenshots, screen streams, network instrumentation, rrweb events, provider authentication, submission, executable reproduction or persistent storage are implemented. The screenshot is an SVG fixture with real in-memory annotation controls; replay/video use animated local fixtures. Local export/import and provider file retention/retrieval remain implementation work. Later-stage capabilities are shown to judge the complete interface without bringing their implementation into the first stage.

Automated browser scenarios live in testing/journeys/reporting-session.spec.mts and reporting-options.spec.mts; run pnpm test:browser reporting-session.spec.mts reporting-options.spec.mts. Full verification and observed source-bound T3 evidence are required before handoff. C is selected; final flow acceptance remains with the user.

Local simulated lifecycle and recovery#

The reporter keeps its Capture/Replay/Settings tabs and configured capture/harvester choices. A local lifecycle module owns simulated pending work, recording timers and playback; rendering invokes its actions and subscribes to immutable snapshots. Pending capture and replay loads offer Cancel. Development fixtures can hold operations for five seconds to exercise cancellation; no real collection or provider request occurs. Local replay files still supply a filename only, never parsing or network access.

Failed/cancelled replacement keeps a clearly labelled retained mock plan; successful selection replaces it, including QA-43's truthful missing-recording result. Start/Stop playback restarts from the first frame on every Start. Capture Pause/Resume remains. Explicit Retry uses current choices, while each pending attempt captures a stable selection. Closing/unmounting cancels pending work and stops timers; React StrictMode reattachment keeps only an already inactive owner alive, while actual unmount permanently disposes it.