Матеріали

Audit planning

Аудитуйте задачі, а не технології.

Цей checklist перетворює широку перевірку agent readiness на повторювані scenarios, спостережуваний evidence і виправлення, які команда може перевірити.

Aiscovery Research12 хв читанняОстання перевірка: 25 серпня 2026 р.
Шари audit sheets, browser targets і session traces, з'єднані зеленим evidence path з одним verified result

Що це допоможе оцінити

  • Як визначити scenarios, fixtures, stop gates і success assertions до запуску агента
  • Які discovery, browser, accessibility, stability і structured-interface signals перевіряти
  • Як класифікувати failures і перетворювати evidence на engineering remediation backlog

Визначте task contract до тестування

Починайте з реальної customer goal, а не з прохання переглянути homepage. Зафіксуйте persona, initial state, immutable prompt, required data, allowed actions, terminal state і criticality. Production run зупиняється перед payment, booking confirmation, account deletion або іншою irreversible action. Sandbox може продовжити сценарій лише із synthetic fixtures та explicit authorization.

Запишіть deterministic assertions до run. Очікувана page, database state, cart contents, reservation summary або API response мають визначати success. Власне повідомлення агента про завершення є evidence для review, а не доказом completion.

  • Зафіксувати locale, viewport, cookie state, network profile і authentication state.
  • Оголосити production stop gate і точну action, яку не можна виконувати.
  • Підготувати available, unavailable, expired-session і validation-error fixtures.
  • Запускати стандартні scenarios тричі, а критичні п'ять разів.

Перевірте discovery та authoritative content

Перевірте status codes, redirects, TLS, robots.txt, sitemap entries, canonical URLs і server-rendered critical content. З'ясуйте, чи може агент визначити authoritative product, policy або support page без hidden navigation path чи search result snippet, який суперечить сайту.

Перевіряйте headings, internal links, structured data і content freshness разом. Інвентаризуйте llms.txt, llms-full.txt та machine-readable alternatives, якщо вони є, але не нараховуйте readiness лише за публікацію file. Факти мають збігатися з canonical HTML і вести до usable task path.

  • Запитати ключові URLs через звичайний browser і declared agent user agents.
  • Порівняти visible prices, availability, policies і dates з metadata та JSON-LD.
  • Зафіксувати blocked resources, redirect loops, soft errors і client-only missing content.
  • Перевірити кожен URL, опублікований у sitemap, structured data та llms files.

Протестуйте accessible interaction path

Перевірте semantic DOM та accessibility tree: names, roles, values, relationships і state changes. Потім виконайте задачу keyboard navigation та controlled browser baseline. Візуально очевидний control може залишатися неоднозначним для агента, якщо accessible name відсутнє, дублюється або не пов'язане з intended action.

Перевірте menus, dialogs, forms, validation, autocomplete, focus restoration і live updates. Error має визначати affected field і надавати recovery step. Cookie banners, popups, CAPTCHA та authentication gates слід вимірювати як частину path, а не відкидати як setup noise.

  • Перевірити один logical H1, descriptive links і native controls перед додаванням ARIA.
  • Перевірити label, description, required state і error association кожного field.
  • Підтвердити focus order, visible focus, modal containment і focus restoration.
  • Повторити primary task на desktop і mobile без coordinate-only assumptions.

Вимірюйте stability і time to outcome

Вимірюйте час від delivery goal до незалежної final-state verification. Зберігайте startup, navigation, network, tool waits, retries, policy approvals і unexpected human interventions як окремі durations, щоб slow або fragile path не ховався за одним average number.

Вимірюйте standards-based Cumulative Layout Shift і пов'язуйте relevant shifts із найближчим agent step. Зберігайте before та after target rectangles, якщо control рухається між perception і action. Тримайте custom target displacement або action-window movement окремо від CLS, щоб report не називав корисну diagnostic стандартною web metric.

  • Рахувати median і tail duration лише для equivalent fixtures та executor profiles.
  • Рахувати retries, repeated observations, navigation loops і unexpected interventions.
  • Зберігати CLS sources, affected elements і action, що відбулася поруч зі shift.
  • Позначати unsupported performance signals як unsupported, а не як zero.

Інвентаризуйте structured interfaces без завищення score

Виявляйте OpenAPI, remote MCP, WebMCP та інші structured interfaces, релевантні customer goal. Перевіряйте tool names, descriptions, schemas, authentication, permissions, structured errors і final results. Registered tool корисний лише тоді, коли агент правильно його обирає, а underlying business action залишається safe і deterministic.

Тримайте technology inventory окремо від outcome scoring. Accessible browser path може пройти без emerging protocol, а broken MCP або WebMCP implementation може створити окремий security і reliability finding, навіть якщо visual interface працює.

  • Розділяти read-only tools та create, update і delete operations.
  • Вимагати confirmation перед consequential actions та idempotency для safe retries.
  • Тестувати schema validation, structured errors, authorization і tenant boundaries.
  • Порівнювати structured-tool outcomes з equivalent visible customer journey.

Захистіть сайт, користувача та evidence

За можливості використовуйте synthetic identities і controlled accounts. Не допускайте credentials, tokens, cookies, payment data, financial records, medical data та direct identifiers до prompts і report artifacts. Визначте retention, authorized viewers і deletion rules до запису browser sessions.

Тестуйте prompt-injection exposure в untrusted page content, hidden instructions і third-party widgets. Executor має відділяти website content від operator policy, не розкривати secrets і вимагати explicit human decision на declared confirmation gates.

  • Знеособлювати screenshots, DOM, accessibility snapshots, URLs, console і network payloads.
  • Перевіряти authentication, authorization, rate limits і session expiry behavior.
  • Фіксувати CAPTCHA, WAF та agent-policy blocks як окремі outcomes.
  • Не додавати raw artifacts до client reports до затвердження redaction.

Доведіть результат і класифікуйте failure

Завершуйте кожен run predefined assertions, а потім пакуйте prompt, executor profile, timestamps, step trace, screenshots, accessibility evidence, console і network signals, performance data та final state в один reviewable record. Stable IDs і hashes роблять result traceable між baseline та retest.

Класифікуйте primary cause як website, agent-specific, agent policy, infrastructure або inconclusive. Finding має містити severity, reproduction steps, expected та observed results, evidence, root cause, remediation, owner і acceptance criteria. Confidence залишається окремим від readiness, коли access або evidence неповні.

  • Не перетворювати not-run, policy-blocked або unsupported states на failures чи zeros.
  • Показувати task success, friction, repeatability і efficiency як окремі signals.
  • Пов'язувати кожен P0 або P1 finding з evidence і deterministic retest condition.
  • Зберігати vendor-neutral baseline окремо від agent-specific regressions.

Мінімальний release checklist

  • Визначити одну representative customer goal з fixtures, allowed actions, stop gate і final assertions.
  • Перевірити crawlable authoritative content, canonical URLs і consistent structured metadata.
  • Виконати path через keyboard navigation і перевірити accessibility tree на кожній state change.
  • Записати session steps, screenshots, timing, retries, interventions і final-state evidence.
  • Виміряти CLS і target movement навколо perception-to-action window агента.
  • Інвентаризувати OpenAPI, MCP, WebMCP, llms.txt і llms-full.txt без трактування presence як success.
  • Перевірити validation, expired sessions, unavailable inventory, popups, CAPTCHA і recovery paths.
  • Редагувати sensitive artifacts і перевірити retention, access та deletion controls.
  • Класифікувати website, agent, policy та infrastructure causes окремо.
  • Перетворити findings на owned acceptance criteria і повторити scenario після remediation.

Первинні джерела

Перевірте сигнал у реальному journey.

Наявність технології важлива лише тоді, коли покращує verified outcome. Пов'яжіть сигнал із task, evidence і final-state assertion.