Browser proofs

Tests tell you that the code works. A browser proof shows you. When a story changes something people see, such as a page, a form or a dialog, kanman opens the app in a real browser, goes through the flow a person would, and records it. You watch the recording instead of taking kanman’s word for it.

What a proof is

A proof is a short video of kanman using your app, with a list of named steps next to it:

• Actions: what kanman did, in plain words, for example “Open the login page” or “Click Save”.
• Checks: what kanman expected to see, for example “The toast says Saved”. A check passes only when the page really shows it.

Each step has its time in the video and a screenshot. Click a step to jump there.

A proof belongs to its story. kanman records one when the change is visible to people; a change without anything to see, such as a database migration or a background job, is proven by your CI and the review alone. See How kanman checks its work.

Where to watch it

You find the same proof in every place you follow the work:

• On the story: the story’s log shows the proof as a card. Open it to play the video with its steps beside it, or open the proof on its own page to share a link to it.
• In the conversation: the line kanman keeps for each story carries a small proof chip. Click it to play the proof without leaving the conversation.
• In the agent session: while you follow a story’s work live, its proofs appear there as soon as they are recorded.
• On the merge request: kanman posts a comment with the outcome, the steps and a few key frames, so reviewers see the result on your code host too.

The player works with the keyboard: Space plays and pauses, the arrow keys step through the video, F switches to full screen. On a phone, All steps opens the step list from the bottom of the screen.

Passed and failed

• Passed: every check found what it expected and the flow ran to its end.
• Failed: at least one check did not find what it expected, or a step could not be done. The step is marked red with the reason, for example “Text not found”, and the proof shows “1 of 5 failed”. kanman fixes the change and records the proof again; it never presents a failed proof as done.
• Cut short: the recording stopped before the end, for example because it reached its length limit. It counts as unproven, never as passed.

A failed proof is useful too: it shows exactly where the flow breaks, as a person would experience it.

Which hosts a proof may open

A proof runs against the app kanman starts for the story from your repository, on the run’s own machine. Beyond that, the browser opens only the hosts your team allows, the same list that limits internet access while kanman works. Production is never opened unless your team lists it.

To allow a host, for example a staging environment, add it on the Team tab under Agent and models > Internet access. When a proof tries to open a host that is not allowed, the step shows that the host was blocked and names it. See Internet access while the agent works.

Against a preview from your CI

When your CI deploys a preview for a merge request (a review app or preview environment), kanman can record the proof against that preview instead of starting the app itself. kanman reads the preview’s address from your CI, from the deploy job’s environment; it never uses an address from elsewhere.

A proof runs against a preview only on the hosts you list under Agent and models > Internet access > Preview hosts, for example *.review.example.com. A production environment is opened only when its own host is listed there; a wildcard never covers production. Without preview hosts, proofs run against the app kanman starts.

A proof against a preview says so on its card: Against preview and the address, and the merge request comment names the environment.

Recordings never show the passwords kanman types: they are hidden in the video, the steps and the merge request comment.