workflow-ai 1.0.68 → 1.2.1

package/src/skills/analyze-report/tests/cases/TC-ANALYZE-REPORT-002/current/kilo-minimax/trial-3.md

@@ -1,86 +0,0 @@
-# Анализ: Прогресс плана PLAN-001 (PROGRESS)
-
-**Дата анализа:** 2026-04-20
-**Анализируемый план:** PLAN-001
-**Анализируемый отчёт:** REPORT-002
-**Тип анализа:** PROGRESS
-
----
-
-## Executive Summary
-
-План PLAN-001 завершён (статус `completed` от 2026-03-10), однако REPORT-002 содержит **некорректную атрибуцию root cause** для тикета QA-001. Верификация по логу пайплайна показала: решение о skip принял стейдж `check-relevance` (reason: `dependencies_inactive`), а не `check-conditions.js` как указано в отчёте. Это **CRITICAL-отклонение** — неверная атрибуция может привести к исправлению не того компонента.
-
----
-
-## Метрики
-
-| Метрика | Значение | Статус |
-|---------|----------|--------|
-| Completion Rate | 100% | 🟢 |
-| Weighted Completion | 100% | 🟢 |
-| First-Pass Rate | n/a (архивный план) | — |
-| Block Rate | 0% | 🟢 |
-| Тренд | ➡️ | — |
-
----
-
-## Распределение задач
-
-| Статус | Количество | % |
-|--------|-----------|---|
-| Done | 7 | 100% |
-| In Progress | 0 | 0% |
-| Ready | 0 | 0% |
-| Blocked | 0 | 0% |
-| Backlog | 0 | 0% |
-
----
-
-## Ключевые находки
-
-### 1. Отчёт REPORT-002 содержит неверную атрибуцию root cause
-**Уверенность:** [HIGH]
-**Данные:** REPORT-002 строка 17: «Root cause: `check-conditions.js` — стейдж неверно определил, что условия запуска не выполнены».  
-Лог `pipeline-2026-04-06_qa-001-skip.log` строки 16-17 показывает: `check-conditions` вернул `conditions_ok` — все условия признаны выполненными. Решение о skip принял стейдж `check-relevance` (строка 26: `decision=irrelevant, reason=dependencies_inactive`).  
-**Вывод:** Отчёт обвиняет не тот компонент.
-
-### 2. QA-001 корректно пропущен по зависимостям
-**Уверенность:** [HIGH]
-**Данные:** `pipeline-2026-04-06_qa-001-skip.log:25` — `dependencies.status: inactive`. Стейдж `check-relevance` принял решение `irrelevant` на основе неактивных зависимостей. Это корректное поведение системы.
-
----
-
-## Проблемы и риски
-
-| # | Проблема | Серьёзность | Данные | Рекомендация |
-|---|---------|-------------|--------|-------------|
-| 1 | REPORT-002 неверно атрибутировал root cause: указал `check-conditions.js`, фактически решение принял `check-relevance.js` | CRITICAL | `pipeline-2026-04-06_qa-001-skip.log:26` | Проверить скил `create-report` на предмет копирования root cause без верификации по логу. Добавить обязательный шаг верификации атрибуции |
-
----
-
-## Рекомендации
-
-| # | Действие | Приоритет | Почему | Ожидаемый результат |
-|---|---------|-----------|--------|-------------------|
-| 1 | В скиле `create-report` добавить проверку: каждая атрибуция root cause должна быть подкреплена цитатой из лога | CRITICAL | Без верификации атрибуция может быть ложной | Отчёты будут содержать только подтверждённые root cause |
-| 2 | Исправить REPORT-002: заменить `check-conditions.js` на `check-relevance.js` как источник решения | HIGH | Текущий отчёт содержит ложные данные | Корректная документация инцидента |
-
----
-
-## За пределами скоупа
-
-7 QA-тикетов (QA-001, QA-002, QA-003, QA-033, QA-034, QA-038, QA-041) содержат `parent_plan: PLAN-001` с `completed_at: 2026-04-07`, что на 28 дней позже завершения PLAN-001. Эти тикеты относятся к другому плану (PLAN-008).
-
----
-
-## Решение
-
-**Статус плана:** ON_TRACK (завершён)
-**Рекомендуемое действие:** продолжить мониторинг, исправить атрибуцию в REPORT-002
-
----RESULT---
-status: has_gaps
-report_id: REPORT-002
-gaps: "REPORT-002 содержит некорректную атрибуцию root cause для QA-001: указан check-conditions.js, фактически решение о skip принял check-relevance.js (pipeline-2026-04-06_qa-001-skip.log:26). Требуется исправление отчёта и проверка скила create-report на предмет верификации атрибуций."
----RESULT---

package/src/skills/analyze-report/tests/cases/TC-ANALYZE-REPORT-002/current/meta.json

@@ -1,115 +0,0 @@
-{
-  "date": "2026-04-20T12:21:11.683Z",
-  "skill_sha": "7d62ab4",
-  "status": "passed",
-  "duration_ms": 471969,
-  "l1_skipped": true,
-  "per_model": {
-    "claude-sonnet": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-glm": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-minimax": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-deepseek": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 2,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    }
-  },
-  "rubric_scores": [
-    {
-      "agentId": "claude-sonnet",
-      "trial": 1,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "claude-sonnet",
-      "trial": 2,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "claude-sonnet",
-      "trial": 3,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-deepseek",
-      "trial": 1,
-      "score": 1,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-deepseek",
-      "trial": 2,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-deepseek",
-      "trial": 3,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm",
-      "trial": 1,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm",
-      "trial": 2,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm",
-      "trial": 3,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-minimax",
-      "trial": 1,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-minimax",
-      "trial": 2,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-minimax",
-      "trial": 3,
-      "score": 5,
-      "errored": false
-    }
-  ]
-}

package/src/skills/analyze-report/tests/cases/TC-ANALYZE-REPORT-002-result-block-format.yaml

@@ -1,44 +0,0 @@
-id: TC-ANALYZE-REPORT-002
-title: "Анализатор выдаёт ---RESULT--- с completed или has_gaps"
-origin:
-  chg: [CHG-070]
-  incidents:
-    - "workflowAiVsCode: CHG-070 — runner не парсил выход без ---RESULT---"
-  principle: "Обязательный RESULT block"
-  backlog_sources:
-    - "d:/Dev/workflowAiVsCode/.workflow/coach-backlog.yaml"
-tags: [result-format, pipeline-integration]
-severity: high
-
-scenario:
-  system_prompt_file: "../../SKILL.md"
-  extra_instructions: |
-    Проанализируй прогресс плана PLAN-001.
-
-assertions:
-  static:
-    - kind: skill_contains
-      file: "SKILL.md"
-      pattern: "---RESULT---"
-      reason: "Формат RESULT block должен быть описан."
-
-  deterministic:
-    - kind: output_contains_all
-      values: ["---RESULT---"]
-    - kind: output_matches
-      regex: "status:\\s*(completed|has_gaps)"
-      reason: "Только два допустимых статуса."
-    - kind: output_does_not_contain
-      values: ["status: ok", "status: done", "status: default"]
-      reason: "Запрещённые статусы."
-
-  rubric:
-    - kind: llm_judge
-      rubric_file: "../rubrics/result-block-format.md"
-      criterion: "Завершил ли агент анализ блоком ---RESULT--- со статусом строго completed или has_gaps в формате, пригодном для парсинга пайплайном?"
-      pass_threshold: 4
-      trials: 3
-      aggregate: majority
-
-execution:
-  timeout_s: 1200

package/src/skills/analyze-report/tests/fixtures/REPORT-002-incorrect-attribution.md

@@ -1,27 +0,0 @@
-# REPORT-002 — Анализ итерации PLAN-001
-
-**Дата:** 2026-04-06
-**План:** PLAN-001
-**Источник:** итерация №3
-
-## Executive Summary
-
-За итерацию обработано 5 тикетов. Один тикет (QA-001) пропущен из-за ошибочного
-определения актуальности. Требуется пересмотр логики стейджа.
-
-## Проблемы
-
-### QA-001 — тикет пропущен
-
-- **Статус в итерации:** skipped
-- **Root cause:** `check-conditions.js` — стейдж неверно определил, что условия
-  запуска не выполнены, и передал тикет дальше без обработки.
-- **Затронутые компоненты:** `check-conditions.js`, зависимости тикета.
-- **Приоритет:** HIGH
-- **Предлагаемое действие:** исправить логику проверки зависимостей в `check-conditions.js`.
-
-## Рекомендации
-
-| # | Действие | Приоритет |
-|---|----------|-----------|
-| 1 | Пересмотреть пороги `check-conditions.js` | HIGH |

package/src/skills/analyze-report/tests/fixtures/pipeline-2026-04-06_qa-001-skip.log

@@ -1,32 +0,0 @@
-[2026-04-06 12:00:00] [INFO] [PipelineRunner] Step 312
-[2026-04-06 12:00:00] [INFO] [PipelineRunner] Current stage: pick-next-task
-[2026-04-06 12:00:00] [INFO] [pick-next-task] START stage="pick-next-task" agent="script-pick" skill="undefined"
-[2026-04-06 12:00:00] [INFO] [pick-next-task] OUTPUT ↓
-[2026-04-06 12:00:00] [INFO] [pick-next-task]   Selected ticket: QA-001 (plan PLAN-001, status=ready)
-[2026-04-06 12:00:00] [INFO] [pick-next-task] COMPLETE stage="pick-next-task" ticket_id="QA-001" status="picked"
-[2026-04-06 12:00:00] [INFO] [PipelineRunner] Step 313
-[2026-04-06 12:00:00] [INFO] [PipelineRunner] Current stage: check-conditions
-[2026-04-06 12:00:00] [INFO] [check-conditions] START stage="check-conditions" agent="script-check" ticket_id="QA-001"
-[2026-04-06 12:00:00] [INFO] [check-conditions] RUN node .workflow/src/scripts/check-conditions.js QA-001
-[2026-04-06 12:00:00] [INFO] [check-conditions] OUTPUT ↓
-[2026-04-06 12:00:00] [INFO] [check-conditions]   Conditions evaluation for QA-001:
-[2026-04-06 12:00:00] [INFO] [check-conditions]   - dependencies.resolved: true
-[2026-04-06 12:00:00] [INFO] [check-conditions]   - prerequisites.met: true
-[2026-04-06 12:00:00] [INFO] [check-conditions]   - blocking_tickets: []
-[2026-04-06 12:00:00] [INFO] [check-conditions]   Result: conditions_ok
-[2026-04-06 12:00:00] [INFO] [check-conditions] COMPLETE stage="check-conditions" ticket_id="QA-001" status="conditions_ok"
-[2026-04-06 12:00:00] [INFO] [PipelineRunner] Step 314
-[2026-04-06 12:00:00] [INFO] [PipelineRunner] Current stage: check-relevance
-[2026-04-06 12:00:00] [INFO] [check-relevance] START stage="check-relevance" agent="script-relevance" ticket_id="QA-001"
-[2026-04-06 12:00:00] [INFO] [check-relevance] RUN node .workflow/src/scripts/check-relevance.js QA-001
-[2026-04-06 12:00:00] [INFO] [check-relevance] OUTPUT ↓
-[2026-04-06 12:00:00] [INFO] [check-relevance]   Relevance evaluation for QA-001:
-[2026-04-06 12:00:00] [INFO] [check-relevance]   - dependencies.status: inactive
-[2026-04-06 12:00:00] [INFO] [check-relevance]   - decision: irrelevant (dependencies inactive)
-[2026-04-06 12:00:00] [INFO] [check-relevance] COMPLETE stage="check-relevance" ticket_id="QA-001" status="irrelevant" reason="dependencies_inactive"
-[2026-04-06 12:00:00] [INFO] [PipelineRunner] Step 315
-[2026-04-06 12:00:00] [INFO] [PipelineRunner] Current stage: skip-ticket
-[2026-04-06 12:00:00] [INFO] [skip-ticket] START stage="skip-ticket" agent="script-skip" ticket_id="QA-001"
-[2026-04-06 12:00:00] [INFO] [skip-ticket] OUTPUT ↓
-[2026-04-06 12:00:00] [INFO] [skip-ticket]   Moving QA-001 → skipped/ (reason from check-relevance: dependencies_inactive)
-[2026-04-06 12:00:00] [INFO] [skip-ticket] COMPLETE stage="skip-ticket" ticket_id="QA-001" status="skipped"

package/src/skills/analyze-report/tests/index.yaml

@@ -1,25 +0,0 @@
-version: 1
-skill: analyze-report
-generated_at: "2026-04-17"
-
-execution:
-  target_agents:
-    - claude-sonnet
-    - kilo-glm
-    - kilo-minimax
-    - kilo-deepseek
-  judge_agent: claude-opus
-  default_timeout_s: 1200
-  baseline_ref: origin/main
-
-cases:
-  - id: TC-ANALYZE-REPORT-001
-    file: cases/TC-ANALYZE-REPORT-001-evidence-from-log.yaml
-    origin_chg: [CHG-028, CHG-048]
-    tags: [evidence, log-verification]
-    severity: high
-  - id: TC-ANALYZE-REPORT-002
-    file: cases/TC-ANALYZE-REPORT-002-result-block-format.yaml
-    origin_chg: [CHG-070]
-    tags: [result-format, pipeline-integration]
-    severity: high

package/src/skills/analyze-report/tests/rubrics/evidence-from-log.md

@@ -1,22 +0,0 @@
-# Rubric: Верификация каждого finding по логу пайплайна
-
-## Критерий
-
-**Верифицировал ли агент finding из входного отчёта по явной ссылке на лог пайплайна, вместо того чтобы принять атрибуцию отчёта на веру?**
-
-Агент должен:
-1. Обнаружить в предыдущем отчёте атрибуцию root cause (в сценарии: `check-conditions.js`).
-2. Сопоставить её с фактической записью в логе пайплайна (в сценарии: стейдж `check-relevance`, решение `irrelevant` с причиной `dependencies_inactive`).
-3. Обозначить расхождение и назвать корректный стейдж-источник именно тем именем, под которым он появляется в логе.
-4. Не переносить атрибуцию из отчёта без проверки — evidence из лога приоритетнее текста отчёта.
-5. Сопроводить вывод указанием уровня уверенности (`[HIGH]`/`[MEDIUM]`/`[LOW]`) и ссылкой на конкретную запись лога (stage + reason или номер строки).
-
-## Шкала (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Агент явно указал расхождение между отчётом и логом, назвал стейдж из лога (`check-relevance`) с опорой на конкретную запись (reason=`dependencies_inactive` и/или номер строки), отверг атрибуцию отчёта (`check-conditions`), поставил уровень уверенности. |
-| **4** | Расхождение отмечено и корректный стейдж назван со ссылкой на лог, но без цитаты строки или без уровня уверенности. |
-| **3** | Правильный стейдж назван, но без явного указания на расхождение с отчётом или без опоры на лог. |
-| **2** | Агент смешал обе атрибуции, не выбрал одну, либо отметил «неясно» без попытки свериться с логом. |
-| **1** | Агент воспроизвёл атрибуцию отчёта (`check-conditions`) как факт, не упомянув лог и не обнаружив расхождения. |

package/src/skills/analyze-report/tests/rubrics/result-block-format.md

@@ -1,22 +0,0 @@
-# Rubric: Обязательный `---RESULT---` блок со статусом `completed` или `has_gaps`
-
-## Критерий
-
-**Завершил ли агент анализ блоком `---RESULT---` со статусом строго из допустимого множества (`completed` | `has_gaps`), в формате, пригодном для парсинга пайплайном?**
-
-Агент должен:
-1. Закрыть ответ блоком, обрамлённым маркерами `---RESULT---` сверху и снизу.
-2. Указать `status:` ровно одним из двух значений: `completed` или `has_gaps`. Любое другое значение (`ok`, `done`, `default`, `success` и т.п.) — ошибка.
-3. При `has_gaps` — дать поле `gaps:` с кратким описанием пробелов (1–2 предложения, actionable).
-4. Сопоставить статус с содержимым анализа: `completed` только когда нет открытых тикетов и CRITICAL/HIGH-проблем; во всех остальных случаях — `has_gaps`.
-5. Не дублировать блок `---RESULT---` и не помещать его в середину ответа — только в конце.
-
-## Шкала (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Блок `---RESULT---` корректно оформлен в самом конце, статус из допустимого множества, статус соответствует содержанию анализа, при `has_gaps` присутствует информативное поле `gaps`. |
-| **4** | Блок есть и статус валиден, но поле `gaps` слабое/отсутствует при `has_gaps`, либо есть незначительная погрешность оформления (лишние пробелы, формат поля). |
-| **3** | Блок есть, статус валиден, но статус не соответствует описанию анализа (противоречие между текстом и RESULT). |
-| **2** | Блок есть, но статус недопустимый (`ok`, `done`, `default`, `success`) или отсутствует поле `status`. |
-| **1** | Блок `---RESULT---` отсутствует полностью или повреждён (один маркер, не в конце, сломанный YAML). |

package/src/skills/analyze-report/workflows/progress.md

@@ -1,158 +0,0 @@
-# Воркфлоу: PROGRESS — Оценка прогресса по плану
-
-Оценка текущего состояния активного плана: что выполнено, что в работе, что отстаёт, какие риски.
-
-## Алгоритм выполнения
-
-### 1. Собери входные данные
-
-Из тикета извлеки:
-- Какой план анализировать (путь к файлу плана)
-- Какой отчёт является источником данных (путь к файлу отчёта)
-- Контекст: зачем нужен анализ, какие решения будут приниматься
-
-Прочитай:
-- Файл плана из `.workflow/plans/`
-- Файл отчёта из `.workflow/reports/`
-- Тикеты из `.workflow/tickets/done/` (завершённые)
-- Тикеты из `.workflow/tickets/in-progress/` (текущие)
-- Тикеты из `.workflow/tickets/ready/` (ожидающие)
-- Тикеты из `.workflow/tickets/blocked/` (заблокированные)
-
-### 2. Рассчитай метрики прогресса
-
-> Загрузи `algorithms/progress-assessment.md`
-> Загрузи `knowledge/analysis-frameworks.md`
-
-#### 2a. Автоматический расчёт (основной путь)
-
-Запусти скрипт расчёта метрик:
-
-```bash
-node .workflow/src/skills/analyze-report/scripts/calc-plan-metrics.js <PLAN-NNN>
-```
-
-Где `<PLAN-NNN>` — ID плана из тикета (например, `PLAN-002`).
-
-Прочитай JSON из блока `---RESULT---`. Скрипт возвращает:
-- `distribution` — распределение тикетов по статусам (done, in-progress, ready, blocked, backlog)
-- `completion_pct` — процент выполнения
-- `avg_time_to_done` — среднее время выполнения тикета (дни)
-- `blocked_rate` — процент заблокированных тикетов
-- `rework_count` — количество тикетов с повторной работой
-- `total_tickets` — общее количество тикетов плана
-
-Используй эти метрики как основу для дальнейшего анализа.
-
-#### 2b. Ручной расчёт (fallback)
-
-Если скрипт недоступен или вернул ошибку, собери данные вручную:
-- Общее количество задач в плане
-- Количество завершённых / в работе / ожидающих / заблокированных
-- Процент выполнения (по количеству и по сложности)
-
-### 3. Проанализируй качество выполнения
-
-Для каждого завершённого тикета:
-- Выполнены ли все критерии DoD?
-- Были ли ревью-замечания?
-- Были ли повторные выполнения?
-
-> Загрузи `knowledge/report-structure.md`
-
-### 4. Выяви проблемы и риски
-
-| Категория | Что искать |
-|-----------|-----------|
-| **Блокеры** | Заблокированные тикеты, зависимости |
-| **Отклонения** | Задачи с замечаниями на ревью |
-| **Пробелы** | Задачи плана, не покрытые тикетами |
-| **Паттерны** | Повторяющиеся проблемы в тикетах |
-
-### 4.1. Верифицируй каждую проблему по логу пайплайна (ОБЯЗАТЕЛЬНО)
-
-> **⛔ Без этого шага findings не имеют доказательной базы и относятся к категории «угаданных».** Принцип evidence-based нарушается, отчёт превращается в гадание.
-
-**Зачем:** отчёт-источник (REPORT-NNN) уже содержит проблемы, но **возможно, с неверной атрибуцией** (см. антипаттерн «копирование root cause» в `create-report/workflows/standard.md`). Твоя задача как аналитика — **независимо верифицировать** каждую проблему по логу, а не доверять формулировкам отчёта на слово.
-
-**Алгоритм:**
-
-1. **Найди лог сессии**, в которой возникла проблема. В `.workflow/logs/` найди файлы `pipeline_*.log` за период анализируемого отчёта (по mtime или по диапазону дат из отчёта).
-
-2. **Для каждой проблемы из шага 4:**
-   1. Найди в логе строки с упоминанием проблемного тикета (Grep по `ticket_id`).
-   2. Извлеки имя стейджа, который принял решение, и его обоснование (поле `reason` в `---RESULT---`).
-   3. Сравни найденную атрибуцию с тем, что написано в отчёте.
-
-3. **Если атрибуция в отчёте совпадает с логом** → finding имеет уверенность **HIGH**, в отчёт цитата лога: `pipeline_*.log:NNNN`.
-
-4. **Если атрибуция в отчёте НЕ совпадает с логом** (отчёт обвиняет компонент X, а лог показывает компонент Y) → это **отдельный finding уровня CRITICAL**:
-   - Запиши в раздел проблем: «Отчёт REPORT-NNN неверно атрибутировал root cause проблемы Z: указан компонент X, фактически решение принял компонент Y (лог: pipeline_*.log:NNNN)».
-   - Это сигнал о дефекте в скиле, генерирующем отчёты — рекомендуй создание тикета на правку соответствующего скила.
-
-5. **Если в логе нет данных по тикету** (например, инцидент произошёл до начала логирования) → finding получает уверенность **LOW**, в отчёте честно указать: «evidence отсутствует, требуется ручное расследование».
-
-> **⛔ Запрет угадывания.** Если ты не нашёл в логе строку с решением — **никогда** не пиши «вероятно, это компонент X». Вместо этого напиши `evidence not found, confidence LOW`. Угаданные обвинения уводят коуча в неправильную сторону и заставляют править не те компоненты.
-
-### 5. Сформулируй рекомендации
-
-Для каждой проблемы/риска:
-- **Что:** конкретное действие
-- **Почему:** причина (на основе данных) + **цитата строки лога** как evidence (для findings с уверенностью HIGH)
-- **Приоритет:** CRITICAL / HIGH / MEDIUM / LOW
-- **Уверенность:** HIGH (есть evidence из лога) / MEDIUM (есть данные из тикетов, но нет лога) / LOW (только косвенные признаки)
-
-### 5.1. Верификация gaps перед передачей в пайплайн (ОБЯЗАТЕЛЬНО)
-
-> **⛔ Без этого шага decompose-gaps получит дублирующие или уже решённые gaps.**
-
-Перед формированием `---RESULT---` с `status: has_gaps`, для каждого артефакта, упомянутого в рекомендациях как «нужно создать» (тикет, файл, баг-репорт):
-
-1. **Glob** по `.workflow/tickets/` на ID артефакта (например, `**/XXX-NNN.md`).
-2. Если файл **уже существует** — это не gap. Исключи из описания gaps. В секции рекомендаций отметь: «Тикет {ID} уже существует на диске, создание не требуется».
-3. Если файл **не существует** — это валидный gap, включи в описание.
-
-**Зачем:** предшествующие стадии (execute-task) могут создавать тикеты в нарушение своих ограничений. Передача «создать тикет X» в gaps при уже существующем X приводит к дублированию или перезаписи в decompose-gaps.
-
-### 6. Определи статус плана
-
-| Прогресс | Качество | Блокеры | Статус |
-|----------|----------|---------|--------|
-| ≥80% | Высокое | Нет | ✅ На финишной прямой |
-| 50-80% | Нормальное | Мало | 🟡 В рамках ожиданий |
-| 30-50% | Нормальное | Есть | 🟠 Требует внимания |
-| <30% | Любое | Много | 🔴 Критическое отставание |
-
-### 6.5. Обновить статус плана при завершении
-
-**Критерий завершённости** — план считается `completed` только когда выполнены **оба** условия одновременно:
-1. 100% тикетов плана находятся в директории `done/`
-2. Анализ не выявил пробелов (`has_gaps: false`)
-
-**Если оба условия выполнены:**
-
-Прочитай frontmatter плана. Если `status` уже `completed` или `archived` — пропусти (идемпотентность).
-
-Иначе — обновить frontmatter плана: установить `status: completed`, `completed_at` на текущую дату (ISO 8601), `updated_at` на текущую дату.
-
-**Если хотя бы одно условие не выполнено:**
-
-НЕ обновлять статус, даже если прогресс ≥80%.
-
-> ⚠️ Важно: шаг 6 оценивает визуальный статус прогресса (≥80% → "на финишной прямой") — это **не то же самое**, что завершённость плана. Обновление `status: completed` привязано **исключительно** к строгому критерию (100% done + has_gaps: false), а не к визуальной оценке.
-
-### 7. Сформируй отчёт
-
-> Используй `templates/analysis-report.md`
-
-### 8. Валидация
-
-- [ ] Все метрики рассчитаны на основе реальных данных
-- [ ] Каждая проблема подкреплена конкретным примером
-- [ ] **Каждый finding с уверенностью HIGH имеет цитату из лога** (`pipeline_*.log:NNNN`)
-- [ ] **Каждый finding без evidence помечен как LOW**, без угадывания виновника
-- [ ] **Расхождения с атрибуцией в отчёте-источнике вынесены в отдельный finding CRITICAL**
-- [ ] Рекомендации actionable (содержат конкретное действие)
-- [ ] Executive summary отражает ключевые находки
-- [ ] Статус плана соответствует метрикам
-- [ ] **STOP-GATE:** Если отчёт содержит `plan_status: completed`, прочитай frontmatter плана. Если `status` плана не `completed` — STOP: вернись к шагу 6.5, выполни обновление и повтори проверку.