workflow-ai 1.1.0 → 1.2.1

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, выполни обновление и повтори проверку.

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

@@ -1,143 +0,0 @@
-# Воркфлоу: RETROSPECTIVE — Ретроспективный анализ завершённого плана
-
-Полный анализ завершённого плана: что получилось, что нет, какие уроки извлечь, что улучшить в следующем цикле.
-
-## Алгоритм выполнения
-
-### 1. Собери входные данные
-
-> **Pre-condition: Проверка статуса плана**
->
-> До начала сбора данных — прочитай frontmatter плана.
->
-> Если `status` **не** `completed` и не `archived`:
-> 1. Зафиксировать как находку в разделе Lessons Learned отчёта:
->    «Аномалия процесса: план не имел статуса `completed` к моменту запуска ретроспективы — пропущено обновление статуса в progress-анализе (шаг 6.5)»
-> 2. Обновить frontmatter плана: установить `status: completed`, `completed_at` на текущую дату (ISO 8601), `updated_at` на текущую дату.
->
-> Если `status` уже `completed` или `archived` — пропустить (идемпотентность), продолжить шаг 1 в штатном режиме.
->
-> ⚠️ Это страховочный механизм. Основной путь обновления `status: completed` — через шаг 6.5 в `progress.md`. Ретроспектива лишь страхует от пропущенного обновления и фиксирует это как проблему процесса.
-
-Из тикета извлеки:
-- Какой план анализировать
-- Все связанные отчёты
-- Контекст: для чего проводится ретроспектива
-
-Прочитай:
-- Файл плана из `.workflow/plans/`
-- Все отчёты, связанные с планом, из `.workflow/reports/`
-- Все тикеты плана из `.workflow/tickets/done/`
-- Заблокированные тикеты (если остались) из `.workflow/tickets/blocked/`
-
-### 2. Оцени результат vs цели
-
-> Загрузи `knowledge/analysis-frameworks.md`
-
-Для каждой цели плана:
-
-| Цель | Статус | Результат | Отклонение |
-|------|--------|-----------|------------|
-| ... | ✅/⚠️/❌ | Что получилось | Чем отличается от ожиданий |
-
-### 3. Проанализируй эффективность процесса
-
-> Загрузи `algorithms/progress-assessment.md`
-
-#### 3a. Автоматический расчёт (основной путь)
-
-Запусти скрипт расчёта метрик:
-
-```bash
-node .workflow/src/skills/analyze-report/scripts/calc-plan-metrics.js <PLAN-NNN>
-```
-
-Где `<PLAN-NNN>` — ID анализируемого плана.
-
-Прочитай JSON из блока `---RESULT---`. Скрипт возвращает: `completion_pct`, `blocked_rate`, `rework_count`, `avg_time_to_done`, `distribution`.
-
-Используй готовые метрики для:
-- **Throughput**: `completion_pct` + `distribution` (завершено / всего)
-- **Blockers**: `blocked_rate` + `distribution.blocked`
-- **Rework**: `rework_count`
-
-#### 3b. Дополнительные метрики (вручную)
-
-Скрипт не рассчитывает — собери самостоятельно:
-- **Quality**: % тикетов, прошедших ревью с первого раза (проверь историю ревью в тикетах)
-
-#### 3c. Fallback (если скрипт недоступен)
-
-Собери все метрики вручную:
-- **Throughput**: сколько тикетов завершено / сколько было в плане
-- **Quality**: % тикетов, прошедших ревью с первого раза
-- **Blockers**: количество и длительность блокировок
-- **Rework**: количество тикетов, потребовавших повторного выполнения
-
-### 4. Выяви паттерны
-
-**Что работало хорошо (Keep):**
-- Практики, которые привели к успешным результатам
-- Процессы, которые работали гладко
-
-**Что не работало (Stop):**
-- Практики, которые приводили к проблемам
-- Повторяющиеся ошибки
-
-**Что попробовать (Try):**
-- Идеи для улучшения на основе выявленных проблем
-
-### 4.1. Верифицируй паттерны проблем по логам пайплайна (ОБЯЗАТЕЛЬНО)
-
-> **⛔ Без этого шага ретроспектива воспроизводит ошибки атрибуции из отчётов-источников.** Принцип evidence-based нарушается.
-
-**Зачем:** ретроспектива опирается на REPORT-NNN, которые могут содержать **угаданную** атрибуцию root cause (если их сгенерировал старый воркфлоу `create-report` без проверки лога). Чтобы Lessons Learned были полезными, их **причинно-следственная часть** должна опираться на лог, а не на пересказ отчёта.
-
-**Алгоритм:**
-
-1. **Найди логи сессий** в `.workflow/logs/`, относящиеся к периоду плана. Может быть несколько `pipeline_*.log` за разные дни.
-
-2. **Для каждой проблемы в категории "Stop":**
-   1. Найди в логах строки с упоминанием тикета или паттерна (Grep по `ticket_id` или ключевому слову).
-   2. Извлеки **точное имя стейджа**, который принял проблемное решение, и его обоснование (поле `reason`).
-   3. Сравни с тем, что написано в отчёте-источнике.
-
-3. **Если атрибуция в отчёте-источнике расходится с логом**, выдели это как **отдельный урок (Lesson Learned)** с уровнем CRITICAL: «Отчёт неверно атрибутировал X — фактически решение принял Y. Это указывает на дефект в скиле, генерирующем отчёты». Рекомендуй создание тикета на правку.
-
-4. **Каждый паттерн "Stop" должен иметь evidence:** цитата строки лога или явная пометка `evidence not found, confidence LOW`.
-
-> **⛔ Запрет угадывания.** Если evidence нет — пиши уровень уверенности LOW. Не интерпретируй знакомые имена компонентов как «вероятную причину».
-
-### 5. Извлеки уроки (Lessons Learned)
-
-Для каждого урока:
-- **Наблюдение:** что произошло (факт)
-- **Причина:** почему это произошло (анализ) — **для уровня HIGH обязательна цитата строки лога**
-- **Урок:** что из этого следует (вывод)
-- **Действие:** что изменить в следующем цикле (рекомендация)
-- **Уверенность:** HIGH (есть evidence из лога) / MEDIUM (только данные из тикетов) / LOW (косвенные признаки)
-
-### 6. Сформулируй рекомендации для следующего плана
-
-- Что учесть при планировании
-- Какие риски закладывать
-- Какие процессы изменить
-- Приоритеты: CRITICAL / HIGH / MEDIUM / LOW
-
-### 7. Сформируй отчёт
-
-> Используй `templates/analysis-report.md`
-
-> Загрузи `knowledge/report-structure.md`
-
-### 8. Валидация
-
-- [ ] Каждая цель плана покрыта анализом (результат vs ожидания)
-- [ ] Метрики процесса рассчитаны на реальных данных
-- [ ] Паттерны подкреплены конкретными примерами из тикетов
-- [ ] **Каждый паттерн "Stop" имеет evidence из лога** (`pipeline_*.log:NNNN`) или явную пометку LOW
-- [ ] **Расхождения с атрибуцией в отчёте-источнике вынесены в отдельный урок CRITICAL**
-- [ ] Уроки содержат и наблюдение, и причину, и действие
-- [ ] Уроки помечены уровнем уверенности (HIGH/MEDIUM/LOW)
-- [ ] Рекомендации actionable и приоритизированы
-- [ ] Executive summary отражает ключевые выводы

package/src/skills/coach/README.md

@@ -1,43 +0,0 @@
-# Coach — Модульный скилл
-
-Мета-скил для создания, аудита и совершенствования других скилов. Обрабатывает тикеты `COACH-*`.
-
-## Структура
-
-```
-coach/
-├── SKILL.md                          # Ядро: роль, маршрутизация, принципы
-├── workflows/                        # CREATE, AUDIT, ANALYZE, IMPROVE, RESEARCH, REVIEW
-├── knowledge/                        # skill-anatomy, common-antipatterns, prompt-engineering,
-│                                     # backlog-management, shared-knowledge-guide
-├── algorithms/                       # skill-scoring, gap-analysis, improvement-prioritization
-├── templates/                        # new-skill, audit-report, improvement-plan
-└── README.md
-```
-
-## Как это работает
-
-1. Агент получает `COACH-*` тикет → **SKILL.md** определяет тип → подгружает **workflow**
-2. Воркфлоу ссылается на **knowledge** и **algorithms** по необходимости
-3. Результат оформляется по **template**
-
-## Типичные сценарии
-
-| Задача | Воркфлоу |
-|--------|----------|
-| Создать скил для новой роли | `workflows/create.md` |
-| Полный аудит скила | `workflows/audit.md` |
-| Анализ эффективности по тикетам | `workflows/analyze.md` |
-| Точечное улучшение | `workflows/improve.md` |
-| Поиск лучших практик | `workflows/research.md` |
-| Ревью структуры и качества | `workflows/review.md` |
-
-## Как расширять
-
-| Что добавить | Действия |
-|-------------|----------|
-| Новый тип тикета | Создать `workflows/type.md` + строка в маршрутизации SKILL.md |
-| Новые знания | Создать `knowledge/name.md` + строка в таблице загрузки SKILL.md |
-| Новый алгоритм | Создать `algorithms/name.md` + строка в таблице загрузки SKILL.md |
-| Новый шаблон | Создать `templates/name.md` + ссылка в воркфлоу |
-| Расширение модуля | Дописать после маркера `<!-- РАСШИРЕНИЕ -->` |