# Bug-report widget (https://docs.vitrinka.ai/qa/report-widget)



## What it is [#what]

`<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.

```html
<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 [#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](/security/redaction).

## Quarantine and review [#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](/operator/connectors#jira); otherwise promote it from the Reports panel.

## Configuration [#config]

`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](/dev/api/http).