Multi-Site Checkout Smoke Test

# Multi-Site Checkout Smoke Test

Run the same read-only storefront journey across a reviewed set of public product pages and report where the experience breaks before payment.

## Loadout capabilities

Use <action-tag>api:tinyfish_api:run_batch</action-tag> to launch one isolated TinyFish browser run per approved product URL. Use <action-tag>api:tinyfish_api:batch_get_runs</action-tag> to poll the returned run IDs together, <action-tag>api:tinyfish_api:get_run_by_id</action-tag> to inspect an individual terminal or failed run, and <action-tag>api:tinyfish_api:get_step_screenshot</action-tag> only when a relevant step image is needed to prove a defect.

Read every current schema before execution. TinyFish browser Actions require the user's connected personal TinyFish credential. Verify the connection through Aident Vault and never request a raw key. Preflight the exact batch, show the URL count and quote, and obtain approval before starting it.

## Test contract

Collect 2 to 10 exact public product URLs, the expected product names and prices, locale and currency, the allowed stopping point, and whether adding one item to an anonymous cart is permitted. Default to no account creation, no login, no address entry, no contact details, no coupon redemption, no consent acceptance, no payment entry, and no order placement.

This is a smoke test, not a load test. Use one run per URL and one journey per run. Do not test sites the user does not own or have permission to assess when the requested interaction could create material traffic or state.

## Build the TinyFish batch

For each reviewed URL, write a narrow goal that tells TinyFish to:

1. Confirm that the intended product loads and record the displayed name, price, currency, stock state, and primary purchase control.
2. Select only a user-approved default variant when a selection is required.
3. If cart interaction is approved, add exactly one unit and confirm the cart line, quantity, subtotal, and currency.
4. Navigate only as far as the first checkout or order-review page reachable without entering personal, account, address, or payment data.
5. Stop immediately before any login, account creation, personal-data form, terms acceptance, payment control, or final purchase action.
6. Return a structured pass or fail result with the last confirmed URL, observed values, blocker, and completed step.

Use the default agent mode. Do not set strict mode or a custom maximum step count unless the user's TinyFish entitlement and test plan explicitly require it. Request snapshots and screenshots only when they are needed for evidence; avoid recordings by default.

## Execute and verify

Show the complete per-URL goals and stopping rules before seeking batch approval. After approval, run the batch once and retain all returned run IDs. Poll them together until each reaches a terminal provider state. A client timeout is not a test failure; use the run IDs to recover provider state.

Inspect each terminal result individually. Fetch a step screenshot only for the first clear failure, a material price mismatch, or the final permitted checkout boundary. Never publish screenshot URLs or browser session details; present the verified image through the host's supported artifact renderer when needed.

Do not retry a run that may have crossed its stopping boundary. If the terminal state or last action is ambiguous, report `Needs Review`, preserve the run ID and last confirmed step, and ask before any rerun.

## Pass criteria

A URL passes only when the correct product is shown, commercial values match the agreed expectation or are clearly flagged, the permitted cart step succeeds if requested, and the run stops before restricted data or actions. Classify results as `Pass`, `Fail`, `Blocked`, or `Needs Review`. A generic success page, completed navigation, or HTTP response alone is not proof of a passing journey.

## Output

Return one row per URL with product, locale, observed price, cart result, furthest safe step, status, blocker, terminal provider state, evidence reference, and run ID. Summarize failures by stage and recommend the smallest manual follow-up. Confirm explicitly that no account was created, no personal or payment data was entered, and no order was placed.