Test a cart and checkout flow in a real browser

1. The badge count drifts out of step with the cart contents after a quick add-remove-add.
2. The line total and the subtotal disagree once quantity goes above one.
3. Setting a quantity to zero leaves a ghost row instead of removing the item.
4. Removing the last item leaves the cart in a broken state rather than an empty state.
5. A discount code changes the displayed total but not the amount that would be charged.

All five survive a happy-path script, because a happy-path script never goes backwards.

Add an item to the cart, open the cart, change the quantity, remove the item, and report whether totals and the cart badge stay correct at every step. Stop before any real payment and report what the final step would have been. Then check computer.diagnostics() for console errors and failed requests.

Most carts are used on a phone, and that is where drawer carts and sticky bars fall apart. Run it again at phone size:

Do the same on a phone: call computer.setDevice('phone') first, then add an item to the cart, open the cart drawer, change the quantity and remove the item. Report anything that overflows, any control you cannot reach by scrolling, and whether the totals and cart badge stay correct.

The prompt tells the run to stop at the payment step and describe what it would have done. That keeps the test useful without touching a payment provider's UI. If your provider's terms allow automated test-mode checkout on your own store, you can ask for it explicitly instead.

• Model — a fast model (Claude Haiku 4.5, GPT-5.6 Luna) is fine for a flow you run often. Reach for a deeper model when a run keeps getting stuck on the same step.
• Devices — laptop is enough for a first pass. Add phone when the flow is mostly used on mobile.
• Step budget — 30 scripts covers most flows. Raise it for long, multi-page journeys.
• Reasoning effort — passed straight through to the model. Higher effort costs more and thinks longer before acting.

• A verdict: pass, fail or blocked.
• Named checks, each marked passed or not, so you can see what was actually asserted.
• Findings rated critical, high, medium, low or info, with the evidence behind each one.
• A screenshot for every step, and one session video for the whole run.
• Console errors, uncaught page errors and failed or 4xx/5xx requests, collected automatically.

Worth knowing before you point it at something important.

• No real charges, and by default the run stops before payment.
• No hosted payment pages. Stripe and PayPal checkouts sit on a third-party domain, and automating a payment provider's UI is usually against their terms.
• No order-confirmation email, because there is no inbox access.
• Inventory and order side effects are real. Use a staging store.