Deployment regression comparator

Capture runner and fixture setup

Use Node.js 24 or newer in a new local folder. Download these three files: capture runner, package.json (save with that name), and fixture template (save as fixtures.json).

1. Edit fixtures.json for routes and visible elements in a self-contained application you own. Leave manifest false unless it exposes the Network Speed Tester asset-integrity manifest contract.
2. Run npm install, then npx playwright install chromium. The downloaded package pins the tested Playwright version.
3. Run node deployment-capture.mjs --origin https://your-owned-baseline.example --fixtures fixtures.json --out baseline.json --ack-owned.
4. Repeat with your candidate origin and --out candidate.json, keeping fixtures and browser version unchanged. Existing output files are never overwritten.
5. Paste both capture files into the comparator. Resolve unknown coverage before interpreting an absence of new failures.

A fixture such as {"selector":"h1","text":"Dashboard"} expects exactly one visible heading with normalized text Dashboard. The example routes must be adapted to your application. The runner is a bounded diagnostic, not a browser security sandbox; only run it against applications you operate.

Capture the same expectations twice

Choose a baseline and candidate build that you operate. Use the exact same fixture file, Chromium version and viewport for both. Each route declares its expected HTTP status and optional CSS selectors for exactly one visible element, with optional whitespace-normalized text. The runner makes real GET requests and opens real browser pages; it does not execute clicks, logins or user-provided scripts.

Separate changes from regressions

A route becomes a newly failed expectation only when a previously passing status, UI check or page-error condition fails. Failures already present in the baseline and recoveries are counted separately. Changed response digests and changed declared asset manifests are differences to inspect, not automatic regressions.

Keep incomplete evidence visible

Captures from different fixture suites, browser versions or viewports cannot be compared. Missing or oversized HTTP bodies, interrupted browser observations and blocked external requests remain unknown. Partial coverage never becomes a passing expectation. A no-new-failures result applies only to these fixtures, not the whole deployment.

Capture boundaries and privacy

The local runner accepts HTTPS origins or loopback HTTP with explicit ownership acknowledgement. It uses fresh browser contexts, blocks service workers and WebSockets, and admits only same-origin GET/HEAD browser requests. Use self-contained, unauthenticated builds. It caps routes, request counts, HTTP observation bodies and execution time; browser loading has no total-byte budget. The HTTP response observation and browser UI observation are separate requests and are not an atomic release snapshot.

Reuse asset evidence without overstating it

When manifest is enabled in the fixture file, the runner reads the existing asset-integrity manifest, validates its bounded schema and internal digest, and records only its revision and entry count. This is a declaration comparison, not a fresh byte check of every delivered asset. Use the separate Asset Integrity tool for that purpose.

Understand supplied-capture trust

Captures imported into the page are user-supplied and can be edited. The browser comparator does not authenticate their origin or independently repeat their measurements. Exports contain anonymous fixture numbers, counts and outcomes, with no raw URLs, selectors, headers, response bodies, captured text, cookies or credentials. No visual screenshot, accessibility, CDN propagation or production readiness claim is made.

Method references and related tools

The fixture and capture contracts are versioned with the downloadable runner. Observations apply to the exact supplied fixture suite; no external standard certifies a deployment from these checks.

Response stability monitor · All tools · Overall measurement methodology