workflow-ai 1.1.0 → 1.2.1

package/src/skills/coach/knowledge/common-antipatterns.md

@@ -1,76 +0,0 @@
-# Типичные антипаттерны в скилах
-
-Чеклист проблем при аудите и ревью скилов.
-
-## Структурные (S)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| S1 | Осиротевшие файлы (не в SKILL.md) | Добавить в таблицу загрузки или удалить |
-| S2 | Битые ссылки | Создать файл или исправить ссылку |
-| S3 | Пустые директории | Заполнить или убрать |
-| S4 | Монолитный SKILL.md | Декомпозировать в воркфлоу |
-| S5 | Нет README | Создать по эталону |
-
-## Содержание (C)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| C1 | Абстрактная роль | Описать роль, границы, зону ответственности |
-| C2 | Размытые принципы | Что делать, когда, как измерить |
-| C3 | Воркфлоу-декларация без шагов | Конкретные шаги, чеклисты, пороги |
-| C4 | Knowledge без структуры | Таблицы, заголовки, маркеры расширения |
-| C5 | Algorithm без формул | Числовые критерии, формулы, пороги |
-| C6 | Template без подсказок | Примеры и placeholder в каждое поле |
-
-## Поведение (B)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| B1 | Выход за границы | Уточнить «Ты НЕ делаешь» |
-| B2 | Дублирование знаний | Вынести в один модуль, ссылаться |
-| B3 | Нет маршрута для типа | Добавить воркфлоу/маршрутизацию |
-| B4 | Игнорирование knowledge | Добавить ссылки в шагах воркфлоу |
-| B5 | Нет fallback | Правило «Если тип не определяется — ...» |
-
-## Изоляция (I)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| I1 | Хардкод имён ролей/скилов | → «любой скил проекта», generic ID (XXX-NNN) |
-| I2 | Примеры с конкретными ID ролей | → XXX-001, example-skill |
-| I3 | Таблица ролей во Взаимодействии | → «Любой скил может создать тикет {PREFIX}-*» |
-| I4 | Ссылки на инструменты других скилов | → «описаны в SKILL.md исполнителя» |
-| I5 | Границы компетенции с именами | → «соответствующий скил проекта» |
-
-**Проверка:** `grep -rE "GML|PMA|CSM|CRO|PMK" src/skills/` → 0 результатов.
-
-## Изоляция от конфигурации (IC)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| IC1 | Хардкод project-wide типов задач | Скил определяет подход по содержимому тикета |
-| IC2 | Knowledge-дубликат конфига | Удалить, источник правды — конфиг |
-| IC3 | Воркфлоу под каждый project-wide тип | Организовать по этапам работы или собственным типам |
-
-## Scope management (SC)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| SC1 | Scope creep через DoD | Запретить скилу исполнения создавать тикеты |
-| SC2 | Декомпозиция без scope-guard | Проверка «Включено/Исключено из scope» |
-| SC3 | Тикеты-сироты без parent_plan | Обязательно заполнять parent_plan |
-| SC4 | Каскадная декомпозиция | Только скилы декомпозиции создают тикеты |
-| SC5 | Горизонт за пределами плана | Future-задачи → рекомендации, не тикеты |
-| SC6 | Каскад исполнение→план→декомпозиция | 3 уровня защиты в скиле исполнения |
-| SC7 | Автодекомпозиция без human-approval | Только планы со `status: approved` |
-
-## Масштабирование (M)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| M1 | Нет маркеров расширения | `<!-- РАСШИРЕНИЕ: ... -->` в конец |
-| M2 | Жёсткая привязка | Параметризовать или вынести в конфиг |
-| M3 | Нет инструкций по расширению | Секция «Как расширять» в README |
-
-<!-- РАСШИРЕНИЕ: добавляй новые антипаттерны ниже -->

package/src/skills/coach/knowledge/prompt-engineering.md

@@ -1,45 +0,0 @@
-# Prompt Engineering для скилов
-
-Принципы написания эффективных инструкций в SKILL.md и воркфлоу.
-
-## Роль
-
-| Принцип | Плохо | Хорошо |
-|---------|-------|--------|
-| Конкретность | «Ты — полезный помощник» | «Ты — Growth Marketing Lead в команде из 5 человек» |
-| Границы | Только «Ты делаешь» | «Ты делаешь» + «Ты НЕ делаешь» |
-| Контекст | Без контекста команды | С RACI-матрицей и связками ролей |
-
-## Воркфлоу
-
-1. **Глагол в начале** — «Определи», «Собери», «Проверь», не «Нужно определить»
-2. **Ссылки на знания** — каждый шаг с данными ссылается на источник (`→ knowledge/module.md`)
-3. **Чеклисты** — завершай воркфлоу проверочным списком
-4. **Условия** — развилки описывай оба пути явно
-5. **Нет «подумай»** — заменяй на конкретный метод/алгоритм
-
-## Knowledge
-
-1. **Факты, не мнения** — «CAC < LTV/3» вместо «CAC должен быть маленьким»
-2. **Источники** — откуда данные
-3. **Пороги числами** — «> 3x» вместо «значительно выше»
-4. **Структура** — таблицы, категории, маркер `<!-- РАСШИРЕНИЕ -->`
-
-## Algorithms
-
-1. **Детерминированность** — одинаковый вход → одинаковый выход
-2. **Числовые пороги** — «если score > 7» вместо «если оценка высокая»
-3. **Граничные случаи** — что делать если данных нет
-4. **Структура:** Вход → Алгоритм → Выход → Пример
-
-## Антипаттерны
-
-| Антипаттерн | Решение |
-|-------------|---------|
-| «Будь креативным» | Укажи конкретный метод |
-| «Учти все факторы» | Перечисли факторы и веса |
-| «При необходимости» | Укажи конкретное условие |
-| Длинные абзацы | Таблицы, списки, чеклисты |
-| Дублирование | Один источник правды + ссылки |
-
-<!-- РАСШИРЕНИЕ: добавляй новые принципы prompt engineering ниже -->

package/src/skills/coach/knowledge/shared-knowledge-guide.md

@@ -1,44 +0,0 @@
-# Shared Knowledge — межскиловые знания
-
-Когда knowledge-модуль нужен 2+ скилам — он выносится в `skills/shared/`.
-
-## Структура
-
-```
-skills/
-├── shared/               # Проектно-специфичные знания, общие для нескольких скилов
-│   ├── README.md         # Индекс: таблица модулей с описанием и списком потребителей
-│   └── module.md
-├── skill-a/
-└── skill-b/
-```
-
-## README.md — обязательный индекс
-
-```markdown
-# Shared Knowledge Modules
-
-| Модуль | Описание | Используется в |
-|--------|----------|----------------|
-| `module-name.md` | Что содержит | skill-a, skill-b |
-```
-
-## Правила
-
-| Правило | Описание |
-|---------|----------|
-| **Критерий выноса** | Контент используется 2+ скилами с пересечением 70%+ |
-| **Скилы — универсальные, shared — проектный** | Скилы переносятся между проектами as-is. Shared содержит проектно-специфичные знания |
-| **Ссылка из скила — через glob** | В таблице загрузки: `../shared/*` → «проверь индекс, загрузи релевантные». Не хардкодить имена модулей |
-| **Domain-контекст — в скиле** | Специфичная интерпретация shared-знаний остаётся в knowledge/workflows скила |
-
-## Антипаттерны
-
-| Антипаттерн | Как правильно |
-|-------------|---------------|
-| Дублировать данные в knowledge/ нескольких скилов | Вынести в shared/ |
-| Хардкодить `../shared/module.md` в SKILL.md | `../shared/*` → проверить README |
-| Класть в shared/ knowledge одного скила | Оставить в knowledge/ скила |
-| Вкладывать shared/ в конкретный скил | shared/ — на одном уровне со скилами |
-
-<!-- РАСШИРЕНИЕ: добавляй правила shared knowledge ниже -->

package/src/skills/coach/knowledge/skill-anatomy.md

@@ -1,49 +0,0 @@
-# Эталонная анатомия скила
-
-Справочник по структуре и содержанию идеального скила workflow-ai.
-
-## Обязательная структура директорий
-
-```
-skill-name/
-├── SKILL.md              # Ядро: роль, маршрутизация, принципы
-├── README.md             # Документация для людей
-├── workflows/            # Пошаговые алгоритмы по типам тикетов
-├── knowledge/            # Экспертные знания домена
-├── algorithms/           # Формализованные методы принятия решений
-└── templates/            # Шаблоны вывода
-```
-
-## SKILL.md — обязательные секции
-
-| Секция | Критерий качества |
-|--------|-------------------|
-| **Frontmatter** (name, description, ticket_prefix) | description 2-3 предложения, prefix уникален |
-| **Роль** (делает / не делает) | Конкретно, без абстракций |
-| **Маршрутизация** (тип → триггеры → воркфлоу) | Каждый тип → свой файл. **Только собственные типы** |
-| **Загрузка знаний/алгоритмов/шаблонов** | Все файлы перечислены с условиями загрузки |
-| **Принципы** (3-7) | Actionable, не декларативные |
-| **Формат вывода** | Специфичен для домена |
-| **Границы компетенции** | Перечислены смежные зоны с указанием куда направить |
-
-## ⛔ Принцип изоляции скилов
-
-Скилы НЕ знают о других скилах по имени. Используй: «любой скил проекта», generic ID (XXX-NNN).
-
-**Изоляция от project-wide типов:** не хардкодить типы из `config.yaml:task_types`. Маршрутизация — по собственным типам скила, не по project-wide.
-
-## Требования к качеству компонентов
-
-| Компонент | Ключевые требования |
-|-----------|--------------------|
-| **Workflows** | Пронумерованные шаги, ссылки на knowledge/algorithms, чеклисты завершения |
-| **Knowledge** | Таблицы/списки, маркер `<!-- РАСШИРЕНИЕ -->`, формулы явно, источники |
-| **Algorithms** | Вход → алгоритм → выход, пороги числами, пример применения |
-| **Templates** | Обязательные/опциональные поля, placeholder-подсказки, markdown |
-| **README.md** | Название, структура, flow, как расширять |
-
-## Shared Knowledge
-
-При создании/аудите скила → загрузи `knowledge/shared-knowledge-guide.md` для правил межскиловых знаний.
-
-<!-- РАСШИРЕНИЕ: добавляй новые требования к анатомии скила ниже -->

package/src/skills/coach/knowledge/test-authorship.md

@@ -1,141 +0,0 @@
-# Авторство тест-кейсов регрессионных тестов скилов
-
-Руководство для коуча по написанию тест-кейсов при работе с регрессионными тестами скилов.
-
----
-
-## 1. Дерево выбора слоя (L0 / L1 / L2)
-
-Выбери слой по первому подходящему условию:
-
-| Слой | Название | Когда использовать |
-|------|----------|-------------------|
-| **L0** | static | **Всегда** — если нужно проверить, что агент записал конкретный инвариант в файл (наличие раздела, запрета, поля). Не зависит от модели. |
-| **L1** | deterministic | Когда у output есть наблюдаемая сигнатура: структура YAML/JSON, наличие обязательных ключей, формат ID. Подходит, если ответ детерминирован при заданном входе. |
-| **L2** | rubric | Когда нужно проверить **принцип рассуждения** агента: правильно ли выбрана root cause, корректно ли применён принцип. Оценивается поведение, а не текст. |
-
-Правило: если сомневаешься между L0 и L1 — выбирай L0. L2 только тогда, когда L0/L1 физически не применимы.
-
----
-
-## 2. Правила написания static-anchor
-
-**Семантический инвариант, не дословный текст:**
-
-- Anchor должен выражать *правило*, нарушение которого тест должен поймать.
-- Anchor **отвергает** любое поведение, нарушающее правило, а не просто проверяет «строка существует в файле».
-- Один anchor — одно правило. Несколько правил → несколько anchor'ов.
-
-**Пример плохого anchor:** `"git commit"` — существует в любом упоминании темы.
-
-**Пример хорошего anchor:** `"коуч не выполняет git commit ни при каких условиях"` — семантически проверяет запрет, а не присутствие слова.
-
----
-
-## 3. Минимизация фикстуры
-
-- Фикстура — реальный артефакт ±20 строк вокруг инцидента.
-- **Не включай** в фикстуру весь лог или полный тикет.
-- Критерий минимума: убери строку → тест перестаёт проверять нужное поведение? Если нет — строка лишняя.
-- Для log-фикстур: вырезай только те шаги, где произошёл инцидент + 5 строк контекста до и после.
-
----
-
-## 4. Формулировка rubric-критерия
-
-Rubric проверяет **процесс рассуждения**, а не конкретный текст ответа:
-
-- Формулируй как: «Агент должен [определить / выбрать / проверить] [что именно] [по какому признаку]».
-- Не указывай конкретные слова, которые агент должен произнести — указывай логический шаг.
-- Rubric должен оставаться валидным при переформулировке инструкций скила.
-
-**Пример плохого rubric:** «Ответ содержит слово "root cause"».
-
-**Пример хорошего rubric:** «Агент идентифицировал физический скил-источник артефакта, а не предметный владелец».
-
----
-
-## 5. Выбор `target_agents[]` на уровне скила
-
-Заполняется автором-коучем вручную при первой настройке, сверяясь с `pipeline.yaml` проекта.
-
-Перечислить как минимум все модели, на которых скил реально гоняется в пайплайне:
-- основная модель скила,
-- fallback-модель (если задана),
-- модели из секций `agent_by_type` и `agent_by_attempt`.
-
-**Дополнительные модели для сравнения разрешены.** `target_agents[]` может включать модели сверх pipeline-набора — они выступают как «контрольная группа» для выявления регрессий формулировок скила на более широкой выборке. Такие модели помечаются комментарием (см. пример в `coach/tests/index.yaml`). Наличие «лишних» моделей — не ошибка и не повод сокращать список.
-
-Заполняется один раз в `tests/index.yaml` и наследуется всеми тест-кейсами скила. Не дублировать в каждом кейсе отдельно.
-
-**⛔ Сокращать `target_agents[]` (на уровне `index.yaml` или через per-case override) коуч не имеет права без явного согласия стейкхолдера.** Это относится к любому удалению модели из списка, включая случай «модель не используется в pipeline.yaml». Обоснование: `target_agents[]` — это заявленная сфера регрессии скила, а не техническая конфигурация; сокращение сужает покрытие тестов. См. подробный запрет ниже в секции «Override на уровне кейса».
-
-**Сверка с pipeline.yaml:**
-
-Runner автоматически проверяет каждый agent-id из `target_agents[]` против списка `agents` в `pipeline.yaml`. Если агент не найден — fail-fast с сообщением:
-
-```
-Agent 'invalid-agent-id' from target_agents[] not found in pipeline.yaml → agents[]
-```
-
-Порядок резолва `pipeline.yaml`:
-1. Приоритет: `<project_root>/.workflow/config/pipeline.yaml` (через `find-root.mjs`)
-2. Fallback: `<package_root>/configs/pipeline.yaml`
-
-Путь к используемому файлу логируется при старте runner'а.
-
-**Override на уровне кейса:**
-
-Точечный override допустим — если конкретный тест-кейс требует другую модель, укажи `execution.target_agents[]` в файле кейса. Это переопределит значение из `index.yaml` для данного кейса.
-
-**⛔ Override target_agents — это решение стейкхолдера, не коуча.** Убирать модель из списка или сужать его — **изменение сферы тестирования**, не техническая правка. Коуч **не имеет права** проактивно применять per-case override target_agents при провале модели на тесте, даже если:
-- модель выдаёт нестабильные/обрезанные ответы;
-- есть прецедент в бэклоге, где похожий override уже применялся;
-- формально «модель физически не может пройти тест».
-
-Все эти случаи — повод **явно согласовать** с стейкхолдером в отдельном сообщении, показав: (а) диагностику, что именно модель не может сделать, (б) три варианта действий (оставить как есть с honest baseline / исследовать глубже / исключить), (в) дождаться выбора. Применение override без явного согласия — перекладывание решения стейкхолдера на коуча и нарушение **границ компетенции** (см. SKILL.md, раздел «Границы компетенции»).
-
-**Антипаттерн:** «в прецеденте X модель была исключена, применяю тот же паттерн молча». Прецедент — это не карт-бланш. Проверь: стейкхолдер явно запросил исключение в прецеденте или коуч предложил и получил согласие? Если второе — всегда повторяй согласование для нового случая, даже если кажется аналогичным.
-
-**CLI-флаги для запуска:**
-
-- `--agent <id>` — прогон только на конкретной модели из `target_agents[]`
-- `--primary-only` — только первая модель из `target_agents[]` (без fallback)
-
----
-
-## 6. Сравнение прогонов через git
-
-Для отслеживания регрессий между прогонами используй стандартные git-инструменты:
-
-| Задача | Команда |
-|--------|---------|
-| Посмотреть изменения в мета-файле | `git diff current/meta.json` |
-| История прогонов | `git log current/meta.json` |
-| Кто изменил конкретную строку | `git blame current/meta.json` |
-
-Никакой специальной инфраструктуры не требуется — `current/meta.json` версионируется как обычный файл.
-
----
-
-## 7. Кто делает commit
-
-**⛔ Коуч не выполняет `git add`, `git commit`, `git push`, `git checkout`, `git reset` ни при каких условиях.**
-
-Коммит `current/` делает **исключительно пользователь**.
-
-Роль коуча после прогона тестов:
-1. Сообщить verdict runner'а (pass / fail / error).
-2. Перечислить затронутые файлы.
-3. Остановиться — дальнейшие git-операции выполняет пользователь.
-
----
-
-## 8. Антипаттерны авторства
-
-| Антипаттерн | Почему плохо | Как правильно |
-|-------------|-------------|---------------|
-| Тестировать дословную формулировку инструкции | Хрупко: переформулировка инструкции ломает тест, не меняя поведение | Тестировать семантический инвариант правила |
-| Over-specifying expected output | Привязка к конкретным словам делает тест зависимым от стиля модели | Проверять принцип, а не точный текст |
-| Фикстура = полный лог/тикет | Тест медленный, нечитаемый, хрупкий к несвязанным изменениям | Минимальная фикстура ±20 строк вокруг инцидента |
-| L2 вместо L0 для проверки файла | L2 дороже и недетерминирован; если можно проверить файл — используй L0 | Выбирай наименьший подходящий слой |

package/src/skills/coach/templates/audit-report.md

@@ -1,39 +0,0 @@
-# Шаблон: Отчёт аудита скила
-
-```markdown
-# Аудит скила: {skill-name}
-
-**Дата:** {YYYY-MM-DD}
-**Тикет:** {COACH-NNN}
-
-## Общая оценка
-
-| Категория | Балл | Макс |
-|-----------|------|------|
-| Структура | {N} | 20 |
-| Полнота SKILL.md | {N} | 20 |
-| Качество воркфлоу | {N} | 20 |
-| Качество знаний и алгоритмов | {N} | 20 |
-| Связность и консистентность | {N} | 20 |
-| **Итого** | **{N}** | **100** |
-
-**Оценка:** {EXCELLENT / GOOD / NEEDS_WORK / POOR}
-
-## Найденные проблемы
-
-| # | Приоритет | Файл | Проблема | Рекомендация |
-|---|-----------|------|----------|-------------|
-| 1 | {CRITICAL/HIGH/MEDIUM/LOW} | {path} | {описание} | {что сделать} |
-
-## Антипаттерны / Gap-анализ
-
-| # | Тип | Описание | Где / Приоритет |
-|---|-----|----------|----------------|
-| 1 | {Антипаттерн/Gap} | {описание} | {файл:секция / приоритет} |
-
-## Сильные стороны (топ-3) / План улучшений
-
-| # | Сильная сторона | Улучшение | Приоритет | Трудозатраты |
-|---|----------------|-----------|-----------|-------------|
-| 1 | {что хорошо} | {что сделать} | {приоритет} | {быстро/средне/долго} |
-```

package/src/skills/coach/templates/coach-backlog-init.yaml

@@ -1,14 +0,0 @@
-version: 2
-last_updated: ""
-
-# Защита от повторного анализа тикетов/логов, не приведших к правке скила.
-# (Те, что привели к правке, имеют тест-кейс в src/skills/*/tests/cases/ — туда и смотрим.)
-analyzed_tickets: []
-
-# Snapshot scores скилов на момент аудита (trajectory во времени).
-audited_skills: []
-
-# История правок скилов — в git, не в этом файле:
-# git log -- src/skills/<name>/                    # все правки скила
-# git log -- src/skills/<name>/tests/cases/        # тест-кейсы
-# git log --follow -- src/skills/<name>/SKILL.md   # история файла

package/src/skills/coach/templates/coach-backlog-init.yaml.legacy

@@ -1,10 +0,0 @@
-# Шаблон инициализации бэклога коуча
-# Скопировать в .workflow/coach-backlog.yaml при первом запуске
-version: 1
-last_updated: ""
-
-analyzed_tickets: []
-
-applied_changes: []
-
-audited_skills: []

package/src/skills/coach/templates/improvement-plan.md

@@ -1,42 +0,0 @@
-# Шаблон: План улучшений скила
-
-```markdown
-# План улучшений: {skill-name}
-
-**Дата:** {YYYY-MM-DD}
-**Тикет:** {COACH-NNN}
-**Основание:** {ссылка на аудит / анализ / запрос}
-
-## Цель
-
-{Что хотим улучшить и почему — 1-2 предложения.}
-
-## Изменения
-
-| # | Название | Приоритет | Файлы | Проблема → Решение | Ожидаемый эффект |
-|---|----------|-----------|-------|--------------------|-----------------|
-| 1 | {название} | {CRITICAL/HIGH/MEDIUM/LOW} | {файлы} | {проблема → решение} | {эффект} |
-
-## Порядок выполнения
-
-{Последовательность: что делать первым, какие зависимости.}
-
-1. {Шаг 1} — зависит от: нет
-2. {Шаг 2} — зависит от: шаг 1
-...
-
-## Критерии успеха
-
-- [ ] {Критерий 1 — как проверить что улучшение работает}
-- [ ] {Критерий 2}
-- [ ] Все ссылки в SKILL.md валидны
-- [ ] Scoring скила вырос на {N} баллов
-
-## Источники
-
-{Если использовались внешние знания — ссылки с описанием.}
-
-| Источник | Что взято | Дата |
-|----------|----------|------|
-| {URL/название} | {что именно} | {YYYY-MM-DD} |
-```

package/src/skills/coach/templates/new-skill.md

@@ -1,95 +0,0 @@
-# Шаблон: Структура нового скила
-
-## SKILL.md
-
-```markdown
----
-name: {skill-name}
-description: >
-  {2-3 предложения: кто агент, что делает, в каком контексте}
-ticket_prefix: {PREFIX}
----
-
-# {Skill Name} — Agent Skill
-
-## Роль
-
-{Роль, контекст, ограничения}
-
-**Ты делаешь:** {перечисление}
-**Ты НЕ делаешь:** {перечисление → куда направить}
-
-## Маршрутизация тикетов {PREFIX}-*
-
-| Тип | Триггеры | Воркфлоу |
-|-----|----------|----------|
-| **TYPE1** | «ключевые слова» | → `workflows/type1.md` |
-
-## Загрузка знаний
-
-| Модуль | Когда загружать |
-|--------|----------------|
-| `knowledge/module.md` | Условие |
-
-## Загрузка алгоритмов
-
-| Алгоритм | Когда загружать |
-|----------|----------------|
-| `algorithms/algo.md` | Условие |
-
-## Шаблоны вывода
-
-| Шаблон | Когда использовать |
-|--------|-------------------|
-| `templates/template.md` | Условие |
-
-## Принципы
-
-1. **Принцип** — описание.
-{3-7 принципов}
-
-## Формат вывода
-
-- Язык, стиль, конкретность
-
-## Границы компетенции
-
-- **Зона X** → куда направить
-```
-
-## Workflow файл
-
-```markdown
-# Воркфлоу: {TYPE}
-
-## Алгоритм
-### 1. {Действие}
-{Пояснение, ссылки на knowledge/algorithms}
-### N. Валидация
-- [ ] Критерий 1
-```
-
-## Knowledge файл
-
-```markdown
-# {Модуль знаний}
-
-## {Категория}
-| Параметр | Значение | Описание |
-|----------|----------|----------|
-<!-- РАСШИРЕНИЕ: добавляй {что} ниже -->
-```
-
-## Algorithm файл
-
-```markdown
-# Алгоритм: {Название}
-## Вход
-{Входные данные}
-## Алгоритм
-### 1. {Шаг}
-## Выход
-{Результат}
-## Пример
-{Конкретный пример}
-```

package/src/skills/coach/tests/cases/TC-COACH-001/current/claude-sonnet/trial-1.md

@@ -1,58 +0,0 @@
-Тест пройден. Relevant case TC-DECOMPOSE-PLAN-004: **passed**.
-
-**Verdict: `no_baseline_failures`** (режим no-baseline — история отсутствует, это первый прогон). Все 4 статических assertion прошли.
-
----
-
-## Итог анализа пайплайна PLAN-003
-
-### Findings
-
-| # | Приоритет | Проблема | Статус |
-|---|-----------|---------|--------|
-| 1 | CRITICAL | ID-коллизия IMPL-002/IMPL-003: заархивированы из PLAN-002, пересозданы для PLAN-003 | ✅ Fix в пайплайне (`allocate-ticket-ids`) |
-| 2 | CRITICAL | STOP-GATE 9.B нарушен: декомпозитор назначил ID «из головы» при отсутствии `id_ranges_json` | ✅ STOP-GATE уже добавлен в `decompose.md` |
-| 3 | HIGH | `ids_allocated_from` отсутствует в RESULT | ✅ Требование зафиксировано в `decompose.md` |
-| 4 | MEDIUM | STOP-GATE не определял явный формат вывода ошибки — пайплайн не мог отличить infra-ошибку от нормального завершения | **CHG-2026-04-19-001: добавлен `status: infra_error`** |
-
-### Ключевой паттерн коллизии
-
-```
-16:36:02  auto-correction: IMPL-002 (PLAN-002) → archive/
-16:36:02  auto-correction: IMPL-003 (PLAN-002) → archive/
-          [check-plan-decomposition → decompose-plan БЕЗ allocate-ticket-ids]
-16:40:31  decompose-plan создаёт IMPL-002 для PLAN-003 → backlog/
-16:40:31  decompose-plan создаёт IMPL-003 для PLAN-003 → backlog/
-          ↑ tasks_completed в pick-next-task.js находит старый IMPL-002 в archive/
-            и ошибочно считает зависимость QA-001 выполненной
-```
-
-### Правка скила (CHG-2026-04-19-001)
-
-**Файл:** `skills/decompose-plan/workflows/decompose.md`, шаг 9.B пункт 3
-
-**Добавлен явный формат вывода при срабатывании STOP-GATE:**
-```
----RESULT---
-status: infra_error
-error: <описание: что отсутствует или некорректно в id_ranges_json>
----RESULT---
-```
-
-**Тест:** `TC-DECOMPOSE-PLAN-004` — verdict `no_baseline_failures`, relevant case passed.
-
-### Рекомендуемый тикет (вне scope коуча)
-
-Добавить в `pipeline.yaml` обработчик `infra_error` для стадии `decompose-plan`:
-```yaml
-decompose-plan:
-  goto:
-    default: check-atomicity-limit
-    infra_error: check-conditions  # ← добавить
-```
-
-**Затронутые файлы:**
-- `D:/Dev/workflowAi/src/skills/decompose-plan/workflows/decompose.md`
-- `D:/Dev/workflowAi/src/skills/decompose-plan/tests/cases/TC-DECOMPOSE-PLAN-004-stopgate-infra-error-format.yaml` (новый)
-- `D:/Dev/workflowAi/src/skills/decompose-plan/tests/index.yaml`
-- `.workflow/coach-backlog.yaml`