kao273183/mk-qa-master

Mobile 版的 analyze_url：通过 `maestro hierarchy` dump 当前 iOS Simulator / Android Emulator / 实体机 / BlueStacks（通过 QA_ANDROID_HOST）前台 app 的 view tree，再分类成 form（带 hint_text 的输入字段）、cta（enabled + 有文字的可点击组件）、tab_bar（selected 状态 + 同 y 对齐的 2+ 个 tab）三种模块，并附带 candidate_tcs。内置噪声过滤器自动排除 iOS 状态栏 + asset 命名标签（bg_* / *_filled / 纯数字 / 单个 ASCII 字符等），让结果信号集中。需要 Maestro CLI 已安装、设备已启动、app 已在台前。若给定 app_id + launch_app=true，会先用 launchApp 启动再 dump。

v1.1.0 — Edge AI версия analyze_url / analyze_screen. Зондирует RTSP-поток (или путь к файлу для локального mediamtx) и возвращает базовую геометрию (ширина / высота / fps) плюс список candidate_tcs. Когда предоставлен аннотационный sidecar (JSON: ожидаемые обнаружения на кадр), в candidate_tcs добавляется по одной записи на каждый найденный класс И четыре стандартных записи (throughput, latency SLA, reconnect, empty-frame). Только строки — схема та же, что и у candidate_tcs из analyze_url. Чёрный список вендорских хостов (включён по умолчанию): блокирует RTSP-URL на известных доменах камер наблюдения / IoT-камер (Dahua / Hikvision / и т.д.), чтобы случайное зондирование публичных видеопотоков не попало на стандартный путь. Установите `QA_EDGE_ALLOW_VENDOR_HOSTS=true`, чтобы отключить проверку для тестирования собственных камер. Требует дополнений `[edge]` (`pip install "mk-qa-master[edge]"`) — opencv-python выступает драйвером зондирования. Инструмент возвращает `{error: missing_extras, hint}`, когда дополнения не установлены. При успехе возвращает: `{url, width, height, fps, labels, candidate_tcs}`. При отклонении возвращает: `{error: bad_request | forbidden_vendor_host | missing_extras | stream_unreachable, hint, ...}`.

Проверяет живую веб-страницу в headless Chromium и возвращает структурированную карту тестируемых модулей и API-эндпоинтов, которые страница действительно вызвала. Веб-аналог analyze_screen. Поведение: - page.goto(url) с ожиданием DOMContentLoaded + 5s networkidle - DOM-зонд извлекает пять видов модулей: form (с полями fields[] + флагами required), nav (списки ссылок), dialog (модальные контейнеры), section (подписанные области), cta (кнопки действия, совпадающие с ключевыми словами действий, например 登入/送出/Login/Submit) - У каждого модуля появляется candidate_tcs[] — тестовые сценарии с учётом предметной области, готовые для вставки в generate_test - Записывает каждый fetch/XHR, который страница выполнила, удаляет дубли по (method, path), добавляет специфичные для эндпоинта кандидаты-тесты (401, 404, 4xx, payload-too-large…) - Сканирование переполнения макета: ищет видимые элементы, содержимое которых выходит за пределы контейнера более чем на 2 пикселя по горизонтали / 10 пикселей по вертикали (跑版 / text-overflow) Возвращает: {url, page_title, scanned_at, modules[], api_endpoints[], layout_warnings[]} Когда использовать: - Пользователь хочет тесты для конкретного URL или страницы - Разработка регрессионного покрытия на основе реального пользовательского поведения - Нужны подсказки по покрытию бэкендовых API (api_endpoints[] даёт методы + пути) - Исследование багов вёрстки при текущем viewport - Использовать в паре с generate_test(module=…) для одного выполняемого теста на модуль Когда НЕ использовать: - Мобильные приложения (нет DOM) → используйте analyze_screen - Нужен анализ + немедленная генерация тестов → используйте auto_generate_tests (одношаговая версия) - Поиск существующих тестов → используйте list_tests - Прототип тестирования одной страницы → используйте codegen Крайние случаи: - URL недоступен / таймаут → возвращает {error: «打開頁面失敗…», url} - На странице 0 форм / 0 cta → modules[] пуст, но вызов завершается успешно - Страница за логином без auth_cookie → анализирует страницу входа (менее полезно) — передайте auth_cookie, чтобы попасть на страницы после входа - SPA с отложенной гидратацией → увеличьте timeout_ms до 30000+ Планировочная вставка (v0.10.0): передайте `plan_id` из предыдущего вызова qa_plan, и ответ автоматически прикрепит `plan_verification`. Каждый обнаруженный модуль…

Выполняет полную доставку одной командой: последовательно запускает analyze_url, затем для каждого обнаруженного module с содержимым candidate_tcs запускает generate_test, записывает полный каркас pytest-тестов в PROJECT_ROOT/tests/. Это автоматизированная версия ручного запуска `generate_test` N раз для каждого module после `analyze_url`. Подходит для быстрого покрытия в стиле «дай мне URL, остальное сделай сам». Каждый candidate_tc становится docstring соответствующей test-функции; после run_tests HTML-отчёт отображает docstring как имя тестового сценария. Возвращает список путей сгенерированных файлов и количество тестов на каждый module. По умолчанию — 1 тест на module, для более плотного покрытия увеличьте `tests_per_module`. Plan bookend (v0.10.0): передаёте `plan_id` из предыдущего вызова `qa_plan`, и ответ автоматически подключает `plan_verification`. Каждая сгенерированная запись теста (или ошибка генерации) становится строкой evidence с полями kind=generated_test, path, covers_module (form/cta/nav и т.д.), module_name, error (None при успехе) и source url. CPs могут проверять покрытие («модуль form произвёл ≥1 тест») или инварианты отсутствия ошибок («ни один module не имел ошибок генерации»).

Запускает интерактивную запись тестов для активного бегуна. Полезно как построитель базовой линии перед уточнением с помощью generate_test. Поведение: - pytest-playwright: запускает `playwright codegen -o <output> <url>`: открывается настоящее окно Chromium, вы кликаете, вводите, переходите, Playwright записывает каждое действие в исполняемый код pytest, результат сохраняется в PROJECT_ROOT/<output> при закрытии браузера. - Maestro: возвращает человекочитаемую подсказку, указывающую на `maestro studio` (для него не существует готового codegen, который можно вызвать из оболочки). - jest / cypress / go runners: такая же подсказка-заглушка, как у Maestro. Возвращает: строку с сохранённым путём или подсказкой для ручной записи. Когда использовать: - Интерактивное построение базового happy-path теста (вы кликаете, он записывает). - Сайт со сложной аутентификацией / JS-состоянием, которое проще не прописывать вручную. - Быстрый прототип перед уточнением с помощью generate_test. - Пользователь говорит «record / 錄製 / use codegen / 紀錄操作». Когда НЕ использовать: - Безголовые CI / контейнерные окружения: нельзя открыть Chromium. - Нужна структурированная, управляемая AI генерация тестов на основе анализа: используйте generate_test или auto_generate_tests. - Покрытие тестами модулей за один проход: используйте auto_generate_tests. - Потоки мобильного UI: всё равно вернёт подсказку, лучше используйте analyze_screen + generate_test. Крайние случаи: - `output` содержит `..` или является абсолютным путём: блокируется защитным ограждением. - Chromium не установлен: playwright codegen завершается ошибкой; пользователь увидит подсказку `playwright install` в stderr.

把最近一次 `run_tests` 的结果渲染成一个单文件自包含的 HTML——以 base64 形式嵌入的截图、嵌入式 step list、history sparkline 走势、折叠的 Passed 区块、展开的 Failed cards。没有外部 CSS/JS 依赖，可以直接发邮件、丢到静态托管、贴到 Slack。默认输出 `PROJECT_ROOT/report.html`。实现在 `reporters/html.py`，沿用 `sample_report.html` 同款设计。

Создайте скелет теста для pytest-playwright. Рекомендуемый процесс: сначала вызовите analyze_url, чтобы получить candidate_tcs, затем для каждого TC, который хотите покрыть, вызовите один раз generate_test, передав всю строку candidate_tc в качестве description — она автоматически станет docstring тестовой функции, а в HTML-отчёте будет отображаться как имя кейса. Если указаны url+module (из modules[] от analyze_url), selectors будут предзаполнены исполняемой версией. Если нужно обработать весь URL сразу, не составляя тесты вручную, используйте auto_generate_tests.

Извлекает полные материалы для анализа первопричин для каждого упавшего теста в последнем прогоне. Поведение: - Читает report.json, фильтрует тесты, где outcome == 「failed」 - pytest: парсит Playwright trace.zip → извлекает реальную последовательность вызовов API (события Frame.*, Page.*, Locator.*, ElementHandle.*) как steps[] - Maestro: парсит flow YAML на наличие директив `takeScreenshot:` → определяет путь к <name>.png в корне PROJECT_ROOT - По мере возможности определяет пути к screenshot / trace.zip / video / recording из директорий артефактов --output / --debug-output Возвращает: list[{nodeid, title, message, duration, steps[], screenshot, trace, video}] Когда использовать: - run_tests только что сообщил о наличии > 0 упавших тестов → углубиться в каждый случай - Пользователь спрашивает 「почему упало / покажи трейс / что сломалось」 - Создание бага в JIRA → использовать пути к артефактам для прикрепления screenshot+trace - Сравнение сигнатур падений между прогонами (в паре с get_test_history) Когда НЕ использовать: - Нужно только общее количество → используй get_test_report (легче) - Тесты ещё не запускались → возвращает [{error: 「找不到報告」}] - Нужны детали и по ПРОЙДЕННЫМ тестам → здесь не поддерживается; HTML-отчёт отображает их по другому пути Граничные случаи: - Подстрока test_id не соответствует ничему → пустой список, без ошибки - screenshot / trace / video отсутствуют на диске → эти поля равны null, но запись остаётся - Перезапуск исправил флак (был упавшим, теперь прошёл) → здесь не отображается; вместо этого показывается в summary.flaky_in_run

Объединяет modules, обнаруженные через history/снэпшоты, telemetry tool-usage и analyze_url, и формирует трёхуровневый самоусиливающийся анализ: (1) Качество набора тестов: для каждого теста вычисляется строка outcomes (например, «PFPFP») → flake_score, затем fingerprint-сравнение signal-ов ошибок: 3 последовательных совпадения одного signal — признак broken, ухудшение duration более чем в 1.5 раза — slow_regression, иначе stable_passing. (2) Шаблоны использования MCP: top tool, повторяющиеся args, частота ошибок, типичные цепочки вызовов (совместное появление A→B). (3) Эффективность AI-сгенерированных тестов: появляется ли тест, написанный generate_test, в следующем прогоне, соответствует ли module, обнаруженный analyze_url, тестовому файлу (coverage adoption vs coverage gap). Возвращает структурированный JSON и синхронно записывает в PROJECT_ROOT/optimization-plan.md. Каждый раз после завершения run_tests автоматически срабатывает один раз, поэтому этот tool используется для «чтения результатов в реальном времени».

Читает `qa-knowledge.md` тестируемого проекта (бизнес-правила / исторические баги / стандартные строки утверждений / User Journeys и другие области знаний), разбивает их на секции с заголовками `## H2`. Использование: сначала вызови, чтобы получить весь документ или указанную секцию, затем передай соответствующие абзацы как `business_context` в `generate_test` — сгенерированные тесты автоматически получат аннотации с бизнес-знаниями, уходя от monkey testing. Если файл отсутствует, используется встроенная общая база: семь принципов ISTQB + эквивалентное разбиение + граничные значения + таблица решений + переходы состояний + Mobile checklist — можно применять и так; позже запусти `init_qa_knowledge`, чтобы создать версию, специфичную для проекта.

Возвращает текущий тестовый runner, выбранный переменной окружения QA_RUNNER (один из пяти: pytest / jest / cypress / go / maestro), а также полный список всех runner'ов, встроенных в сервер при компиляции. Рекомендуется вызывать этот инструмент первым в каждом сеансе — AI использует его, чтобы решить, генерировать ли Playwright .py или Maestro .yaml дальше, нужен ли headed browser, и избежать ошибочного шаблона. Также применяется для проверки корректности настройки окружения проекта: QA_PROJECT_ROOT указывает на правильную директорию, QA_RUNNER не содержит опечаток. Формат возврата: {active: 'pytest', available: ['pytest', 'jest', ...]}.

Перебирает снимки test-results/history/*.json (автоматически архивируются после каждого run_tests), возвращает сводку по каждому запуску: timestamp / total / passed / failed / skipped / duration / pass_rate (0-100). Используется для анализа флаков («этот тест всю прошлую неделю падал?»), анализа деградации скорости («duration всё растёт?») и графика тренда покрытия. По умолчанию возвращает последние 10 записей, limit можно настроить от 1 до 100. Если нужны исполняемые рекомендации, подключи get_optimization_plan — он уже объединяет history + telemetry.

Читает report.json, оставшийся от последнего run_tests, и возвращает лёгкую сводку: total / passed / failed / skipped / flaky_in_run (количество спасённых авто-повтором) / duration (сек). Намного дешевле повторного прогона — подходит для частой проверки состояния между последовательными операциями. Если тесты не запускались, возвращает {error: 找不到報告，請先執行 run_tests}. Если в сводке failed > 0, вызывать get_failure_details для получения деталей ошибок. v1.3.0+: Edge AI runner добавляет опциональный блок `edge_metrics` к каждой записи теста ({p95_latency_ms, fps, iou_per_frame, labels_covered}). `get_optimization_plan` читает эти метрики и выводит 4 сигнала флака, специфичных для Edge (latency_p95_exceeded_sla, fps_variance_across_runs, iou_jitter_per_tc, coverage_gap_per_label), наряду со стандартными категориями flake/broken/slow_regression. В обычных (не Edge) прогонах поле `edge_metrics` отсутствует, и сигналы не меняются.

В корне тестируемого проекта (PROJECT_ROOT) создать начальный шаблон qa-knowledge.md, содержащий 5 разделов H2: бизнес-правила / исторические баги / стандартный текст утверждений / User Journeys / технические ограничения. Каждый раздел содержит подсказку TODO. Idempotent: если файл уже существует, он не будет перезаписан (если только overwrite=true). Новым пользователям рекомендуется при первом запуске MCP сразу вызвать его один раз. Этот файл впоследствии будет прочитан get_qa_context, передан как business_context в generate_test, что позволит AI писать тесты с бизнес-логикой (а не примеры monkey testing).

Обнаруживает задачу reCAPTCHA v2 типа «сетка изображений» на активной странице, делает её скриншот и возвращает метаданные плиток. Клиент ИИ (Claude / Cursor / Gemini — мультимодальный) использует собственное зрение, чтобы определить, какие плитки нужно нажать, затем вызывает solve_visual_challenge с выбранными индексами. Требуется установить QA_VISUAL_CHALLENGE_CONSENT=true на уровне сервера; без этого возвращает структурированную ошибку `consent_required` с полным юридическим отказом от ответственности. Возвращает: {challenge_id, screenshot_base64, challenge_text, grid_layout ('3x3'|'4x4'), tile_count, tiles[{index, viewport_x, viewport_y, w, h}], expires_at, fingerprint}. Формы ошибок: consent_required / unauthorized_domain / forbidden_domain / no_challenge_present / no_active_page / detection_failed — та же обёртка {error, retryable, hint}, что и у всех остальных раннеров. Область применения: только reCAPTCHA v2 image-grid в v0.7.0 (hCaptcha → v0.7.1; v3 / Turnstile навсегда вне области). Используется в паре с solve_visual_challenge — этот инструмент сам по себе никогда ничего не нажимает.

Использует собственный механизм сборки runner для перечисления всех исполняемых тестов в тестируемом проекте: pytest запускает `pytest --collect-only`, Jest — `npx jest --listTests`, Cypress — glob `cypress/e2e/*.cy.*`, Go — `go test -list .*`, Maestro — рекурсивный поиск по `*.yaml`. Возвращает построчный список nodeid / имён файлов. Используется: перед run_tests — проверить, что сборка полная; перед generate_test — избежать дублирования с существующими кейсами.

v0.9.1 — Сохраняет список контрольных точек перед выполнением задачи QA. Хост-LLM объявляет, как выглядит успех (тест проходит, сканер находит X, скриншот показывает Y), этот инструмент сохраняет это и возвращает `plan_id`. Позже вызывайте `verify_plan` с доказательствами (строки результатов тестов, находки сканера, строки логов, пути к скриншотам) и получайте вердикт pass/fail по каждой контрольной точке. Вдохновлён паттерном plan.md из microsoft/Webwright: объявление критериев успеха заранее заставляет верификатор честно оценивать, выполнена ли работа. Планы живут 30 минут (TTL кэша) в памяти и ограничены LRU до 50 активных. v0.9.3 — сохранение на диск: когда установлена `QA_PROJECT_ROOT` (или `QA_PLAN_PERSIST=true`), план также атомарно сбрасывается в `<QA_PROJECT_ROOT>/test-results/plans/<plan_id>.json`. `verify_plan` прозрачно падает на диск при промахах в памяти, так что планы переживают перезапуски процесса и вытеснение из кэша. Истечение срока действия по-прежнему учитывается при чтении с диска — просроченный план не будет молча загружен заново. Сохранение делается по возможности: ошибки файловой системы никогда не всплывают к вызывающему коду. Возвращает: `{plan_id` (12 шестнадцатеричных символов), `task`, `kind`, `critical_points` [{id, description, verification_hint}], `created_at`, `expires_at`, `persisted_to` (путь файловой системы или null, когда сохранение выключено)}. Формы ошибок: no_task / no_critical_points / bad_critical_points (дублирующийся id, отсутствует description, неправильный тип) / bad_kind.

v0.8.0: сканер на основе правил OWASP API Security Top 10 (2023). Загружает спецификацию OpenAPI 3.x, обходит каждый путь × метод и применяет 5 правил из v0.8 — BOLA (API1), Broken Authentication (API2), Mass Assignment (API3, опционально), Function-Level Authz (API5), Security Misconfiguration (API8). Возвращает блок отчёта безопасности v0.8 с для каждой находки: rule_id, severity (critical/high/medium/low/info), endpoint, evidence dict и remediation_hint. Требует QA_API_SECURITY_CONSENT=true на уровне сервера. Хосты не из localhost должны быть указаны в QA_API_SECURITY_AUTHORIZED_DOMAINS (через запятую). mass_assignment изменяет состояние сервера — включите его, передав в `categories`. Фикстура первого уровня (`examples/sample_vulnerable_api/`) поставляется с пакетом для самопроверки. v0.9.4 — Передайте `plan_id` (из qa_plan), чтобы автоматически проверить результаты сканирования по критическим точкам плана в том же вызове. Ответ получает блок `plan_verification` (чеклист по каждой КТ + общий статус). Эквивалент одного вызова последовательности qa_plan → run_api_security_scan → verify_plan. Возвращает: {scan_id, spec_url, base_url, categories_run, rules_ran, ops_scanned, severity_threshold, findings[...], summary{total, by_severity}, findings_below_threshold_count, plan_verification (только если передан plan_id)}. Формы ошибок: consent_required / unauthorized_domain / spec_load_failed / no_base_url / unknown_categories / bad_severity_threshold.

Запускает только тесты, упавшие в прошлый раз — это намного быстрее, чем прогонять весь набор, и подходит для итеративной проверки после исправления ошибки. pytest использует флаг `--lf` (last-failed), Jest — `--onlyFailures`, Cypress анализирует массив failures[] из последнего report.json и находит соответствующие spec-файлы для повторного запуска, Go извлекает имена упавших тестов, составляет из них regex и передаёт флагу `-run`, Maestro находит nodeid и перезапускает соответствующий .yaml. Для работы требуется хотя бы один предшествующий запуск run_tests (иначе report.json не существует). Возвращает данные в той же структуре, что и run_tests; их можно просматривать с помощью get_test_report / get_failure_details тем же способом.

Выполняет тестовый набор под активным QA_RUNNER и формирует структурированный отчёт. Самый часто вызываемый инструмент: вызывайте каждый раз, когда пользователь говорит «跑/run/test/check/驗證/執行», после generate_test (проверить новый тест) или после исправления (подтвердить, что баг исчез). Поведение: - Вызывает собственный CLI раннера в QA_PROJECT_ROOT: pytest с --screenshot=on / --tracing=on / --video=retain-on-failure, или `npx jest --json`, `npx cypress run --reporter json`, `go test -json`, `maestro test --format junit` - Необязательный `filter` сужает область: pytest -k expr, jest -t pattern, cypress --spec glob, go -run regex, maestro flow-name substring - Записывает report.json (структура pytest-json-report, не зависящая от раннера) + XML JUnit - Сохраняет снимок запуска в history/ и автоматически запускает optimizer.write_plan() → optimization-plan.md обновляется - Maestro: автоматически повторяет потоки, упавшие при первой попытке (MAESTRO_RETRY=true), показывает количество flaky_in_run Возвращает: {exit_code, raw_exit_code, stdout_tail, stderr_tail, retry_enabled, flaky_in_run, ...} Когда использовать: - После написания нового теста → убедиться, что он действительно проходит. - Дымовое тестирование перед релизом. - Когда бы запрос пользователя ни содержал глагол запуска/тестирования. Когда НЕ использовать: - Просмотр последних результатов без повторного запуска → используйте get_test_report (дешевле). - Повторный запуск только упавших случаев → используйте run_failed (гораздо быстрее). - Перечисление существующих тестов → используйте list_tests. Граничные случаи: - Ни один тест не соответствует `filter` → exit_code != 0, в stderr_tail «no tests ran». - Превышено QA_TIMEOUT_SECONDS → exit_code 124 + тег `[TIMEOUT…]` в stderr_tail. - `filter`, начинающийся с `-` или содержащий `..` → блокируется защитным механизмом, возвращает {error: …}. Обрамление плана (v0.10.0): передайте `plan_id` из предыдущего вызова qa_plan, и ответ автоматически прикрепит `plan_verification` — критические точки проверяются по только что записанному report.json через тот же поток, что использует run_api_security_scan. Опустите `plan_id`, чтобы сохранить устаревшую форму (без ключа plan_verification). Когда verify_plan завершается неудачей (неизвестный / истёк…)

Применяет выбранные AI-клиентом плитки, выполняет цепочку кликов, нажимает Verify, ожидает токен reCAPTCHA и возвращает результат. Работает в паре с inspect_visual_challenge - должен вызываться с `challenge_id`, возвращённым предыдущим вызовом inspect. Требует `confirm: true` в качестве предохранителя - случайный вызов без confirm возвращает `confirm_required` без выполнения кликов. Также требует `QA_VISUAL_CHALLENGE_CONSENT=true` на уровне сервера. DYNAMIC-REPLACE MODE (v0.7.4): когда в приглашении задачи написано 'Click verify once there are none left' (en) / '確定沒有遺漏' (zh), нажатые плитки заменяются новыми изображениями. solve обнаруживает это и возвращает `status: 'continue'` со СВЕЖИМ скриншотом + сеткой плиток вместо нажатия Verify. AI должен посмотреть на новый скриншот и снова вызвать solve со следующими совпадениями. Для завершения (нажать Verify и проверить токен) передайте пустой `selected_tile_indices: []`. Возвращает: {status: 'passed' | 'continue' | 'failed' | 'expired' | 'consent_required' | 'confirm_required' | 'challenge_not_found' | 'error', challenge_id, attempts_remaining, token (только при passed), hint, а при 'continue': screenshot_base64, tiles, tile_count, grid_layout, rounds_used}. Телеметрия записывает только boolean-результат - скриншоты, текст задачи и выбранные плитки никогда не сохраняются. Plan bookend (v0.10.0): передаёт `plan_id` из предыдущего вызова qa_plan, и ответ автоматически присоединяет `plan_verification`. Доказательство - сводка из одной записи {kind: 'captcha_solve', status, token_populated, rounds_used, fingerprint, challenge_id} - сырой `token` НИКОГДА не включается (гигиена телеметрии). Верификация срабатывает только после того, как solve действительно выполняется; consent_required, confirm_required, challenge_not_found, expired - все они обходят верификацию, так как это ошибки использования, а не результаты solve.

v0.9.1 (расширенная v0.9.2 с автообнаружением) — Проходит по критическим точкам плана и проверяет каждую на соответствие свидетельствам. Работает в паре с `qa_plan` — должен вызываться с `plan_id`, возвращённым предыдущим вызовом `qa_plan`. Возвращает структурированный чеклист со статусом выполнения по каждой КТ и общим статусом (passed / incomplete / failed). Правило сопоставления: КТ считается выполненной, когда её `verification_hint` встречается (без учёта регистра, как подстрока) в строковом представлении любого элемента свидетельства. Элементы свидетельств могут быть строками, словарями или вложенными структурами — проверяющий их уплощает. v0.9.2 — Режим auto_discover: установите `auto_discover: true`, и проверяющий читает pytest-json-report проекта по пути `<QA_PROJECT_ROOT>/report.json` (или `MK_QA_REPORT_PATH`, или аргумент `report_path`) и добавляет список его `tests` в поток свидетельств. По возможности — отсутствующий или повреждённый отчёт молча пропускается, это НЕ жёсткая ошибка. Поле `evidence_sources` в ответе сообщает, что было использовано. Семантика статусов: - `'passed'`: все КТ выполнены - `'incomplete'`: некоторые выполнены, некоторые нет - `'failed'`: ни одна КТ не выполнена (или свидетельства пусты) Даже если хост утверждает «всё хорошо», `verify_plan` возвращает `'incomplete'`, когда любая КТ не выполнена. Это заложено в дизайн — факты важнее заявлений о возможностях. v0.9.3 — Когда включено сохранение (см. `qa_plan`), промах кэша в памяти прозрачно переключается на диск. Поле `plan_source` в ответе сообщает, откуда взят план: `'memory'` (попадание в кэш) или `'disk'` (загружен из `<plans_dir>/<plan_id>.json` после перезапуска или вытеснения). Возвращает: {plan_id, task, kind, status, checklist[{id, description, verification_hint, satisfied, matched_evidence}], unmet[], summary{total, satisfied, unsatisfied}, evidence_sources{explicit_count, autodiscovered, autodiscovered_count, report_path}, plan_source ('memory' или 'disk'), verified_at}. Формы ошибок: no_plan_id / plan_not_found / no_evidence (только когда опущены и явные свидетельства, и auto_discover) / bad_evidence.