Verified MergeRequired checkSigned evidence

Make your Playwright suite trustworthy.

Every pull request arrives with proof it was tested. QAFind runs the Playwright specs the change affects, reruns failures, and blocks only regressions it reproduces. Keep the repo, specs and CI you already have; one required check, one comment, a signed bundle.

Explore the sample console See how the check works

Attach in one config line
Plain Playwright + TypeScript
Signed evidence, free local format
MIT licensed · no account required

acme/shop #412Retry checkout on 500tests/checkout.spec.ts

qafind bot reviewed line 42 · just now

HIGH · testsDeterministic check

A fixed sleep makes this checkout test flaky.

A 3-second wait races the payment webhook on slow runners. Wait for the confirmation the customer actually sees.

Suggested change

41 await page.getByRole('button', { name: 'Pay now' }).click();

42−await page.waitForTimeout(3000);

42+await expect(page.getByTestId('order-confirmed')).toBeVisible();

Commit suggestion Reply confidence 0.98 · verified

QAFind browser run · checkout-flow 18/18 with the fix · receipt e2114ac9… signed

Built on tools engineers already trust

Playwright
TypeScript
GitHub Actions
Bun or Node.js 18+
MIT licensed

The moat / Verified Merge

Only a failure we reproduced can block the merge.

Most review bots can only guess from the diff. Most test dashboards only see pass/fail and retries. QAFind runs the affected specs, reruns the failures, and treats a failure that passes on rerun as a flake — never a regression. The verdict is signed, and the evidence can be verified offline.

01 · Select

Run the specs this PR affects

The CLI maps the diff to Playwright specs and runs them in your CI. Your suite, your browser, your staging target.
```
git diff origin/main...HEAD
→ tests/cart.spec.ts
→ tests/checkout.spec.ts
```
affected specs
02 · Reproduce

Rerun every failure

Failed specs run again in the same environment. Passed on rerun means flake. Failed again means regression.
```
first run   cart.spec.ts  failed
rerun       cart.spec.ts  failed
verdict     reproduced regression
```
deterministic triage
03 · Prove

Publish one check and one comment

The required context is QAFind Verified Merge. The signed verdict and in-toto/DSSE attestation travel with it.
```
QAFind Verified Merge  FAILED
1 reproduced regression in cart.spec.ts
evidence · signed · in-toto · verify offline
```
required check

Apply as a design partner Read the CLI docs (opens in a new tab)

01 / On every pull request

A QA reviewer on every pull request. It reads the diff like a tester — then runs it.

Generic AI reviewers comment on style. QAFind review looks for what breaks releases: missing tests, fixed sleeps, focused or skipped specs, brittle selectors, unsafe calls. Every finding is grounded to a changed line. The reviewer reads the diff and repository context and does not execute repository code; running affected specs is the Verified Merge step, not the reviewer.

qafind commented · summary updates on every push

QAFind review

Blockedacme/shop#412 — Retry checkout on 500

4 files changed. The new retry can submit a payment twice, and a focused test would silence the rest of the suite in CI.

HIGHRetry resubmits the payment without an idempotency key
src/checkout/pay.ts:57 · LLM review · verified
MEDIUMFocused test committed (.only)
tests/checkout.spec.ts:18 · deterministic
MEDIUMFixed sleep in a test
tests/checkout.spec.ts:42 · deterministic

deterministic 2 · LLM kept 1 · 3 dropped by grounding · verified

02 / A sample review

See exactly what lands on your pull request.

A walkthrough on a demo repository: the summary, inline findings with one-click suggestions, a conversation with the bot, the browser run, and the merge gate.

Retry checkout on 500 #412

Openravi-m wants to merge 3 commits into main from fix/checkout-retry

Conversation 7Commits 3Checks 2Files changed 4

qafindbotcommented · edited on 9f2c4a1

QAFind review

Blocked · 1 finding open of 3 · the idempotency issue is resolved

QA walkthrough

src/checkout/pay.tsRetries POST /api/checkout once on a 500, now with an Idempotency-Key.

src/checkout/retry.tsNew backoff helper (250 ms, one retry).

tests/checkout.spec.tsCovers the retry path; still focused with .only.

.github/workflows/qafind.ymlAdds the QAFind review status check.

Pre-merge checks

PASSNo findings at or above high — idempotency fix verified on 9f2c4a1
PASSNo newly added credential-like value — stand-in keys only
PASSSource changes include test changes — checkout.spec.ts covers the retry
FAILNo focused, skipped or paused tests — .only at checkout.spec.ts:18
SKIPRequired human approvals — not configured

Files 4 · +86 / −12 · deterministic 2 · LLM kept 1 (3 dropped by grounding) · 6.1k prompt / 0.9k completion tokens

src/checkout/pay.tsResolved

56 if (res.status === 500) {

57+ return fetch('/api/checkout', { method: 'POST', body });

58 }

qafind HIGH · correctness

The retry resubmits the payment without an idempotency key.

If the first POST succeeded but the response was lost, the retry charges the customer twice. Send a stable Idempotency-Key per checkout attempt.

LLM review · grounded to line 57 · confidence 0.86 · verified

ravi-m author

Good catch — added the key in 9f2c4a1 and a regression test. @qafind review

qafind

Verified on 9f2c4a1. I re-ran checkout-flow with a forced 500: one POST /api/checkout per click, same Idempotency-Key on the retry. Marking resolved.

tests/checkout.spec.ts

qafind MEDIUM · tests

Focused test committed (.only) — CI would run only this test.

Suggested change

18−test.only('retries checkout once on 500', async ({ page }) => {

18+test('retries checkout once on 500', async ({ page }) => {

Commit suggestionDeterministic check · safe one-line fix

maya-c reviewer

Also — in this repo we prefer getByRole over test ids in specs.

qafind

Understood. I’ll suggest role locators in tests/** from now on.

Learning added · repo-scoped · “Prefer getByRole in tests/**” · manage in the console

qafindran the journeys this diff touchesPreview

Journey	Result	Steps	Evidence
checkout-flow	Passed	18/18	42s · checkpoint cart_ready reused
cart-coupon	Passed	8/8	19s
guest-checkout	Failed	8/9	step 9 · “Continue as guest” moved · heal 0.81 proposed

Safety door: 41 allowed · 1 stopped (POST /v1/refunds) · receipt e2114ac9… signed Ed25519

QAFind reviewRequired — Blocked: focused test in checkout.spec.ts

QAFind browser run2 of 3 journeys passed · guest-checkout needs a heal review

Merging is blockedMerge pull request

01
Grounded, not guessed
Every LLM finding must point at an added line, then a verifier drops anything unsupported or duplicated.
02
Tests the change, not just the code
Missing tests, .only and .skip, fixed sleeps, tautological asserts and removed coverage are caught deterministically.
03
No code execution in review
The reviewer reads the diff and repository context. Running the affected specs is the Verified Merge step, not part of the review bot.
04
One-click suggestions
Safe single-line fixes arrive as suggestion blocks you can commit straight from the PR.
05
Learns your conventions
Accept, reject or reply to a finding and it becomes a repo-scoped learning for the next review.
06
Gates the merge
Pre-merge checks, a required status, reviewer routing and opt-in auto-approve inside risk limits.

Talk to it in the PR

@qafind review
Re-review the latest head, even if this SHA was seen.
@qafind ask which journeys hit the refund API?
Grounded answers from the diff and repo context.
@qafind fix guidance
The smallest safe change for the top findings.

.qafind-review.yml

review:
  fail_on: high
  ignore_paths: ['docs/**', '**/*.lock']
  approve_when_passed: false
path_instructions:
  - path: 'tests/**'
    instructions: 'Prefer role locators; never add fixed sleeps.'

Sample review on a demo repository; names and hashes are illustrative. Browser runs inside PR comments and @qafind fix are in preview. The review is QA-focused and is not a compliance assessment.

03 / The spirit animal

The tardigrade survives vacuum, radiation and drying out. Your suite should be that hard to break.

We named the mark after the toughest animal we know. Each of its survival tricks maps to one thing QAFind does for a browser test.

1
Tun state → Checkpoints
A tardigrade dries into a sealed tun and revives later, unchanged. A checkpoint seals a signed-in, cart-filled browser and forks it into new runs.
2
Armoured cuticle → Safety door
Nothing gets in or out unchecked. Every request passes host, path and method rules, default deny, with stand-in keys instead of real secrets.
3
Segmented body → Hash-linked ledger
Each segment joins the one before it. Each ledger block commits to the hash before it, and the run signs the Merkle root.
4
Eight clawed legs → Resilient locators
Lose one grip, keep walking. Locators hold by test id, role, name and text, and propose a repair when one breaks.

04 / The moat

Four things a browser-testing tool cannot copy by adding a button.

One loop: a real customer journey becomes a test you own, it survives your changing UI, and every run leaves a receipt anyone can verify. The safety door sits underneath it all.

01 · Every step leaves a track

A recorded journey is a real Playwright test.

Click through your site once. QAFind compiles that trace into a readable .spec.ts with resilient locators — your file, in your repo, on stock Playwright.

Playwright + TypeScriptNo test scriptingLocal · CI · hosted

02 · Seal the state, revive it many times

One login, many paths.

Save the signed-in, cart-filled moment as a checkpoint, then fork it into parallel variants. You skip the repeated setup, not the coverage.

Browser state onlyParallel forksSetup skipped, not coverage

03 · Segment by segment

Every run ends with a receipt.

Each run writes a hash-linked log and signs the Merkle root with HMAC-SHA256 or Ed25519. Anyone can verify later that the record was not changed after signing.

Hash-linked ledgerEd25519 or HMACVerifiable offline

04 · The armoured cuticle

Nothing real crosses the line.

Every request passes the safety door: host, path and method rules, default deny, and stand-in keys instead of real secrets. A test never holds production keys.

Default denyPhantom keysEvery verdict logged

How it works / Record · Compile · Run · Audit

From a few clicks to a signed result.

Read the steps as

No test scripts to write by hand. Show QAFind what a customer does once — it turns that into a test, runs it safely, and hands you proof. Each stage produces a file you can commit and review.

01 · Record

Record

Click through your site once. QAFind writes down every step.

qafind explore url records DOM actions and network events to a trace file.
```
00:01 click · Buy now
00:02 fill  · email
00:03 click · Place order
```
trace.json
02 · Compile

Turn it into a test

Your clicks become a real, repeatable test people and machines can read.

qafind compile emits Playwright TypeScript with multi-attribute fallback locators.
```
- locator('#buy-now')
+ getByTestId('add-to-bag')
```
checkout.spec.ts
03 · Run

Run it safely

On your laptop, in CI, or hosted. The safety door checks every request.

qafind test --local | --cloud runs behind the request policy; hosted runs go to POST /v1/runs.
```
GET  /api/cart    allowed
POST /admin       blocked
POST /api/orders  allowed
```
qafind test --local
04 · Audit

Get signed evidence

Every run ends with signed evidence. Edit the log and verification fails.

qafind audit recomputes the Merkle root and checks the signature (HMAC-SHA256 locally, Ed25519 for hosted runs).
```
#1 EXEC_START    4f1c…
#2 SECRET_SWAP   9b02…
#3 EXEC_COMPLETE 21ad…
merkle root · verified
```
qafind audit

Integration options — the same flow from a terminal, an HTTP call or your pipeline.

terminal

# local runs are free and need no account
$ npx qafind test --local

# hosted runs: sign in with an API key from your console
$ npx qafind login
$ npx qafind test --cloud

# see today’s quota and recent runs, then verify evidence
$ npx qafind usage
$ npx qafind runs
$ npx qafind audit

submit a hosted run

curl -X POST https://api.qafind.si/v1/runs \
  -H "Authorization: Bearer $QAFIND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "suiteName": "smoke",
    "targetUrl": "https://staging.example.com",
    "workflow": { "name": "smoke", "steps": [
      { "action": "goto", "url": "/" },
      { "action": "expectVisible", "selector": "body" }
    ] }
  }'

.github/workflows/qafind.yml

name: QAFind
on: [push, pull_request]
jobs:
  browser-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
      - run: bun install
      - run: bunx qafind test --cloud
        env:
          QAFIND_API_KEY: ${{ secrets.QAFIND_API_KEY }}

05 / The console

Every run, heal, verdict and receipt in one place.

Open the sample console

Overview & test runs

Local, CI and cloud runs side by side, what needs attention, and the latest signed receipt.

QA bot reviews

Every PR verdict, finding and learning — accept, reject or apply a safe fix.

Self-healing review

Broken locators get a scored replacement. Below 80%, nothing changes without a person.

Request policy

Rules, blocked hosts and stand-in keys — and a tester that shows what the door would decide.

Audit & evidence

The ledger, link by link. Tamper with a block and watch verification break.

Also in the console Recorder Checkpoints Investigator Time warp preview Fixtures preview Chaos report preview Bug capsules preview API & CI/CD

06 / The guardrail

Your browser test, with a guardrail on every request.

QAFind clicks like a customer, and every request the browser makes is checked at the door. Each verdict is logged and signed with the run.

your test

Browser context · stand-in keys only

safety door

host · path · method · default deny

real services

Only approved hosts reach them

Sample trace — illustrative requests, real rule kinds. Policy covers gateway and proxy traffic only.

GET
/api/cart
Clicked “Checkout” · stand-in key swapped for the real one on api.shop.test
Allowed
POST
/admin/delete-account
Clicked “Delete account” · destructive call never reached the service
Blocked
GET
/api/customer
Read the customer panel · upstream response sanitized first
Sanitized
POST
/api/orders
Submitted the order form · 201 from the test shop
Allowed

What this build does — and where it stopsTen capabilities, each with what it covers today and what it does not.Show the scope

Capability	Does today	Does not do
Request policy	Checks host, path and method rules on gateway and proxy traffic, default deny, and logs every verdict.	Not an OS-level firewall. It does not inspect calls your own servers make.
Phantom credentials	Stand-in secrets in the test browser; real values are swapped in at the door only for approved hosts and methods.	Not a secrets manager. Hosted runs never hold your application secrets.
Self-healing locators	Scores candidates by test id, accessible name, text and structure, then writes a suggested repair.	Repairs are suggestions, not silent edits. Default confidence threshold is 0.8.
Browser checkpoints	Captures storage, session storage, URL and a DOM hash, restores them into fresh contexts, forks in parallel.	Browser state only. Not a VM snapshot; no process memory.
Signed run evidence	Hash-links every event, signs the Merkle root with HMAC-SHA256 locally or Ed25519 hosted, verifies with qafind audit.	Proves the log was not changed after signing — not that your application is secure.
Time warp Preview	Offsets Date in the page and later navigations.	Server, database and cron clocks do not move.
Fixtures Preview	Saves an outside answer once and serves it for matching requests.	Misses currently pass through to the network.
Chaos report Preview	Spots checkout buttons that could charge twice and reports idempotency keys.	Scenarios are simulated, not real charges.
Failure X-ray Preview	Adds W3C traceparent headers and records response metadata.	Backend detail appears only when the server returns it.
Bug capsules Preview	Replays a sanitized event capsule and writes a reproduction spec.	Redaction is heuristic.

07 / Where it runs

Lives in every habitat your tests do.

Local, CI and hosted runs share the same compiled test. The safety door and the signed receipt come with you.

Cloud runners

Hosted browsers on the free plan: up to 50 steps per run, 90 seconds each, and signed evidence for every run.

100 runs / dayStart a hosted run →

Your CI

Run the same test from GitHub Actions or any pipeline. The API key is a CI secret; your pipeline stays the source of truth.

GitHub ActionsRead the CI guide ↗ (opens in a new tab)

Your laptop

The open-source CLI runs where your code does. No account, no upload; the local console shows runs, checkpoints, heals and evidence.

MIT LicenseInstall locally ↗ (opens in a new tab)

Hosted runs never hold your application secrets: a hosted run sends only policy — allowed hosts, methods and blocked paths — never real values.

08 / Pricing

Free to start. Pro when private QA pays for itself.

Free plan

Available now

$0per month · no card

100 hosted runs per day per workspace
1 run at a time, up to 50 declarative steps
90 seconds per hosted run
API key for the CLI and CI
Signed run evidence for every run

Create a free account

Local · open source

MIT License

$0forever · no account

Recorder, compiler and runner
Safety door and stand-in keys
Self-healing, checkpoints and the preview lab
Signed run evidence and the local console
No quota, no network round trip

Open the repository

Planned · Pro waitlist — $29 per workspace / month: private repositories, 3 concurrent runs, 3,000 hosted runs a month, 90-day retention.

See the pricing →

09 / Questions

Good questions, short answers.

Do I need to know how to code?

Not to get started. Record a test by clicking through your site; the console shows each step in plain words. The output is real Playwright code engineers can extend.

Can a test touch real customers or real money?

Every request through the gateway and proxy passes the safety door first. Destructive paths are blocked by your rules and unknown sites are blocked by default. It does not cover calls your own servers make.

What is signed run evidence, exactly?

A hash-linked log of what happened, signed. Anyone with the key can check it was not changed after signing. It does not show that your application is secure.

Where do my tests run?

On your laptop or CI runner with no account, or on hosted runners with a free account. The same CLI does both: --local or --cloud.

What does “Preview” mean?

Preview tools work today, but only inside the test browser. Each one lists what it covers and what it does not.

How is the QA bot different from an AI code reviewer?

It reviews for QA — tests, flakiness, reliability and unsafe calls — grounds every finding to a changed line, and can run the journeys the change touches and sign the result. It is not a style linter and not a compliance assessment.

Why a tardigrade?

It is the toughest animal we know — it seals itself into a tun and survives what would end anything else. That is the bar we hold a browser test to.

Which browsers are supported?

Chromium today, managed by Playwright. Runs work headless or with a visible window.

Try a safe test run.

Create a free account for 100 hosted runs a day, or install QAFind and run locally with no account.

Create a free account Explore the sample workspace