CONTROLLED STOREFRONT TESTING

The Owloscope
test lab.

One realistic commerce journey. Multiple deliberately reproducible conditions. Use cases to check whether your detection reports facts—not assumptions.

ACTIVE SCENARIO: healthy
SCENARIO LIBRARY

Choose a condition.

SCENARIOEXPECTED BEHAVIOROPEN
Healthy baselinehealthyEverything works: add to cart → view cart → checkout → mock payment.Open case ↗
Add-to-cart failureatc-failATC click is accepted visually but item is not added.Open case ↗
Cart persistence failurecart-lossProduct adds, then disappears on the cart page.Open case ↗
Checkout advance failurecheckout-blockContinue to payment refuses to advance.Open case ↗
Guest checkout unavailableno-guestCheckout requires an account; not necessarily a defect.Open case ↗
Broken product assetbroken-imageAn illustration returns a 404 from the server.Open case ↗
Accessibility regressionmissing-altRemoves alternative text from selected product images.Open case ↗
Empty homepage contentempty-homeMain homepage content is cleared after rendering.Open case ↗
Go to storefront ↗
IMPORTANT: REMOTE SCANNERS

Browser-local settings are not server settings.

Clicking a case opens a link with a ?vf_case= parameter. It affects that browser's navigation only. A remote scanner starting from owloscope.com won't inherit your browser's state. For root-domain scans, set DEFAULT_SCENARIO in assets/config.js and redeploy, or host individual scenarios on separately configured subdomains. Hostname-based cases are already supported by the code.

Recommended fixed hostnames: atc-fail.owloscope.com, broken-image.owloscope.com, etc. Each hostname must be configured on the hosting platform, not just DNS.