# Recorded sessions (https://docs.vitrinka.ai/qa/sessions)



## Record the run [#record]

Start the [browser recorder](/qa/extension) and test as you always do; inside your own web app — on a phone, where extensions do not run — it is the [web recorder](/qa/recorder/web), and in a mobile app the [Expo journey recorder](/qa/recorder/expo). The session captures the walk itself — screens, clicks, network calls, console errors, Web Vitals — plus every annotation you drop along the way. Stop the recording and the run lands as a session board: your screens in the order you walked them, issues attached where they happened.

For people who will never install a recorder — a colleague in the field, a pilot customer — the embeddable `<vitrinka-report>` widget files a single bug report from inside your own app, quarantined for admin review before anyone acts on it.

## The server keeps it light [#preprocess]

Raw recordings are heavy; nobody — human or AI — should have to wade through them. The server pre-processes every session into a compact digest:

* Runs of bare clicks on one screen fold into a single step; annotated or failing steps stay their own.
* Failing network calls dedupe on method, path and status — five 500s from one endpoint are one issue with a count.
* Console errors dedupe on message; Web Vitals summarize per route.

Agents can start with the digest and fetch details as needed. You can also replay the full recording in the browser.

## What the pipeline does with it [#pipeline]

The sessions skill guides a connected agent through these steps. What it can complete depends on its access to the repository, the test environment and your instructions:

* **Groups** the deduped issues into real workstreams — a session's thirty issues are usually a handful of causes.
* **Fixes what it can**, in the app's repository, closing each of your annotations with proof.
* **Writes e2e tests** for the journeys you walked, so the next regression is caught by a machine instead of by you; their runs land on the feature's [QA record](/qa/runs).
* **Verifies** by re-running those journeys and tracing the results onto the session board as a next pass, beside your original recording — before and after read at a glance.
* **Hands the remainder to developers** with the full reconstruction and its own observations attached, instead of a ticket that half-describes the issue.

If you use an external tracker, you can promote an approved report to a ticket through a [connector](/operator/connectors). Configured synchronisation transfers supported changes between the ticket and the report.

## What you see, and what you stop doing [#board]

The session board shows the original walkthrough, recorded issues and evidence added after a fix. It helps with:

* Writing reproduction steps — the session is the reproduction.
* Collecting screenshots and console dumps — captured as you tested.
* Checking a fix — an agent can add another pass to the same board and submit annotations for your approval.

<Callout type="warn">
  Sessions respect retention: a deleted recording stays restorable for a grace window, then is purged permanently — screens, events and blobs. Do not treat a session board as long-term documentation; that is what [documents and artifacts](/dev/skills/authoring) are for.
</Callout>