Skip to main content
Every feature test run produces a complete evidence package. The harness records all of it automatically; the test doesn’t write any of it. This page walks the layers in the order a reviewer meets them in the PRD view’s drawer.

​
Video, in both themes

The flow is recorded twice, in light and dark themes, from a real browser driving the real app. Playback is made watchable automatically:
  • actions are paced, with a visible cursor and a click ripple wherever the user clicks;
  • typing appears keystroke by keystroke, so you can read what was entered;
  • each step shows who is acting and what permissions they hold;
  • each step’s label is shown as the flow progresses.
The player syncs the step timeline to playback: click a step to jump to it, and the current step highlights as the video plays. A theme toggle switches between the two recordings.

​
The step timeline

Every prd.step and prd.verify becomes a timeline row, in execution order: actions with their labels, assertions with ✓ or ✗. Service calls appear as rows too, grouped under the step that caused them, so “they clicked Generate” is immediately followed by what the app sent because of it.

​
Setup and end-state data

The drawer shows two database snapshots: Setup data, the seeded world the test started from, and End state data, every table as the flow left it. Together with the video they answer both halves of “did it work”: the screen showed the right thing, and the database ended in the right state. A flow that renders success but writes nothing, or writes the wrong rows, is caught here.

​
Service calls: what the app sent

Every call the app made across the service boundary is captured with its full payload and shown under Service calls (what the app sent): the LLM prompt exactly as constructed, the Slack message exactly as it would post, the query exactly as it would run. Calls made by a workflow the test triggered are tagged as workflow-originated, so “the app called this directly” and “the pipeline called this” stay distinguishable. Two properties make this layer more than a debugging aid:
  • It’s a data-egress audit. A reviewer can read, for any flow, exactly what data would have left the app, including whether another user’s data ever appeared in a prompt or a message.
  • It’s assertable. Tests pin these payloads down with service-call assertions, including negative ones proving out-of-scope data never left. See Services and workflows.

​
Failures capture everything too

A failing run produces the same package as a passing one: both videos, the timeline with the failing step in red and unreached steps in gray, both data snapshots, and every call up to the failure. The planned steps that never ran still appear, so you can see how far the flow got and what remained.

​
Where it all lives

Recordings and manifests are written to prd/recordings/: one .webm per theme per entry, plus a manifest carrying the timeline, snapshots, and captured calls. They ship with the published app, so reviewers of an installed app see the same evidence the builder saw. An interactive Playwright trace is also captured for step-by-step debugging beyond the video.