Skip to content
Proofline
Start free

AI drafts the tests.You approve what runs.

Evidence-backed Playwright tests drafted from your repository. Nothing runs until your team approves it.

Create your organizationHow review works

Cart and Checkout › Payment validation

12 candidates · acme/storefront @ 3f9c2ad

  1. Pinned commit 3f9c2ad on main
  2. Mapped application38 routes61 forms47 api calls
  3. checkout/payment-validation/rejects-expired-card.yaml+0
    1+name: Rejects an expired card at checkout2+category: negative · priority: high3+steps:4+  - goto: /checkout5+  - fill: { label: "Card number", value: "4000 0000 0000 0069" }6+  - fill: { label: "Expiry", value: "01/20" }7+  - click: { role: button, name: "Pay now" }8+  - expect: { text: "Your card has expired" }
    evidencesrc/routes/checkout.tsx:88src/components/PaymentForm.tsx:142POST /api/paymentsconfidence 0.92

  4. Review requested from M. Ortiz

    Request changesApprove
  5. Playwright · chromium · shard 1/3running
    Playwright · chromium · shard 2/3running
    Playwright · chromium · shard 3/3running
Demonstration dataGenerating
Repositories
GitHub · Bitbucket
CI
GitHub Actions · GitLab CI · Bitbucket Pipelines
AI tokens per CI run
0

Approval is the gate, not a suggestion.

Every generated test walks the same path. The run button only exists for a version a human has approved, and an edit sends it back for review as a new version.

  1. Drafted from your code, not from a prompt. Generated

    Candidates come from a pinned commit: static analysis plus controlled browser discovery, turned into a versioned model of your application.

    • Proofline generated v1 from commit 3f9c2ad

  2. Queued for a person, with its evidence. Pending review

    Reviewers see the steps, the source files and routes behind them, a confidence score, and what the test covers.

    • Review requested from QA
    • CI tried to run v1 · blocked, version not approved

  3. Change a step, get a new version. Edited · v2

    Edits never rewrite history. The new version goes back to Pending review; earlier runs stay attached to the version that produced them.

    • S. Kral edited step 3 · v2 sent back to review

  4. One approval unlocks this exact version. Approved

    Approval is recorded against the version, the reviewer, and the time. Rejected and archived candidates never reach a runner.

    • M. Ortiz approved v2

  5. Executed by Playwright, in isolation. Running

    Approved versions run in resource-limited workers. Membership, permission, billing and approval are checked again right before work begins.

    • Queued on 3 shards · chromium · commit 3f9c2ad

  6. Results with everything you need to trust them. Passed

    Logs, screenshots, videos and traces stay with the run, recorded against the branch and commit it ran on.

    • Passed in 1m 55s · trace, video and screenshots saved

Every candidate shows its work.

A test you cannot trace is a test you cannot approve. Each step links back to the component, route, or API it came from, so review takes minutes, not archaeology.

src/components/PaymentForm.tsx
138<form onSubmit={handlePay}>139  <Field label="Card number" name="number"140         rules={luhn} />1141  <Field label="Expiry" name="expiry"142         rules={notExpired} />2143  {error && <Alert>{error.message}</Alert>}4144  <Button type="submit">Pay now</Button>3145</form>
rejects-expired-card.yaml
  1. 1goto: /checkout
  2. 1fill: "Card number" → 4000…0069
  3. 2fill: "Expiry" → 01/20
  4. 3click: button "Pay now"
  5. 4expect: "Your card has expired"
Capability
Cart and Checkout › Payment validation
Route
/checkout
API
POST /api/payments
Category
Negative
Risk
High
Confidence
0.92

Eight categories per capability

  • Happy path
  • Negative
  • Boundary
  • Validation
  • Permissions
  • Error handling
  • State changes
  • Integration

Organized by what your product does.

Proofline groups tests by the business capability they protect, not the folder the code happens to live in. Your team layers its own modules and tags on top, and regeneration never overwrites them.

  • Tests can belong to several modules and carry several tags.
  • Archiving a module never deletes its tests, versions, approvals or history.
  • Filter by module, tag, capability, route, status, category, priority, branch or last result.
acme/storefront · 8 of 142 tests

Authentication2

Login validationsmoke
Password reset

Product Management3

Browse productssmoke
Product search and filtersregression
Product details

Cart and Checkout3

Add to cartcritical
Update quantity
Payment validationcriticalrelease-1

Demonstration data

Regenerate without losing a reviewed test.

When the code moves, Proofline compares commits and only revisits what changed. Manual, approved, edited and historical tests are always preserved.

a41e07c...3f9c2ad
Changed since last analysis
  • src/components/PaymentForm.tsx+18−4
  • src/routes/checkout.tsx+6−2
  • src/features/cart/useCart.ts+3−3
Affected capabilities
  • Cart and Checkout › Payment validation
  • Cart and Checkout › Update quantity
Result preview · incremental regeneration
New candidates
14
Marked Needs review
3
Approved tests touched
0

Demonstration data · try the menu

Every push runs what you approved, at the exact commit.

Your pipeline sends the repository, branch and commit SHA. Proofline validates the organization, pins the commit, and runs the approved snapshot. No generation happens in CI, so a run normally spends zero AI tokens.

  • GitHub Actions
  • GitLab CI
  • Bitbucket Pipelines
  1. queuedPushfeature/checkout-v2
  2. queuedPipeline calls ProoflineGitHub Actions
  3. queuedValidateorg · billing · permission
  4. queuedPin commit3f9c2ad
  5. queuedRun approved snapshot142 tests · Playwright
  6. queuedReport statusback to the pipeline

Same tests, separate history per branch

  • Login validation
    development
    Passed
    qa
    Passed
    production
    Passed
    feature/checkout-v2
    Passed
  • Add to cart
    development
    Passed
    qa
    Test failed
    production
    Passed
    feature/checkout-v2
    Passed
  • Payment validation
    development
    Passed
    qa
    Passed
    production
    Passed
    feature/checkout-v2
    Test failed
  • Product search and filters
    development
    Passed
    qa
    Environment failure
    production
    Passed
    feature/checkout-v2
    Not run on branch
  • Passed
  • Test failed
  • Environment failure
  • Not run on branch
  • Demonstration data
  • The commit SHA is authoritative; a branch name never silently resolves to your default branch.
  • Pending, rejected or unapproved tests never run, whoever triggers the pipeline.
  • Retries are stored as separate attempts. Test failures are told apart from environment failures.

3,000 tests. Not 3,000 browsers.

Approved tests are balanced into shards by historical duration and run on a bounded, autoscaling worker pool. Plans buy concurrent test slots, not idle servers.

Concurrent test slots100
Estimated wall-clock≈ 34 min
Same suite, one at a time50 h 4 min

Illustration using the formula total duration ÷ workers + overhead, for 3,000 one-minute tests. Real time depends on retries, startup, uneven workloads, serial tests and how much load your environment accepts.

Reviewed by the people who sign off releases.

  1. Dana Whitfieldapproved· Head of QA, Northwind Commerce
    The approval gate is the reason we said yes. My team reviews a candidate with its evidence in a couple of minutes, and nothing sneaks into the pipeline.
  2. Rahul Menonapproved· Engineering Manager, Lattice Health
    Grouping by capability changed our release reviews. We talk about checkout and onboarding coverage now, not about which folder has tests.
  3. Sofia Kralapproved· Staff Engineer, Brightline Freight
    Pinned SHAs and zero-token CI runs made it easy to put in front of platform. Feature branches finally have their own history.

Placeholder testimonials

Pay for concurrency, not idle servers.

Every plan includes the full review workflow. Plans differ by how many approved tests can run at once. Billing is monthly, quarterly or yearly.

  • Starter

    5concurrent test slots

    One team proving out reviewed AI coverage.

    Start with Starter

  • Team

    Most teams

    25concurrent test slots

    Product teams running suites on every push.

    Start with Team

  • Business

    100concurrent test slots

    Large suites across many projects and branches.

    Start with Business

  • Enterprise

    Customconcurrent test slots

    Configurable capacity, limits and retention.

    Set up Enterprise

Included in every plan

  • Human approval gate on every test version
  • GitHub and Bitbucket repositories
  • GitHub Actions, GitLab CI and Bitbucket Pipelines
  • Branch- and commit-aware result history
  • Logs, screenshots, videos and traces
  • Admin, QA and Developer roles
  • AI generation quota pooled across projects

Questions reviewers ask first.

Can an AI-generated test ever run without approval?

No. Only approved test versions can execute, from the dashboard, the API, a schedule, a retry or CI. The check happens when a run is queued and again inside the worker right before execution.

How many AI tokens does a CI run use?

Normally zero. CI executes the approved snapshot of your tests with Playwright. AI is only used when you analyze or regenerate.

Which applications can Proofline analyze today?

The first analyzer targets React and TypeScript applications built with Vite. It combines static analysis of routes, components, forms and API calls with controlled browser discovery.

What happens to my tests when I regenerate?

Manual, approved, edited and historical tests are always kept. Incremental regeneration revisits only what changed between commits; duplicates are linked, and affected tests are marked Needs review instead of being replaced.

Which repositories and pipelines are supported?

Repositories on GitHub and Bitbucket. Pipelines on GitHub Actions, GitLab CI and Bitbucket Pipelines, reporting queued, running, passed, failed, cancelled and blocked states.

Does Proofline test production automatically?

No. You choose the environment for each run, and the deployment URL must match the branch or commit you selected.

Who can approve and run tests?

Organizations have Admin, QA and Developer roles. Admins manage users and billing; review and execution permissions are configurable, and every permission is enforced on the server.

Put a reviewer between AI and your pipeline.

Connect a repository, review the first candidates, and run only what your team approves.

  • Every generated test is reviewed by a person
  • Every run is pinned to an exact commit
  • No unapproved version can reach a runner
Create your organizationSign in