Files
orchestrator/docs/work-items/ORCH-047/02-trz.md
claude-bot c3879f2b80
All checks were successful
CI / test (push) Successful in 12s
analyst(ET): auto-commit from analyst run_id=125
2026-06-05 20:44:58 +00:00

6.0 KiB
Raw Blame History

ТЗ — ORCH-047: _parse_tests_verdict читает result: наравне с verdict:/status:

1. Задействованные модули src/

Файл Что меняется
src/qg/checks.py Функция _parse_tests_verdict (стр. ~223265). Добавить чтение поля result: из frontmatter и включить его в проверку токенов наравне с verdict:/status:. Обновить докстринг функции и check_tests_passed.

Точка входа check_tests_passed(repo, work_item_id, branch) (стр. ~182) и реестр QG_CHECKS НЕ меняются (сигнатура и имя гейта те же).

2. Требуемое поведение _parse_tests_verdict

Вход — строковое тело 13-test-report.md. Выход — tuple[bool, str].

  1. Нет frontmatter (content не начинается с ---) → (False, "No YAML frontmatter ...").
  2. Frontmatter некорректен (split по --- даёт < 3 частей) → (False, "Malformed YAML frontmatter ...").
  3. YAML не парсится → (False, "Invalid YAML frontmatter ...: <e>") (никогда не raise).
  4. YAML не mapping → (False, "Malformed YAML frontmatter ... (not a mapping)").
  5. Прочитать три поля, нормализовать (str(...).upper().strip(), защита от None):
    • verdict
    • status
    • resultНОВОЕ
  6. Если ВСЕ три пусты → (False, "No machine-readable verdict/status/result in test report frontmatter").
  7. Собрать объединённую строку полей fields = f"{verdict} {status} {result}".
  8. Если в fields встречается ЛЮБОЙ negative-токен (_TESTS_NEGATIVE_TOKENS) → (False, "Test verdict: <значение> (<NEG>)"). Negative авторитетен — проверяется ПЕРВЫМ, перебивает любой positive.
  9. Иначе если встречается ЛЮБОЙ positive-токен (_TESTS_POSITIVE_TOKENS) → (True, "Test verdict: <значение> (PASS)").
  10. Иначе (заданы, но не распознаны) → (False, "No recognized PASS verdict in frontmatter (...)").

Наборы токенов НЕ изменяются (важно для обратной совместимости с enduro-trails):

_TESTS_NEGATIVE_TOKENS = ("BLOCKED", "FAILED", "FAIL", "REQUEST_CHANGES", "REJECT", "RED")
_TESTS_POSITIVE_TOKENS = ("PASSED", "PASS", "READY-TO-DEPLOY", "READY_TO_DEPLOY", "GREEN", "APPROVED")

Примечание для разработчика (порядок токенов): negative-список проверяется раньше positive — это даёт авторитетность отрицания. Внутри positive-набора "PASSED" идёт перед "PASS" лишь для аккуратного reason-текста; на результат (bool) порядок не влияет, т.к. это подстрочный поиск.

3. Контракт поля (golden source)

После изменения машиночитаемыми полями testing-гейта считаются три равноправных: result: (канон промпта тестера), verdict:, status: (легаси/enduro-trails). Достаточно ЛЮБОГО одного. Это и есть приведение гейта к тому, что тестеру велено эмитить в .openclaw/agents/tester.md (result: PASS|FAIL).

4. Изменения API

Нет. HTTP-эндпоинты (/health, /status, /queue, вебхуки) не затрагиваются. Сигнатуры функций гейта не меняются.

5. Изменения схемы БД

Нет.

6. Требования к новым QG checks

Новых гейтов нет. Меняется внутренняя логика существующего check_tests_passed (через _parse_tests_verdict). Реестр QG_CHECKS без изменений → снапшот-тест tests/test_qg_registry_snapshot.py должен остаться зелёным.

7. Артефакты pipeline (создать/обновить в этом PR)

  • docs/work-items/ORCH-047/06-adr/ADR-001-*.mdобязательно (правило 2 CLAUDE.md): ADR на изменение семантики SHARED testing-гейта (влияет на все проекты общего инстанса). Заводит архитектор.
  • docs/architecture/README.md — обновить строку о вердикт-парсере (раздел «Plane Sync», п. про машинные ключи): для testing-гейта перечислить result:/verdict:/status:.
  • CHANGELOG.md — запись fix: про ORCH-047.
  • tests/test_qg.py — добавить кейсы на result: (см. 04-test-plan.yaml).

8. Нефункциональные требования

  • Парсер не бросает исключений ни на каком вводе.
  • Изменение читает только frontmatter, не прозу (канон гейтов).
  • Полная обратная совместимость: существующие тесты TestCheckTestsPassed остаются зелёными без правок (кроме, возможно, переименования reason-строки в п.6 BRD — текст причины «No machine-readable verdict/status...» обновляется на «...verdict/status/result...», соответствующий ассерт при наличии обновить).

9. Деплой

Self-hosting: стандартный путь через deploy-staging (8501) перед прод-деплоем. Прод-контейнер orchestrator (8500) не перезапускать в рамках разработки/тестинга.