docs: Product Vision платформы (MD + PPTX, 8 слайдов)

check_tests_passed did "if PASS in content" over the whole 13-test-report.md
body, so a report explicitly marked verdict: BLOCKED / status: blocked whose
prose mentioned "23 passed" / "PASS" / "All checks passed" passed the gate.
On ET-013 an unfinished feature (P1 AC-19 failed) reached Done.

Now mirrors check_reviewer_verdict (S-5) and check_deploy_status: read ONLY the
YAML frontmatter verdict:/status: fields. Positive tokens (PASS/PASSED/
READY-TO-DEPLOY/GREEN/APPROVED) -> True; negative tokens (BLOCKED/FAILED/...) are
authoritative -> False; missing/empty/no-frontmatter/bad-YAML -> False with reason;
file missing -> not found. Never raises.

Positive token set derived from REAL enduro-trails reports ET-001..ET-014
(inconsistent: PASS, ready-to-deploy+status:PASSED, stage:ready-to-deploy+status:pass,
PASS — ready-to-deploy). Validated: all 9 prior passing WIs stay True, ET-013 -> False.

docs/PRODUCT_VISION.md

@@ -0,0 +1,132 @@
+# Product Vision — Автономная фабрика разработки (Orchestrator)
+
+> Мультиагентная платформа, которая превращает идею или баг в задеплоенный на прод результат — автономно, надёжно и дёшево.
+
+**Версия:** 1.0 · **Дата:** 2026-06-04 · **Статус:** концепция развития
+
+---
+
+## 1. Зачем это (бизнес-взгляд)
+
+### Проблема
+Классическая разработка — это люди-бутылочное-горлышко на каждом шаге: аналитик, архитектор, разработчик, ревьюер, тестировщик, деплой-инженер. Каждая передача задачи между ними — потеря времени, контекста и денег. Мелкая фича или баг едут днями.
+
+### Решение
+**Orchestrator** — это конвейер из ИИ-агентов, который проводит задачу через все стадии разработки сам: от бизнес-постановки до релиза на прод. Человек ставит задачу и принимает результат. Всё между — автономно.
+
+### Ценность
+- ⚡ **Скорость:** фича проходит полный цикл (анализ → архитектура → код → ревью → тесты → деплой) за ~35 минут без ручных вмешательств.
+- 💰 **Стоимость:** работа агентов в разы дешевле команды; адаптивный выбор моделей экономит на простых задачах.
+- 🎯 **Автономность:** 0 ручных пинков в штатном прогоне. Человек — постановщик и приёмщик, а не оператор.
+- 🛡️ **Надёжность:** многоуровневые гейты качества не пускают недоделку на прод.
+- 🔁 **Масштаб:** одна платформа ведёт несколько проектов; саму платформу можно тиражировать на новые хосты.
+
+---
+
+## 2. Как это работает (обзор)
+
+### Конвейер
+```
+created → analysis → architecture → development → review → testing → deploy → done
+```
+На каждом переходе стоит **quality gate** — автоматическая проверка, которая не пускает задачу дальше, пока стадия не выполнена честно:
+
+| Переход | Гейт | Что проверяет |
+|---|---|---|
+| analysis → architecture | check_analysis_approved | BRD/TRZ/AC готовы + апрув человека |
+| architecture → development | check_architecture_done | Архитектура/ADR зафиксированы |
+| development → review | check_ci_green | CI зелёный (тесты проходят) |
+| review → testing | check_reviewer_verdict | Машинный вердикт ревьюера: APPROVED |
+| testing → deploy | check_tests_passed | Машинный вердикт тестера (не подделать) |
+| deploy → done | check_deploy_status | Деплой реально успешен, лог в origin/main |
+
+### Агенты
+- **Analyst** — собирает бизнес-требования, пишет BRD/TRZ/критерии приёмки.
+- **Architect** — проектирует решение, фиксирует ADR.
+- **Developer** — пишет код в изолированном git-worktree.
+- **Reviewer** — ревьюит, выносит машинный вердикт.
+- **Tester** — прогоняет тесты, фиксирует результат в отчёте.
+- **Deployer** — мержит, тегирует, деплоит на прод, пишет deploy-log.
+
+### Объекты
+- **Project** — проект в реестре (Plane project ↔ git-репозиторий ↔ префикс задач).
+- **Work-Item** — задача, проходящая конвейер; на каждой стадии накапливает артефакты (00-business-request … 14-deploy-log).
+- **Job** — единица работы в очереди (atomic claim, ретраи, restart-safe).
+
+### Интеграции
+- **Plane** — управление задачами, статусы как триггеры конвейера, webhooks.
+- **Gitea** — репозитории, PR, защита main (pre-receive hook).
+- **Telegram** — живой трекер прогресса, апрувы, уведомления.
+- **LLM** — модели агентов (сейчас Claude, в планах мультипровайдерность).
+
+---
+
+## 3. Что уже сделано (фундамент)
+
+✅ **Автономный конвейер** — подтверждён живым прогоном: задача от issue до Done без ручных вмешательств (~35 мин).
+✅ **Очередь задач** — atomic claim, max_concurrency, ретраи, restart-safe.
+✅ **Изоляция через git-worktree** — каждая задача в своём дереве, без конфликтов в shared-репо.
+✅ **Машинные гейты качества** — вердикты читаются из структурированных артефактов, а не угадываются по тексту.
+✅ **Multi-repo** — платформа ведёт несколько проектов (enduro-trails, сам orchestrator).
+✅ **Идемпотентность webhooks** — дедуп по delivery-id, защита от дублей.
+✅ **Наблюдаемость** — учёт токенов и стоимости каждой задачи.
+✅ **Живой Telegram-трекер** — прогресс редактируется в одном сообщении, без спама.
+
+---
+
+## 4. Куда движемся (дорожная карта)
+
+Развитие сгруппировано в 5 стратегических направлений.
+
+### 🛡️ Надёжность и безопасность
+- **Post-deploy мониторинг + авто-rollback** — следить за продом после релиза, откатывать при деградации.
+- **Security-гейт** — secret-scanning + аудит зависимостей перед мержем.
+- **Бюджетный circuit-breaker** — хард-лимит стоимости на задачу, защита от «убегающих» расходов.
+- **Опциональная human-приёмка** — финальный взгляд человека для критичных фич.
+
+### 💰 Экономика и интеллект
+- **Мультипровайдерность LLM** — Claude, OpenRouter, другие провайдеры на выбор.
+- **Оценка задачи** — прогноз стоимости/времени до старта.
+- **Адаптивный выбор модели** — по сложности: тривиальное на дешёвой, сложное на сильной.
+- **Багфикс-трек** — упрощённый дешёвый путь для багов (без потери качества).
+
+### 🏗️ Платформа и масштаб
+- **Self-hosting** — оркестратор пилит сам себя через собственный конвейер.
+- **Саморазвитие** — петля уроков: ловить отклонения → фиксировать → предлагать улучшения.
+- **Онбординг проектов** — turnkey-заведение нового проекта в систему.
+- **Тиражирование** — развернуть платформу на новой инфраструктуре под ключ.
+
+### 💬 Взаимодействие с человеком
+- **UX/UI дизайнер** — макеты интерфейсов на этапе аналитики.
+- **Интерактивный аналитик** — живой диалог для уточнения требований и обсуждения макетов.
+- **Единые коммент-артефакты** — все агенты прикладывают результаты с кликабельными ссылками.
+- **Прямые ссылки в Telegram** — апрув в один клик, без блужданий.
+
+### 🧩 Расширение возможностей
+- **Тяжёлые расчёты данных** — опциональная стадия для миграций/обработки больших данных.
+- **Android-разработка** — мобильный стек через тот же конвейер.
+- **Декомпозиция эпиков** — большая фича → подзадачи → сборка.
+- **Управление зависимостями** — задача B ждёт задачу A.
+- **Code coverage gate** — защита покрытия тестами от деградации.
+- **База знаний проекта** — персистентный контекст для агентов.
+
+---
+
+## 5. Принципы (что для нас неизменно)
+
+1. **Автономность по умолчанию, человек — на ключевых развилках.** Машина делает, человек ставит и принимает.
+2. **Качество не приносится в жертву скорости/цене.** Удешевляем аналитику — гейты качества остаются. Урок дорого выученный: срезанная проверка = недоделка на проде.
+3. **Машинные вердикты, а не угадывание.** Гейты читают структурированные поля, а не ищут слова в тексте.
+4. **Самоизменение — только через PR + ревью + апрув.** Агент, меняющий агентов, всегда под контролем человека.
+5. **Документация — сразу, не потом.** Изменил функционал → обновил доки.
+6. **Прод — источник правды.** «Деплой прошёл» ≠ «работает». Проверяем реальный результат.
+
+---
+
+## 6. Видение в одну фразу
+
+> **Самодостаточная фабрика разработки, которая размножается, учится на ошибках, оценивает себя, бережёт бюджет и не ломает прод — превращая намерение человека в работающий продукт почти без его участия.**
+
+---
+
+*Документ поддерживается в репозитории orchestrator. Источник дорожной карты — задачи проекта ORCH в Plane (ORCH-7…ORCH-28).*

src/qg/checks.py

@@ -138,7 +138,16 @@ def check_review_approved(repo: str, pr_number: int) -> tuple[bool, str]:
 
 def check_tests_passed(repo: str, work_item_id: str, branch: str | None = None) -> tuple[bool, str]:
     """
-    Check if test report exists and contains PASS indicator.
+    Gate the testing -> deploy transition on the tester's MACHINE-READABLE verdict
+    in 13-test-report.md frontmatter, NOT on a naive substring search of the body.
+
+    ET-013 fix: the previous implementation did `if "PASS" in content`, so a report
+    explicitly marked `verdict: BLOCKED` / `status: blocked` but whose prose mentioned
+    "23 passed" / "✅ PASS" / "All checks passed" was treated as a pass, and an
+    unfinished feature reached Done. This mirrors check_reviewer_verdict (S-5) and
+    check_deploy_status (БАГ 8): read ONLY the YAML frontmatter `verdict:` / `status:`
+    fields, never the body.
+
     File: docs/work-items/<work_item_id>/13-test-report.md
     """
     repo_path = _repo_path(repo, branch)
@@ -150,12 +159,67 @@ def check_tests_passed(repo: str, work_item_id: str, branch: str | None = None)
     try:
         with open(report_path, "r") as f:
             content = f.read()
-        if "PASS" in content or "All tests passed" in content:
-            return True, "Test report indicates PASS"
-        return False, "Test report exists but no PASS indicator found"
     except OSError as e:
         return False, f"Error reading test report: {e}"
 
+    return _parse_tests_verdict(content)
+
+
+# Positive / negative verdict tokens, derived from REAL tester reports in
+# enduro-trails (ET-001..ET-014). The tester is inconsistent: most write
+# `verdict: PASS`, but ET-006 used `verdict: ready-to-deploy` (with `status: PASSED`),
+# ET-007 `verdict: PASS — ready-to-deploy`, ET-008 `verdict: stage:ready-to-deploy`
+# (with `status: pass`). ET-013 (the bug) used `verdict: BLOCKED` / `status: blocked`.
+# We therefore match known positive/negative TOKENS inside the normalized
+# verdict/status fields, and treat a negative token as authoritative (a BLOCKED/FAILED
+# report never passes, even if another field looks positive).
+_TESTS_NEGATIVE_TOKENS = ("BLOCKED", "FAILED", "FAIL", "REQUEST_CHANGES", "REJECT", "RED")
+_TESTS_POSITIVE_TOKENS = ("PASSED", "PASS", "READY-TO-DEPLOY", "READY_TO_DEPLOY", "GREEN", "APPROVED")
+
+
+def _parse_tests_verdict(content: str) -> tuple[bool, str]:
+    """Map a 13-test-report.md body to a quality-gate verdict by reading ONLY the
+    machine-readable `verdict:` (and corroborating `status:`) YAML frontmatter fields.
+
+    Rules:
+      - No frontmatter / bad YAML / neither field present -> (False, reason).
+      - A negative token (BLOCKED/FAILED/...) in verdict OR status -> (False) and is
+        authoritative (ET-013 main case: verdict BLOCKED wins over any prose PASS).
+      - Otherwise a positive token (PASS/PASSED/READY-TO-DEPLOY/...) in verdict OR
+        status -> (True).
+      - Anything else (unrecognized / empty verdict) -> (False, reason).
+    """
+    import yaml
+
+    if not content.startswith("---"):
+        return False, "No YAML frontmatter in test report (cannot read machine verdict)"
+
+    parts = content.split("---", 2)
+    if len(parts) < 3:
+        return False, "Malformed YAML frontmatter in test report"
+
+    try:
+        fm = yaml.safe_load(parts[1]) or {}
+    except yaml.YAMLError as e:
+        return False, f"Invalid YAML frontmatter in test report: {e}"
+    if not isinstance(fm, dict):
+        return False, "Malformed YAML frontmatter in test report (not a mapping)"
+
+    verdict = str(fm.get("verdict", "") or "").upper().strip()
+    status = str(fm.get("status", "") or "").upper().strip()
+
+    if not verdict and not status:
+        return False, "No machine-readable verdict/status in test report frontmatter"
+
+    fields = f"{verdict} {status}"
+    for neg in _TESTS_NEGATIVE_TOKENS:
+        if neg in fields:
+            return False, f"Test verdict: {verdict or status} ({neg})"
+    for pos in _TESTS_POSITIVE_TOKENS:
+        if pos in fields:
+            return True, f"Test verdict: {verdict or status} (PASS)"
+
+    return False, f"No recognized PASS verdict in frontmatter (verdict={verdict!r}, status={status!r})"
 
 
 def check_analysis_approved(repo: str, work_item_id: str, branch: str | None = None) -> tuple[bool, str]:

tests/test_qg.py

@@ -167,23 +167,110 @@ class TestCheckReviewApproved:
 
 
 class TestCheckTestsPassed:
-    def test_report_with_pass(self, setup_work_item_dir):
-        repo_dir = setup_work_item_dir
-        wi_dir = repo_dir / "docs" / "work-items" / "ET-001"
-        wi_dir.mkdir(parents=True)
-        (wi_dir / "13-test-report.md").write_text("# Test Report\n\nResult: PASS\n")
+    """ET-013 fix: testing -> deploy gate reads the tester's MACHINE-READABLE verdict
+    in 13-test-report.md frontmatter (verdict:/status:), NOT a substring of the body.
+    Mirrors check_reviewer_verdict / check_deploy_status. The old `if "PASS" in content`
+    let a `verdict: BLOCKED` report whose prose said "23 passed"/"✅ PASS" pass the gate,
+    shipping an unfinished feature to Done."""
 
+    def _write(self, repo_dir, content, wi="ET-001"):
+        wi_dir = repo_dir / "docs" / "work-items" / wi
+        wi_dir.mkdir(parents=True)
+        (wi_dir / "13-test-report.md").write_text(content)
+
+    def test_verdict_pass_passes(self, setup_work_item_dir):
+        # Most common real form (ET-001/002/005/009/011/012/014).
+        self._write(
+            setup_work_item_dir,
+            "---\ntype: test-report\nverdict: PASS\nstatus: pass\n---\n\n# Test Report\n",
+        )
+        passed, reason = check_tests_passed("enduro-trails", "ET-001")
+        assert passed is True
+        assert "PASS" in reason
+
+    def test_verdict_pass_ready_to_deploy_passes(self, setup_work_item_dir):
+        # ET-007 real form: "PASS — ready-to-deploy".
+        self._write(
+            setup_work_item_dir,
+            "---\nverdict: PASS — ready-to-deploy\nstatus: PASS\n---\n\nbody\n",
+        )
         passed, reason = check_tests_passed("enduro-trails", "ET-001")
         assert passed is True
 
-    def test_report_without_pass(self, setup_work_item_dir):
-        repo_dir = setup_work_item_dir
-        wi_dir = repo_dir / "docs" / "work-items" / "ET-001"
-        wi_dir.mkdir(parents=True)
-        (wi_dir / "13-test-report.md").write_text("# Test Report\n\nResult: FAIL\n")
+    def test_verdict_ready_to_deploy_with_status_passed_passes(self, setup_work_item_dir):
+        # ET-006 real form: verdict has no PASS word, but status: PASSED.
+        self._write(
+            setup_work_item_dir,
+            "---\nverdict: ready-to-deploy\nstatus: PASSED\n---\n\nbody\n",
+        )
+        passed, reason = check_tests_passed("enduro-trails", "ET-001")
+        assert passed is True
 
+    def test_verdict_stage_ready_to_deploy_with_status_pass_passes(self, setup_work_item_dir):
+        # ET-008 real form: verdict: stage:ready-to-deploy, status: pass.
+        self._write(
+            setup_work_item_dir,
+            "---\nverdict: stage:ready-to-deploy\nstatus: pass\n---\n\nbody\n",
+        )
+        passed, reason = check_tests_passed("enduro-trails", "ET-001")
+        assert passed is True
+
+    def test_blocked_verdict_with_pass_in_body_fails(self, setup_work_item_dir):
+        # THE ET-013 BUG: verdict BLOCKED but body is full of "PASS"/"passed".
+        self._write(
+            setup_work_item_dir,
+            "---\ntype: test-report\nstatus: blocked\nverdict: BLOCKED\n---\n\n"
+            "23 passed\n✅ PASS (часть AC-18)\nAll checks passed\n",
+        )
         passed, reason = check_tests_passed("enduro-trails", "ET-001")
         assert passed is False
+        assert "BLOCKED" in reason
+
+    def test_failed_verdict_fails(self, setup_work_item_dir):
+        self._write(
+            setup_work_item_dir,
+            "---\nverdict: FAILED\nstatus: failed\n---\n\nbody\n",
+        )
+        passed, reason = check_tests_passed("enduro-trails", "ET-001")
+        assert passed is False
+        assert "FAILED" in reason
+
+    def test_passed_count_in_body_but_blocked_verdict_fails(self, setup_work_item_dir):
+        # Body says "23 passed" but frontmatter verdict BLOCKED -> substring no longer fools.
+        self._write(
+            setup_work_item_dir,
+            "---\nverdict: BLOCKED\n---\n\nTests: 23 passed, 0 failed.\n",
+        )
+        passed, reason = check_tests_passed("enduro-trails", "ET-001")
+        assert passed is False
+
+    def test_no_frontmatter_fails(self, setup_work_item_dir):
+        # Old format / prose only -> no machine verdict -> fail.
+        self._write(
+            setup_work_item_dir,
+            "# Test Report\n\nResult: PASS\nAll tests passed.\n",
+        )
+        passed, reason = check_tests_passed("enduro-trails", "ET-001")
+        assert passed is False
+
+    def test_no_verdict_field_fails(self, setup_work_item_dir):
+        # Frontmatter present but neither verdict nor status -> fail.
+        self._write(
+            setup_work_item_dir,
+            "---\ntype: test-report\nversion: 1\n---\n\nResult: PASS\n",
+        )
+        passed, reason = check_tests_passed("enduro-trails", "ET-001")
+        assert passed is False
+
+    def test_invalid_yaml_fails_no_exception(self, setup_work_item_dir):
+        # Broken YAML frontmatter -> False with reason, never raises.
+        self._write(
+            setup_work_item_dir,
+            "---\nverdict: [unclosed\n  : : :\n---\n\nbody PASS\n",
+        )
+        passed, reason = check_tests_passed("enduro-trails", "ET-001")
+        assert passed is False
+        assert "YAML" in reason or "frontmatter" in reason.lower()
 
     def test_no_report(self, setup_work_item_dir):
         passed, reason = check_tests_passed("enduro-trails", "ET-001")