Тестуйте buying task, а не один клік.

Почніть із повної customer goal: знайти сумісний товар у межах бюджету, обрати available variant, підтвердити delivery і дійти до cart review. Не зводьте scenario до пошуку однієї кнопки. Task contract фіксує persona, immutable prompt, starting URL, locale, viewport, cookies, allowed actions, stop gate і незалежні final-state assertions.

Зберігайте contract стабільним для deterministic browser baseline і named agent profiles. Стандартні tasks запускайте щонайменше тричі, критичні п'ять разів. Так видно, чи success повторюється, а не виникає випадково через dynamic inventory або personalization.

Надійний scenario потребує відомих test data. Створіть fixtures для available product, unavailable variant, stale або changed price, delivery constraint, expired session і recoverable validation error. Запишіть expected facts та lifecycle window, щоб пізніша inventory change не виглядала як agent failure.

В approved sandbox використовуйте synthetic accounts, addresses і payment instruments. Public production checks можуть перевіряти policies і формувати reversible cart, але не мають створювати order, запускати fulfillment workflow або резервувати scarce inventory без explicit partner authorization.

Порівнюйте product name, identifier, variant, current price, discount context, stock state, delivery promise і return policy у visible HTML, structured data та cart. Product і Offer structured data можуть покращувати machine understanding, але стають defect signal, коли не узгоджені з customer-facing state.

Підтвердьте canonical URLs, headings, labels і update timing. Якщо facts з'являються лише після client rendering, збережіть DOM, accessibility tree і relevant network response у момент agent decision.

Перевіряйте native semantics, accessible names, roles, values і state changes для swatches, selectors, quantity controls та add-to-cart feedback. Keyboard і controlled-browser runs мають доходити до того самого selection без залежності від coordinates або color alone.

Після кожного переходу перевіряйте selected product ID, variant, quantity, displayed price і cart line. Delayed feedback не повинен спричиняти duplicate add. Якщо action endpoint доступний, перевірте idempotency або comparable duplicate-action guard.

Змініть fixture після discovery: зробіть selected variant unavailable, оновіть price, завершіть session або відхиліть delivery postcode. Агент має показати змінений факт, зберегти valid constraints і попросити decision, а не мовчки обрати replacement.

Вимірюйте completion time за phases, включно з rendering, inventory waits, retries і interventions. Фіксуйте Cumulative Layout Shift і target movement біля variant, delivery та cart controls, бо late inventory content може змістити правильний target між observation і action.

Production terminal state знаходиться в cart або order review до payment submission. Runner фіксує intended line items, quantities, variants, totals і delivery context, а потім зупиняється. Assertion також має довести, що order, charge або fulfillment side effect не створено.

Approved sandbox може продовжити із synthetic data, explicit authorization і cleanup rules. Confirmation boundaries мають бути і в scenario definition, і в executor policy, щоб page content не могло їх перевизначити.

Зберігайте immutable prompt, fixture version, executor profile, timestamps, step trace, screenshots, accessibility snapshots, console і network signals, CLS entries, target rectangles та final-state assertion в одному run record. Trace viewer допомагає engineering replay, а deterministic assertions визначають outcome.

Класифікуйте primary cause як website, agent-specific, agent policy, infrastructure або inconclusive. Remediation завершена лише коли той самий scenario і fixture проходять baseline та relevant agents без unexplained regression у time, retries або final state.