QA harness: the run behind the numbers
Everything on this page comes from the artifacts of one recorded run of the checkout robot on a synthetic copy of my store. No real purchases, no real payments, no real customers.
Results of the run
The ten rules it checks
- EE-01 The server decides the price and tells the two variants apart
- EE-02 Retail accepts 1 to 10 per SKU and merges duplicates
- EE-03 Wholesale respects the minimum, the 20-unit cut and the contract maximum
- EE-04 Shipping for Bogotá, national and the exact free-shipping threshold
- EE-05 Contact and consent fields are validated on the server
- EE-06 CHK-101: opt-ins unticked, optional and separate; you can buy without them
- EE-07 to EE-10 Order received, payment pending, totals and messages consistent
The negative test
A robot that always says "all good" proves nothing. The harness plants a bug on purpose: marketing opt-ins pre-ticked. Its two tests must fail for that reason, on desktop and mobile. They did. That is how I know the detector works.
How it is built
- Playwright drives Chromium like a customer would, on a local fixture server (port 4173) with synthetic data.
- Each run leaves run.json, results.json, a verdict, a Spanish summary, video and trace. A coverage check rejects skips, failures, missing or stale evidence.
- Guardrails limit which tools, paths and destinations the agents can touch. Nothing in the harness reads .env or reaches the live store.
- Built and governed with Claude Code and Codex. Challenge winner, Ricardo Celis class at Gradiente, October 8, 2026.
What it does not certify
The run certifies the synthetic contract of the fixture. It does not certify the live store, real payments, the CRM or production. The staging profile is a read-only smoke test.
Screenshot above: Playwright HTML report of the run. The video, trace and raw artifacts stay local until David decides to publish them.