Recorded sessions

Record the run

Start the browser recorder and test as you always do; inside your own web app — on a phone, where extensions do not run — it is the web recorder, and in a mobile app the Expo journey recorder. 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

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

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.
• 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. Configured synchronisation transfers supported changes between the ticket and the report.

What you see, and what you stop doing

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.