How a session works

A session is one persona's visit to your product. The scheduler (or a Run with instructions click) starts it; from there the persona works on its own and hands back a report, a video, and updated memory. It never files a ticket — that's the Dogfooding Ranger's job.

What happens in a run

1. Becomes the persona. It loads who it is — its prompt (or backstory), its focusArea, this session's goal, its memory from past visits, and the targetUrl and login info. It reads its memory first, so if something was broken or missing last time, it goes back to check whether it's been fixed instead of repeating the same probing.
2. Reads your app from source. When a GitHub repo is connected, it shallow-clones it read-only to map which URL serves which feature — so it heads straight to the relevant surfaces. It never pushes or commits.
3. Drives a real browser. It exercises the flows hard with Playwright (Chromium), on the persona's desktop or mobile viewport, logging in with the throwaway account when the goal needs it. The entire run is recorded to one video.
4. Writes findings. The deliverable is a terse, evidence-based report — worked / broke / missing, each item tied to a specific screen and action, no scene-setting or mood — plus each concrete finding saved as a structured observation.
5. Updates memory. It records what it learned so the next visit builds on this one. One-off Run with instructions direction is deliberately not written to memory — it applies to that session only.

A directed session

When you use Run with instructions, your text becomes the spine of that visit — the persona pursues it thoroughly, but still as itself, in its own voice and from its own perspective. The instructions say what to look at, not who to be, and they apply to that one session only.

What a session produces

• A report — worked / broke / missing, tied to concrete screens and actions.
• Structured observations — one per finding, typed worked | broken | missing | friction, with evidence. These are what the Ranger reads across sessions.
• A video — the full run, playable inline (the same player used by QA and Story QA).
• Updated persona memory — carried into the next visit.

Open any past run from the session list on the Dogfooding tab to watch the video and read the report.

From sessions to tickets

A session deliberately stops at observation. The daily Dogfooding Ranger is what reads the completed sessions, groups the same underlying problem across personas and days (worked observations are kept as counter-evidence), and turns corroborated problems into tickets — always flagged as synthetic evidence, since recurrence across personas raises confidence but isn't real-user prevalence. This split is why one agent never both drives the browser and decides what lands on your board; see Discovery & Rangers for the model.

Notes & limits

• Read-only by design. A session uses your product; it never changes code, data, or your board.
• One video per run. The whole session is a single recording — no per-step clips to stitch together.
• Source is a map, not a requirement. No connected repo just means the persona explores from the target URL without the route map; it still runs.
• Credentials never surface. The throwaway login is never printed, logged, screenshotted, or written into observations.