auto-sync: 2026-06-04 16:10:01

2026-06-04 16:10:01 +03:00
parent bcc2625a83
commit 8e31e3b8ab
3 changed files with 201 additions and 2 deletions
--- a/tasks/orchestrator/DEV_TASK_TESTS_VERDICT_FIX.md
+++ b/tasks/orchestrator/DEV_TASK_TESTS_VERDICT_FIX.md
@@ -0,0 +1,95 @@
+# DEV TASK: orchestrator — check_tests_passed пропускает BLOCKED/FAILED отчёты (substring "PASS")
+
+Репо: `slin@82.22.50.71:/home/slin/repos/orchestrator` (пароль `motoZ@yaz2010`).
+Push в main запрещён → **только PR в Gitea**. Gitea токен: `docker exec orchestrator printenv ORCH_GITEA_TOKEN`.
+Одна ветка `fix/tests-machine-verdict` от актуального main, **один PR**. НЕ мержить сам.
+Baseline pytest на проде: **277 passed + 9 failed** (9 = off-limits HMAC/401, НЕ чинить).
+
+---
+
+## КОНТЕКСТ / БАГ (подтверждён на ET-013, 2026-06-04)
+
+Стадия `testing → deploy` гейтится функцией `check_tests_passed` (`src/qg/checks.py:139`).
+Сейчас она делает **наивный substring-поиск**:
+
+```python
+if "PASS" in content or "All tests passed" in content:
+    return True, "Test report indicates PASS"
+```
+
+`content` — это весь `docs/work-items/<WI>/13-test-report.md`.
+
+### Что пошло не так на ET-013
+Тестер ЯВНО выставил машинный вердикт в YAML-frontmatter:
+```yaml
+status: blocked
+verdict: BLOCKED
+```
+(причина: провален P1-критерий AC-19 — на проде нет hillshade z9-тайлов).
+
+НО в теле отчёта полно слова `PASS` («23 passed», «✅ PASS (часть AC-18)», «All checks
+passed»). Substring `"PASS"` нашёлся → гейт вернул True → задача с вердиктом **BLOCKED**
+уехала в deploy и доползла до **Done**. Недоделанная фича попала на прод.
+
+### Корень
+`check_tests_passed` не читает машинный вердикт тестера, а ищет подстроку. Это зеркальная
+проблема той, что уже ПОЧИНЕНА в `check_reviewer_verdict` (S-5, читает `verdict:` из
+frontmatter) и `check_deploy_status` (читает `deploy_status:`). `check_tests_passed`
+забыли привести к тому же контракту.
+
+---
+
+## ШАГ 0 — ПОДТВЕРДИТЬ ПО КОДУ
+1. Открой `check_tests_passed` (checks.py:139) и `check_reviewer_verdict` (checks.py:211) —
+   последняя уже читает frontmatter `verdict:` правильно, используй её как ЭТАЛОН структуры.
+2. Посмотри, какие значения вердикта реально пишет тестер. На ET-013: `verdict: BLOCKED`,
+   `status: blocked`. Проверь ещё 1-2 прошлых отчёта (`git show origin/main:docs/work-items/
+   ET-012/13-test-report.md`, ET-011) — какой вердикт у УСПЕШНЫХ (вероятно `PASS`/`PASSED`/
+   `GREEN`/`APPROVED` — зафиксируй ТОЧНЫЕ значения, чтобы не сломать прошедшие задачи).
+3. Зафиксируй verbatim в отчёте: какие значения = успех, какие = блок.
+
+## ЧТО СДЕЛАТЬ
+
+Привести `check_tests_passed` к машинному контракту, как `check_reviewer_verdict`:
+- Читать ТОЛЬКО `verdict:` (и при необходимости `status:`) из YAML-frontmatter
+  `13-test-report.md`. НЕ искать подстроку в теле.
+- Успех (return True) ТОЛЬКО при явном положительном вердикте. По образцам определи
+  множество положительных значений — как минимум `PASS`/`PASSED` (нормализуй `.upper().strip()`).
+  Если у успешных прошлых отчётов вердикт иной (напр. `GREEN`, `APPROVED`) — включи и его,
+  но ОБОСНУЙ по реальным образцам, не выдумывай.
+- Любой иной вердикт (`BLOCKED`, `FAILED`, `REQUEST_CHANGES`, пустой, нет frontmatter) →
+  return False с понятной причиной (напр. `Test verdict: BLOCKED`).
+- Файла нет → False «Test report not found» (как сейчас).
+- Невалидный YAML → False с причиной (как в check_reviewer_verdict).
+- Никогда не падать.
+
+### ВАЖНО — обратная совместимость
+- Если у УЖЕ ПРОШЕДШИХ успешных задач (ET-011, ET-012, ET-014) в отчётах НЕТ frontmatter-
+  вердикта (старый формат) — реши аккуратно: либо считать отсутствие вердикта блоком (строго,
+  но может сломать тесты), либо оставить узкий fallback. ПРЕДПОЧТИТЕЛЬНО строгий машинный
+  контракт; если это ломает существующие pytest-фикстуры — почини фикстуры под новый контракт
+  (добавь им `verdict: PASS`), а не ослабляй проверку. Опиши решение в отчёте.
+
+### НЕ ТРОГАТЬ
+- `check_reviewer_verdict`, `check_deploy_status` (эталоны, уже верные), merge-gate gitea.py,
+  PLANE_STATES, set_issue_done, launcher deployer-guard, HMAC, queue, usage_comment/Plane-
+  комменты, cost_usd, формат трекера/Итого, миграции, stages.py mapping. Только
+  `check_tests_passed` + его тесты (+ при необходимости фикстуры тест-отчётов).
+
+## ТЕСТЫ (обязательно)
+- `verdict: PASS` (или подтверждённое успешное значение) в frontmatter → True.
+- `verdict: BLOCKED` + тело со словом «PASS» (кейс ET-013!) → **False** (главный кейс).
+- `verdict: FAILED` → False.
+- Тело содержит «23 passed», но frontmatter `verdict: BLOCKED` → False (substring больше не обманывает).
+- Нет frontmatter / нет вердикта → False.
+- Невалидный YAML → False, не исключение.
+- Файла нет → False «not found».
+- Полный pytest зелёный кроме тех же 9 off-limits.
+
+## СДАЧА
+- Ветка `fix/tests-machine-verdict`, один PR. НЕ мержить — на ревью Стрим.
+- Отчёт: `tasks/orchestrator/reports/dev-2026-06-04-tests-verdict-fix.md` — commit, PR-номер,
+  вывод pytest, какие значения вердикта = успех (по реальным образцам ET-011/012/014),
+  до/после поведения на кейсе ET-013, как решена обратная совместимость.
+- Перенос на прод: scp нет → `base64 | ssh 'base64 -d'` или docker cp.
+- Сообщить: PR-номер, pytest, краткое описание.
--- a/tasks/orchestrator/STATUS.md
+++ b/tasks/orchestrator/STATUS.md
@@ -13,13 +13,21 @@
 | **PR #21** живой Telegram-трекер B+ (одно editMessageText-сообщение, умные пинги только на алерты) | 🟢 смержен (`3e5c74ce`), на проде |
 | **PR #22** фикс трекера: дубли (`not modified`=успех, send только при `gone`) + `🔄 Review · попытка N` | 🟢 смержен (`b222d7af`), на проде |
 | **PR #23** фикс деплой-гейта (ложный FAILED, рассинхрон путей `14-deploy-log.md`; fallback на `origin/main`) | 🟢 смержен (`34894f46`), на проде |
-| **Доска ET синхронизирована** (6 Done + ET-8 Done вручную + ET-4 Cancelled) | 🟢 сделано |
+| **PR #24** фикс гейта тестов: `check_tests_passed` читал substring "PASS" вместо машинного вердикта → BLOCKED-задачи уезжали в Done | 🟢 смержен (`83f5020f`), на проде |
+| **ET-8 переоткрыта** (фича НЕ работает на проде — нет тайлов hillshade z8-z9) → Backlog | 🔴 в работе (нужна генерация тайлов) |
+| **Доска ET** (5 Done + ET-4 Cancelled + ET-8 Backlog + ET-9 Done) | 🟢 синхронизирована |

 **Детали:** `🐛 Известные баги` ниже + `memory/2026-06-04.md` + reports `dev-2026-06-04-*`.

 ---

-## 🐛 Известные баги (живой трекер + деплой, 2026-06-04)
+## 🐛 Известные баги (живой трекер + деплой + гейт тестов, 2026-06-04)
+
+### ✅ Баг C — гейт тестов пропускал BLOCKED (substring "PASS", ИСПРАВЛЕН PR #24)
+- **Симптом:** ET-8/ET-013 «по-прежнему мелко» на проде — недоделанная фича уехала в Done.
+- **Корень:** `check_tests_passed` (qg/checks.py:139) делал `if "PASS" in content`. Тестер выставил `verdict: BLOCKED` / `status: blocked` (провал P1 AC-19: нет hillshade z9), но в теле отчёта были слова «23 passed» / «✅ PASS» → substring нашёлся → True → deploy → Done. Подрывал автономность: любой BLOCKED-отчёт со словом PASS проезжал до прода.
+- **Фикс (PR #24, `83f5020f`):** `check_tests_passed` читает машинный `verdict:`/`status:` из frontmatter (зеркало check_reviewer_verdict / check_deploy_status). Набор токенов (вердикты тестера неединообразны по истории): negative (BLOCKED/FAILED/FAIL/REQUEST_CHANGES/REJECT/RED) — authoritative, перебивают positive (PASS/PASSED/READY-TO-DEPLOY/GREEN/APPROVED). 285 passed / 9 off-limits. ET-013 → False (BLOCKED), все 9 прошедших WI → True.
+

 ### ✅ Баг A — трекер плодит дубли сообщений (ИСПРАВЛЕН, PR #22)
 - **Симптом:** вместо одного редактируемого сообщения — новые на каждом цикле. На ET-013: 21 editMessageText / 7 sendMessage = 7 дублей.
--- a/tasks/orchestrator/reports/dev-2026-06-04-tests-verdict-fix.md
+++ b/tasks/orchestrator/reports/dev-2026-06-04-tests-verdict-fix.md
@@ -0,0 +1,96 @@
+# Dev Report: orchestrator — check_tests_passed машинный вердикт (ET-013 fix)
+Дата: 2026-06-04
+Статус: DONE
+
+## Задача
+`check_tests_passed` (src/qg/checks.py:139) гейтила стадию testing→deploy наивным
+substring-поиском `if "PASS" in content` по всему телу `13-test-report.md`. На ET-013
+тестер выставил `verdict: BLOCKED` / `status: blocked` (провален P1 AC-19), но в теле
+были слова «23 passed», «✅ PASS», «All checks passed» → substring нашёлся → True →
+недоделанная фича уехала в deploy и доползла до Done. Нужно привести функцию к
+машинному контракту, как у уже починённых `check_reviewer_verdict` и `check_deploy_status`.
+
+## Сделано
+- [x] ШАГ 0: изучил `check_reviewer_verdict` (эталон, читает `verdict:` из frontmatter)
+- [x] Собрал РЕАЛЬНЫЕ значения вердикта по прошлым отчётам ET-001..ET-014
+- [x] Переписал `check_tests_passed` + добавил `_parse_tests_verdict` (зеркало эталона)
+- [x] Обновил/расширил тесты `TestCheckTestsPassed` (3 → 11 тестов)
+- [x] Прогнал unit + полный pytest
+- [x] Провалидировал на РЕАЛЬНЫХ отчётах прод-репозитория
+- [x] Ветка `fix/tests-machine-verdict`, push, PR #24 (НЕ мержил)
+
+## Изменённые файлы
+- `src/qg/checks.py` — `check_tests_passed` теперь читает ТОЛЬКО frontmatter; новый
+  helper `_parse_tests_verdict`. НЕ трогал check_reviewer_verdict / check_deploy_status.
+- `tests/test_qg.py` — класс `TestCheckTestsPassed` переписан под машинный контракт.
+
+## Положительные значения вердикта по РЕАЛЬНЫМ образцам (verbatim)
+| WI     | verdict (raw)               | status (raw)        | трактовка |
+|--------|-----------------------------|---------------------|-----------|
+| ET-001 | `PASS`                      | `pass`              | ✅ True   |
+| ET-002 | `PASS`                      | `pass`              | ✅ True   |
+| ET-005 | `PASS`                      | `pass`              | ✅ True   |
+| ET-006 | `ready-to-deploy`           | `PASSED`            | ✅ True   |
+| ET-007 | `PASS — ready-to-deploy`    | `PASS`              | ✅ True   |
+| ET-008 | `stage:ready-to-deploy`     | `pass`              | ✅ True   |
+| ET-009 | `PASS`                      | `PASS`              | ✅ True   |
+| ET-011 | `PASS`                      | (нет)               | ✅ True   |
+| ET-012 | `PASS`                      | `ready-to-deploy`   | ✅ True   |
+| ET-013 | `BLOCKED`                   | `blocked`           | ❌ False  |
+| ET-014 | `PASS`                      | (нет)               | ✅ True   |
+
+**Вывод:** поле `verdict` у тестера НЕ единообразно. Чисто `verdict == "PASS"`
+сломал бы ET-006 (`ready-to-deploy`) и ET-008 (`stage:ready-to-deploy`). Поэтому:
+- **Positive tokens** (нормализация `.upper().strip()`, поиск токена в `verdict`+`status`):
+  `PASSED`, `PASS`, `READY-TO-DEPLOY`, `READY_TO_DEPLOY`, `GREEN`, `APPROVED`.
+- **Negative tokens (авторитетны)**: `BLOCKED`, `FAILED`, `FAIL`, `REQUEST_CHANGES`, `REJECT`, `RED`.
+- Логика: нет frontmatter / битый YAML / нет ни verdict ни status → False с причиной;
+  негативный токен в любом из полей → False (перебивает любой PASS); иначе позитивный
+  токен → True; иначе → False. Никогда не падает.
+
+## Результат — до/после на ET-013 (на реальном файле прод-репо)
+- **До:** substring `"PASS"` в теле → `(True, "Test report indicates PASS")` → deploy.
+- **После:** `_parse_tests_verdict` → `(False, 'Test verdict: BLOCKED (BLOCKED)')` → блок.
+
+Прогон на РЕАЛЬНЫХ отчётах (`/repos/_wt/enduro-trails/feature_ET-014-ui-z-index`):
+```
+ET-001 (True, 'Test verdict: PASS (PASS)')
+ET-005 (True, 'Test verdict: PASS (PASS)')
+ET-006 (True, 'Test verdict: READY-TO-DEPLOY (PASS)')
+ET-007 (True, 'Test verdict: PASS — READY-TO-DEPLOY (PASS)')
+ET-008 (True, 'Test verdict: STAGE:READY-TO-DEPLOY (PASS)')
+ET-009 (True, 'Test verdict: PASS (PASS)')
+ET-011 (True, 'Test verdict: PASS (PASS)')
+ET-012 (True, 'Test verdict: PASS (PASS)')
+ET-013 (False, 'Test verdict: BLOCKED (BLOCKED)')   <-- bug fixed
+ET-014 (True, 'Test verdict: PASS (PASS)')
+```
+Все 9 ранее прошедших WI остаются True; ET-013 → False. Регрессий нет.
+
+## Обратная совместимость
+Строгий машинный контракт сохранён БЕЗ ослабления: у всех реальных прошедших отчётов
+ЕСТЬ frontmatter с положительным `verdict:`/`status:`, поэтому fallback на тело не нужен.
+Единственная «несовместимость» была в старых pytest-фикстурах (`Result: PASS` в теле без
+frontmatter) — они описывали старое substring-поведение. Согласно ТЗ их ПОЧИНИЛ под новый
+контракт (добавил frontmatter `verdict:`), а не ослабил проверку. Отсутствие frontmatter
+теперь = False (`test_no_frontmatter_fails`).
+
+## Тесты (pytest, прод-контейнер на /repos/orchestrator)
+- `TestCheckTestsPassed`: **11 passed** (включая главный кейс ET-013, FAILED, "23 passed"
+  в теле при BLOCKED, нет frontmatter, нет полей, битый YAML, файла нет).
+- Полный прогон: **285 passed, 9 failed**. 9 failed = off-limits `test_webhooks.py`
+  HMAC/401 — подтверждено pre-existing: при застешенных моих правках на чистом main те же
+  webhook-тесты падают (их число плавает 9–10 от запуска к запуску, порядко-зависимы).
+  Мои изменения их не затрагивают (только `check_tests_passed` + его тесты).
+  *Прим.:* baseline в ТЗ заявлен 277+9; фактический на этом окружении 276+10 до правки →
+  285+9 после (net +9 passed: класс вырос 3→11 тестов, минус один плавающий webhook-фейл).
+
+## Сдача
+- Ветка: `fix/tests-machine-verdict` (от актуального origin/main, push выполнен).
+- PR: **#24** — http://localhost:3000/admin/orchestrator/pulls/24
+  (внешний: https://git.mva154.duckdns.org/admin/orchestrator/pulls/24). НЕ мержил — на ревью Стрим.
+- В main НЕ пушил.
+
+## НЕ трогал
+check_reviewer_verdict, check_deploy_status, gitea.py merge-gate, PLANE_STATES,
+set_issue_done, launcher deployer-guard, HMAC, queue, stages.py mapping.