P PARALLAX

01 / RELATIONAL BROWSER TESTING

One eye sees no depth.
Two do.

A single browsing session cannot know what it is missing. A member does not know the page it just opened should have denied them. A sender does not know the message never arrived. The evidence is not in the page — it is in the relationship between sessions looking at it.

Parallax opens seven isolated browser contexts against the same commit at the same instant, changes exactly one property from a baseline in each, and reads the disagreement. There is no stored screenshot to compare against, so the first sweep of a site it has never seen still has something to say.

You hand it a URL and a credentials file. It finds the sign-in surface itself, signs in as each role, discovers the routes and controls, decides which axes the application even supports, judges what disagrees, writes the failing Playwright specs, and opens the pull request. Nobody writes a selector, records a baseline, or maintains a golden file.

Run it on your own URL Watch the demo · 2:30 See what it found Repository ↗

One continuous browser session, no cuts. The two boards are two players of one live game; the three call panes are three peers of one live WebRTC mesh.

DERIVATION7 WITNESSES · NOT 36 COMBINATIONS
0ownerEnglishlight1440BASELINE
1memberprivilege
2anonprivilege
3Arabiclocale
4darktheme
5360viewport
6768viewport

Each variant preserves every other baseline value. When one disagrees, there is exactly one property that could have caused it.

02 / WHAT ONLY TWO EYES CAN SEE

Three things a diff cannot find.

Every finding below is in a published sweep on this site. The last two are the ones that matter most: in both, the correct route and the broken one are pixel-identical, so no screenshot comparison of any kind can tell them apart.

THE SAME PAGE, TWO VIEWPORTS

A control that only exists on a desktop.

A sweep of the-internet.herokuapp.com — a public site built by someone else, for practising browser automation. No plants, no configuration, no baseline. First run: 26 findings across 12 surfaces.

/challenging_dom: an actionable control sits
outside the viewport; seen by owner-en-light-mobile,
not seen by owner-en-light-desktop

Confirmed by hand: 20 actionable controls off-screen at 360px, 0 at 768px. The page never changed, so nothing comparing it against its own history would ever report this.

AN ORDER, NOT A MOMENT

A game that ends for the winner alone.

Some promises are not an instant but a sequence. The demo fleet serves the same game at two routes. One plays correctly. On the other, a win is reported to the winner while the loser is still told it is their turn.

'invite, play, and win' broke at step 7 of 7,
'amira completes the middle row and wins':
samir should have seen it but it never appeared
— and so is the player who lost

Two live sessions play a seven-step protocol, and every step is verified from both boards before the next one runs — so the finding names the first promise that broke rather than the wreckage after it.

correct route ↗broken route ↗

ONE EVENT, SEVERAL VANTAGE POINTS

A mute button that mutes nothing.

A real WebRTC mesh: audio genuinely travels between browser sessions. One route enforces its own mute. The other updates the control, sets the label to mic-off, and never touches the outgoing track.

samir perceived 'muting stops the audio the others
receive' but is not an intended audience for it
— the event reached samir, layla

Two listeners still hear her. A third, who turned his own speaker off, is correctly not reported — which is why the sensor measures audio energy rather than asking whether a track exists. A muted sender, a deafened listener and a working call all have tracks.

correct route ↗broken route ↗

03 / GRADED DEMO FLEET

A detection rate is meaningless without an error rate.

Seven applications declare their own deliberate defects in code, including two clean controls with nothing planted at all. A finding on a control is a false positive by definition, which is what makes the error rate measured rather than claimed. Every figure below is read live from /graded-summary.json, produced by the same run that CI gates on.

MEASURED RESULT

The result includes being wrong.

—defects found —defects planted —findings on the controls

Measured control result loading.

The controls are applications deliberately built correct, so anything found on them is an error the tool made. Keeping them in the fleet keeps the detector's accuracy visible instead of assumed.

ApplicationPlantedFoundMissedFalse positives

Loading the graded summary.

04 / REVOCATION LAG

Authority can outlive the decision that removed it.

An owner revokes a member in one live session while the member keeps a second session open. The claim has to be tested in parallel, because a sequential run closes the member's session before the assertion could start — the tool would be measuring its own cleanup.

Decisionthe owner's action succeeded
Distributionthe change reached the store
Enforcementnew requests are refused
Effectsthe open session still reads

Three of the four planes pass, which is why this is invisible to every check that stops at the first one. Only the fourth is measured against a clock, and only from a session that was already open when the authority changed.

OWASP ASVS V3 requires that active sessions be revoked when an account is disabled, and names an employee leaving the company as the case. The OWASP testing guide describes checking it by hand. There is no standard automated verifier.

05 / PUBLISHED SWEEPS

Every claim above, with its pixels attached.

Choose a sweep to load its recorded feed. The wall replays the frames the sweep captured on its own — pause or scrub to take it — and click any tile to open that witness across the viewport — seven contexts side by side are too small to read the control a finding is about.

Loading the published sweep index.

06 / OUTPUT

The output is a test, not a report.

A finding ships as a failing Playwright spec you can run in your own suite. Every generated spec must fail as an assertion against the application it was generated from — a generated spec that passes means the defect did not reproduce, which is a broken deliverable rather than good news.

—expected —total —failed —passed —skipped —setup failures

Generated spec figures are loading.

GENERATED / PLAYWRIGHT.spec.ts
Loading generated example.

Not every finding becomes a spec, and the gap is stated rather than hidden. A protocol failure and an audience leak are claims about several live sessions in one moment; this emitter writes single-page specs, so it declines them instead of writing a check that would fail for the wrong reason.