Bug-report widget
A report button inside your own app: a masked screenshot, the console tail, failed requests and optionally a flight-recorder replay, filed into vitrinka under quarantine until an admin approves it.
What it is
<vitrinka-report> is a web component served by your vitrinka deployment at /vendor/report-widget-1.mjs. Users can submit a report with a screenshot, recent console messages and failed-request metadata. Projects can also enable a rolling replay of recent activity. The project's profile controls masking.
<script type="module" src="https://vitrinka.acme.internal/vendor/report-widget-1.mjs"></script>
<vitrinka-report key="vkb_…"></vitrinka-report>The base defaults to the origin the script was served from, so the key is the one attribute you must supply. open-selector="#help-report-bug" binds a button you already have instead of the widget's own floating affordance. That script tag is the whole integration: the widget is never bundled into your app, it is served no-cache by the deployment that ingests the reports (on app.vitrinka.ai that is https://app.vitrinka.ai/vendor/report-widget-1.mjs), so the capture contract can never drift from the server. In a framework app, inject the same <script type="module"> once on mount and render the element; a typed wrapper package is not required.
The publishable key
Create a project-specific vkb_ key in Settings and include it in your page. It lets the widget read public configuration and submit reports for that project; it does not grant access to stored reports or attachments. Requests are rate limited per key. Submitted data is subject to recorder redaction.
Quarantine and review
A filed report is born quarantined. Its screenshot, events and replay chunks are staged on the report and reachable only through admin-gated routes — no session exists yet, so nothing a report carries can surface on a board, in search or to an AI review before a human looks at it.
| Action | Who | What happens |
|---|---|---|
| Inspect | workspace admin | Screenshot, console, requests and replay, in the review panel. |
| Redact | workspace admin | Drop entries, the screenshot or the replay before release. |
| Approve | workspace admin | The staging becomes a real session, the report lands as a card on the project's bug board, and an accepted bug task is filed in the project. |
| Reject | workspace admin | The report is closed and nothing is released. |
An approved report uses the same digest as a recorded session and can be read by a connected agent. With the project's auto-ticket switch on, approval also opens a ticket through the project's connector; otherwise promote it from the Reports panel.
Configuration
GET /api/v1/report-config is what the widget reads on load: the project's redaction profile (strict masks all text and inputs, keeps no network bodies and scrubs the console; balanced and full relax that for internal apps — strict is the default), whether the flight recorder is on, and whether an approved report opens a tracker ticket automatically. These are per-project triage knobs, so they are set from the header of the project's Reports panel, not in workspace Settings; the routes are listed in the HTTP API.