workflow-ai 1.0.63 → 1.0.64

package/src/skills/decompose-gaps/tests/cases/TC-DECOMPOSE-GAPS-002-glob-before-write.yaml

@@ -0,0 +1,36 @@
+id: TC-DECOMPOSE-GAPS-002
+title: "Декомпозитор проверяет Glob существование тикета перед записью"
+origin:
+  chg: [CHG-050]
+  incidents:
+    - "PulseProxy: CHG-050 — перезапись существующих тикетов другими стадиями"
+  principle: "Glob-check before write"
+  backlog_sources:
+    - "d:/Dev/PulseProxy/.workflow/coach-backlog.yaml"
+tags: [glob-check, overwrite-prevention]
+severity: medium
+
+scenario:
+  system_prompt_file: "../../SKILL.md"
+  extra_instructions: |
+    Создай тикет FIX-010 по gap'у. На диске уже существует tickets/ready/FIX-010.md.
+
+assertions:
+  deterministic:
+    - kind: output_does_not_contain
+      values: ["перезапис", "overwrite"]
+      reason: "Существующий тикет не должен быть перезаписан."
+    - kind: output_contains_all
+      values: ["уже существует"]
+      reason: "Должно быть обнаружено существование тикета."
+
+  rubric:
+    - kind: llm_judge
+      rubric_file: "../rubrics/glob-before-write.md"
+      criterion: "Проверил ли агент существование тикета до записи и отказался ли от перезаписи?"
+      pass_threshold: 4
+      trials: 3
+      aggregate: majority
+
+execution:
+  timeout_s: 2400

package/src/skills/decompose-gaps/tests/index.yaml

@@ -0,0 +1,25 @@
+version: 1
+skill: decompose-gaps
+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-DECOMPOSE-GAPS-001
+    file: cases/TC-DECOMPOSE-GAPS-001-scope-exclusion.yaml
+    origin_chg: [CHG-049]
+    tags: [scope-check, exclusion]
+    severity: medium
+  - id: TC-DECOMPOSE-GAPS-002
+    file: cases/TC-DECOMPOSE-GAPS-002-glob-before-write.yaml
+    origin_chg: [CHG-050]
+    tags: [glob-check, overwrite-prevention]
+    severity: medium

package/src/skills/decompose-gaps/tests/rubrics/glob-before-write.md

@@ -0,0 +1,21 @@
+# Rubric: Агент проверил существование тикета до записи
+
+## Критерий
+
+**Проверил ли агент существование тикета с целевым ID в рабочих директориях до записи и отказался ли перезаписывать, если тикет уже существует?**
+
+Агент должен:
+1. До записи нового тикета выполнить проверку существования файла по ID (Glob / Read / эквивалентный шаг).
+2. Обнаружить, что тикет с этим ID уже существует в одной из рабочих директорий.
+3. Отказаться от записи/перезаписи существующего файла.
+4. Явно сообщить факт существования и предложить корректное действие: получить новый ID или остановиться с ошибкой.
+
+## Шкала (1–5)
+
+| Балл | Описание |
+|------|----------|
+| **5** | Проверка существования выполнена явно, перезапись не произведена, предложено корректное действие. |
+| **4** | Перезапись не произведена, проверка выполнена, но без явного объяснения следующего шага. |
+| **3** | Проверка упомянута, но действие неоднозначное (не ясно, записал или нет). |
+| **2** | Запись произведена поверх существующего тикета с оговоркой. |
+| **1** | Запись произведена без проверки существования. |

package/src/skills/decompose-gaps/tests/rubrics/scope-exclusion.md

@@ -0,0 +1,21 @@
+# Rubric: Агент применил scope-проверку и отклонил gap из раздела «Исключено»
+
+## Критерий
+
+**Обнаружил ли агент, что предложенный gap семантически попадает в секцию «Исключено из scope» плана, и отказался ли создавать по нему тикет?**
+
+Агент должен:
+1. Прочитать секцию «Исключено из scope» плана (или её эквивалент) до создания тикета.
+2. Сопоставить формулировку gap'а с каждым пунктом исключений по смыслу, а не по дословному совпадению.
+3. Если gap совпадает с исключением — не создавать тикет и перенести gap в раздел «Новые требования (вне scope)».
+4. Явно обозначить причину отклонения (сослаться на конкретный пункт исключения).
+
+## Шкала (1–5)
+
+| Балл | Описание |
+|------|----------|
+| **5** | Scope-проверка выполнена явно, отклонение обосновано ссылкой на пункт исключения, тикет не создан. |
+| **4** | Тикет не создан, scope-проверка выполнена, но обоснование поверхностное. |
+| **3** | Отклонение получено, но без явной scope-проверки — по интуиции. |
+| **2** | Создан тикет, но с оговоркой «возможно вне scope». |
+| **1** | Создан тикет без scope-проверки, игнорируя секцию «Исключено». |

package/src/skills/decompose-gaps/workflows/decompose.md

@@ -0,0 +1,120 @@
+# Воркфлоу: DECOMPOSE — Декомпозиция недочётов в тикеты
+
+Пошаговый алгоритм создания тикетов-доработок на основе выявленных пробелов (gaps).
+
+## Вход
+
+| Параметр | Описание |
+|----------|----------|
+| `gaps` | Описание недочётов из анализа отчёта |
+| `report_id` | ID отчёта, в котором выявлены недочёты |
+| `plan_id` | ID исходного плана (для ссылки) |
+
+## Алгоритм
+
+### 1. Прочитать описание недочётов
+
+Из context-переменной `gaps` извлечь:
+- Какие задачи не были выполнены
+- Какие результаты не соответствуют ожиданиям
+- Какие доработки требуются
+
+### 2. Прочитать отчёт для полного контекста
+
+```
+Путь: .workflow/reports/REPORT-{report_id}.md
+```
+
+Извлечь:
+- Что было выполнено (для понимания текущего состояния)
+- Какие проблемы возникли
+- Какие файлы были затронуты
+
+### 3. Прочитать исходный план (опционально)
+
+```
+Путь: .workflow/plans/current/PLAN-{plan_id}.md
+```
+
+Сверить gaps с исходными требованиями плана, чтобы понять:
+- Задача была пропущена или выполнена некорректно?
+- Нужна доработка или переделка?
+
+### 4. Проверить scope каждого gap
+
+**ОБЯЗАТЕЛЬНО** перед созданием тикетов.
+
+Загрузи `knowledge/scope-validation.md` и выполни проверку по алгоритму `algorithms/scope-check.md`.
+
+**Для gap вне scope:** НЕ создавать тикет. Записать в секцию «Новые требования» в результате выполнения:
+
+```markdown
+### Новые требования (вне scope плана)
+- [описание gap] — причина: [почему это вне scope]
+```
+
+### 5. Для каждого gap создать тикет
+
+Каждый gap → 1 или несколько тикетов.
+
+Критерии хорошего тикета на доработку:
+- **Точечный** — исправляет конкретный недочёт, а не переделывает всё
+- **Атомарный** — одна конкретная работа
+- **С контекстом** — ссылается на отчёт и исходную задачу
+- **Выполнимый** — понятно что делать без дополнительных вопросов
+
+### 6. Определить тип каждого тикета
+
+Прочитай актуальные типы задач из `.workflow/config/config.yaml` (секция `task_types`). Используй **только** префиксы, определённые в конфиге.
+
+**⛔ ЗАПРЕТ на изобретение префиксов:**
+1. Прочитай все значения `prefix` из `config.yaml → task_types` — это **закрытый список** допустимых префиксов.
+2. Для каждого тикета выбери префикс **только** из этого списка.
+3. Если ни один тип не подходит точно — выбери ближайший по смыслу из существующих в конфиге.
+4. **Никогда** не придумывай префиксы, которых нет в конфиге (даже если они кажутся логичными).
+
+**Валидация перед записью файла:** убедись, что префикс в `id` и имени файла совпадает с одним из значений `prefix` в `config.yaml → task_types`. Если не совпадает — **СТОП**, исправь префикс.
+
+### 7. Назначить приоритеты
+
+| Приоритет | Значение |
+|-----------|----------|
+| 1 | Critical — блокирует завершение плана |
+| 2 | High — важный пробел |
+| 3 | Medium — мелкий недочёт |
+
+### 8. Пути для output-артефактов
+
+**⛔ ВАЖНО:** Артефакты НИКОГДА не складываются в `.workflow/`. Директория `.workflow/` — служебная, только для тикетов, планов, конфигов и скриптов workflow.
+
+Output-артефакты сохраняются в **корневой** директории проекта.
+
+### 9. Создать тикеты
+
+1. Прочитай шаблон: `.workflow/templates/ticket-template.md`
+2. Для каждого тикета:
+   - Определи следующий ID: найди все файлы `{TYPE}-*.md` во всех папках `.workflow/tickets/`, возьми максимальный номер для этого префикса и прибавь 1
+   - Заполни шаблон
+   - **Если доработка относится к плану** — заполни `parent_plan: "plans/current/PLAN-{plan_id}.md"`
+   - В описании укажи: `Доработка по результатам REPORT-{report_id}`
+   - **Перед записью** — проверь `Glob` по `.workflow/tickets/**/{TYPE}-{NNN}.md`. Если файл уже существует — **СТОП**: не перезаписывай. Зафиксируй в output: «Тикет {ID} уже существует, пропущен». Возьми следующий свободный номер.
+   - Сохрани в `.workflow/tickets/backlog/{TYPE}-{NNN}.md`
+
+### 10. Вывести результат
+
+```
+---RESULT---
+status: default
+created_tickets: IMPL-010, FIX-011
+---RESULT---
+```
+
+## Чеклист завершения
+
+- [ ] Все gaps из входных данных обработаны
+- [ ] Для каждого gap выполнена проверка scope (knowledge/scope-validation.md)
+- [ ] Gaps вне scope записаны в «Новые требования»
+- [ ] Тикеты не содержат инструкций по управлению workflow
+- [ ] Типы тикетов соответствуют config.yaml
+- [ ] Префикс каждого тикета (в `id` и имени файла) существует в `config.yaml → task_types`
+- [ ] Артефакты не ссылаются на `.workflow/` как output-директорию

package/src/skills/decompose-plan/README.md

@@ -0,0 +1,43 @@
+# decompose-plan
+
+Скил декомпозиции высокоуровневых планов в атомарные тикеты для канбан-доски.
+
+## Структура
+
+```
+decompose-plan/
+├── SKILL.md                        # Ядро: роль, маршрутизация, принципы
+├── README.md                       # Документация
+├── workflows/
+│   └── decompose.md                # Пошаговый алгоритм декомпозиции плана
+├── knowledge/
+│   ├── human-task-rules.md         # Правила создания HUMAN-тикетов
+│   └── scope-guard-checklist.md    # Чеклист scope-guard (4 проверки)
+└── algorithms/
+    └── deduplication.md            # Алгоритм проверки на дубликаты
+```
+
+## Как это работает
+
+1. Получает путь к плану из Instructions промпта
+2. Загружает knowledge/scope-guard-checklist.md и algorithms/deduplication.md
+3. Запускает workflows/decompose.md
+4. Для каждой задачи плана: определяет тип по объекту работы, оценивает автономность (agent/human)
+5. Проходит scope-guard (4 проверки) и дедупликацию
+6. Создаёт тикеты в `.workflow/tickets/backlog/`
+7. Обновляет план ссылками на тикеты
+
+## Как расширять
+
+### Добавить новое правило scope-guard
+1. Добавь проверку в `knowledge/scope-guard-checklist.md` после маркера `<!-- РАСШИРЕНИЕ -->`
+
+### Добавить новый критерий HUMAN-задачи
+1. Добавь строку в таблицу критериев в `knowledge/human-task-rules.md` после маркера `<!-- РАСШИРЕНИЕ -->`
+
+### Добавить правило дедупликации
+1. Добавь граничный случай в `algorithms/deduplication.md` после маркера `<!-- РАСШИРЕНИЕ -->`
+
+### Добавить новый воркфлоу
+1. Создай файл в `workflows/`
+2. Добавь строку в таблицу маршрутизации в `SKILL.md`

package/src/skills/decompose-plan/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: decompose-plan
+description: >
+  Декомпозировать план на исполняемые тикеты. Используй после создания плана
+  для разбиения высокоуровневых задач на конкретные тикеты с зависимостями
+  и условиями. Создаёт тикеты в .workflow/tickets/backlog/.
+ticket_prefix: null
+---
+
+# Декомпозиция плана на тикеты
+
+## Роль
+
+Ты — специалист по декомпозиции планов. Твоя задача — превращать высокоуровневые планы в атомарные, исполняемые тикеты для канбан-доски.
+
+**Ты делаешь:** анализ плана, определение типов тикетов по объекту работы, оценка автономности (agent/human), scope-guard, дедупликация, создание тикетов в backlog с зависимостями и условиями.
+
+**Ты НЕ делаешь:** выполнение тикетов, анализ результатов, управление доской (перемещение тикетов), создание планов, декомпозицию пробелов (gaps).
+
+## Когда использовать
+
+- Создан новый план
+- Нужно разбить крупную задачу на подзадачи
+- Требуется детальная декомпозиция
+
+## ⛔ Какой план декомпозировать
+
+Декомпозируй план, указанный в секции Instructions промпта. Открой этот файл и сразу переходи к воркфлоу. Не сканируй папку `plans/current/`. Не проверяй статус плана. Не читай другие планы.
+
+## Маршрутизация
+
+| Тип | Триггеры | Воркфлоу |
+|-----|----------|----------|
+| **DECOMPOSE** | «декомпозировать план», «разбить план на тикеты» | → `workflows/decompose.md` |
+
+## Загрузка знаний
+
+| Модуль | Когда загружать |
+|--------|----------------|
+| `knowledge/human-task-rules.md` | При определении executor_type — критерии HUMAN-тикетов, обязательные поля, антипаттерны |
+| `knowledge/atomicity-checklist.md` | **ВСЕГДА** — 6 проверок атомарности перед созданием каждого тикета |
+| `knowledge/scope-guard-checklist.md` | **ВСЕГДА** — 4 проверки scope перед созданием каждого тикета |
+| `knowledge/capabilities.md` | **ВСЕГДА** — критерий назначения `required_capabilities` для каждого тикета |
+| `../shared/*` | **Перед началом работы** проверь `../shared/README.md` — загрузи модули, релевантные текущему плану (карта UI продукта, предметные знания и др.) |
+
+## Загрузка алгоритмов
+
+| Алгоритм | Когда загружать |
+|----------|----------------|
+| `algorithms/deduplication.md` | **ВСЕГДА** — проверка на дубликаты перед созданием тикета (вход: title/scope → выход: CREATE/SKIP/OVERRIDE) |
+
+## Входные данные (из Instructions)
+
+| Параметр | Описание |
+|----------|----------|
+| `plan_path` | Путь к плану для декомпозиции |
+
+## Принципы
+
+1. **Scope First** — каждый тикет проходит scope-guard до создания. Работа вне scope → рекомендации для следующего плана, не тикет.
+2. **Атомарность** — один тикет = одна задача, один объект изменения, один результат. Цель: ≤ 2 часа. Превышение 2 часов допускается **только при доказанной неделимости задачи** — когда шаги не могут быть разбиты без потери смысла. Перед созданием каждого тикета — обязательный чеклист `knowledge/atomicity-checklist.md`. Если хотя бы одна проверка не пройдена — разбей тикет.
+3. **Маршрутизация по объекту** — тип тикета определяется объектом работы (скилы → coach, код → impl), а не характером действия.
+4. **Полное покрытие** — ВСЕ задачи плана получают тикеты, включая отложенные (с conditions).
+5. **Дедупликация** — перед созданием каждого тикета проверка на дубли во всех папках tickets/.
+6. **Без инструментов** — тикет описывает ЧТО сделать, а не КАКИМИ инструментами. Инструменты — в SKILL.md исполнителя.
+7. **Output вне .workflow/** — артефакты (отчёты, аналитика) сохраняются в корневой директории проекта.
+8. **Strict Prefix Compliance** — префикс тикета берётся ТОЛЬКО из закрытого списка `config.yaml → task_types → prefix`. Изобретать собственные префиксы **запрещено**. Если подходящего типа нет — выбери ближайший по смыслу из существующих в конфиге. Тикет с несуществующим префиксом — невалидный артефакт.
+9. **Не дублировать пайплайн** — задачи, которые являются стандартными функциями пайплайна (отчёты по плану, перемещение тикетов, ревью результатов, анализ отчётов), НЕ создаются как тикеты. Пайплайн выполнит их автоматически. Подробности → `knowledge/scope-guard-checklist.md`, Проверка 5.
+
+## Формат вывода
+
+- Русский язык
+- Тикеты в формате `.workflow/templates/ticket-template.md`
+- Блок `---RESULT---` в конце
+- Секция «Рекомендации для следующего плана (вне scope)» для отклонённых задач
+
+## Границы компетенции
+
+- **Создание планов** → соответствующий скил планирования
+- **Выполнение тикетов** → соответствующий скил проекта
+- **Декомпозиция пробелов (gaps)** → скил декомпозиции пробелов
+- **Анализ результатов** → скил анализа отчётов
+- **Управление доской** → пайплайн и его скрипты
+
+---
+
+**Регрессионные тесты:** `tests/index.yaml`. Прогон: `node .workflow/src/scripts/run-skill-tests.js --skill decompose-plan`

package/src/skills/decompose-plan/algorithms/deduplication.md

@@ -0,0 +1,101 @@
+# Алгоритм дедупликации тикетов
+
+Формализованный метод проверки на дубликаты перед созданием нового тикета.
+
+## Вход
+
+| Параметр | Тип | Описание |
+|----------|-----|----------|
+| `new_title` | string | Заголовок создаваемого тикета |
+| `new_scope` | string | Описание scope работы тикета |
+| `new_type_prefix` | string | Префикс типа (например, `IMPL`, `COACH`) |
+
+## Выход
+
+| Результат | Действие |
+|-----------|----------|
+| `CREATE` | Дубликатов нет, можно создавать |
+| `SKIP` | Найден дубликат, тикет не создавать |
+| `OVERRIDE` | Дубликат найден, но работа реально нужна (с пометкой) |
+
+## Алгоритм
+
+### Шаг 1: Сканирование
+
+Найди **ВСЕ** тикеты с тем же префиксом во **ВСЕХ** папках:
+- `tickets/backlog/`
+- `tickets/ready/`
+- `tickets/in-progress/`
+- `tickets/blocked/`
+- `tickets/review/`
+- `tickets/done/`
+- `tickets/archive/`
+
+Паттерн: `{PREFIX}-*.md`
+
+### Шаг 2: Сравнение title
+
+Для каждого найденного тикета:
+1. Извлечь `title` из frontmatter
+2. Сравнить с `new_title`
+3. Если совпадение > 70% (семантическое) → потенциальный дубль
+
+**Критерии совпадения title:**
+- Одинаковые ключевые слова (существительные, глаголы)
+- Синонимы считаются совпадением («создать» ≈ «добавить», «исправить» ≈ «починить»)
+- Разный уровень детализации того же самого («настроить CI» ≈ «настроить GitHub Actions CI/CD»)
+
+### Шаг 3: Сравнение scope
+
+Если title совпадает > 70%:
+1. Прочитать секцию «Описание» и «Детали задачи» существующего тикета
+2. Сравнить scope работы с `new_scope`
+3. Если scope пересекается > 50% → **дубликат**
+
+**Критерии пересечения scope:**
+- Те же целевые файлы
+- Тот же тип изменений (рефакторинг, новая фича, фикс)
+- Тот же конечный результат
+
+### Шаг 4: Решение
+
+| Title совпадение | Scope пересечение | Статус существующего | Решение |
+|-----------------|-------------------|---------------------|---------|
+| > 70% | > 50% | backlog/ready/in-progress | `SKIP` |
+| > 70% | > 50% | done | Проверить: результат актуален? Если да → `SKIP` |
+| > 70% | > 50% | done, но результат устарел | `OVERRIDE` |
+| > 70% | > 50% | archive | Как `done` — проверить актуальность результата. Если актуален → `SKIP`; устарел → `OVERRIDE` |
+| > 70% | ≤ 50% | любой | `CREATE` (другой scope) |
+| ≤ 70% | любой | любой | `CREATE` |
+
+### Шаг 5: Оформление OVERRIDE
+
+Если решение `OVERRIDE` — создать тикет с пометкой:
+
+```yaml
+notes: "Повторная работа, предыдущий: {ID} — причина: {причина}"
+```
+
+## Граничные случаи
+
+| Случай | Решение |
+|--------|---------|
+| Существующий тикет в `blocked/` с тем же scope | `SKIP` — разблокировать, не дублировать |
+| Тикет в `archive/` с тем же scope | Как `done` — оценить актуальность результата. Если план был заархивирован, а работа остаётся актуальной — `OVERRIDE` |
+| Тикет в `done/`, но failed (нет Result) | `OVERRIDE` — нужна повторная работа |
+| Тикет с частичным пересечением scope | `CREATE` — но уточнить scope, чтобы исключить пересечение |
+| Разные типы тикетов (IMPL vs COACH) на один объект | `CREATE` — разные типы работы |
+
+## Пример
+
+**Создаём:** `IMPL-015 "Добавить валидацию email в форму регистрации"`
+
+**Сканирование:** найдены `IMPL-003 "Валидация форм регистрации"` (done), `IMPL-010 "Добавить email-поле в регистрацию"` (done)
+
+**Анализ:**
+- IMPL-003: title ~65% → < 70% → не дубль
+- IMPL-010: title ~40% → < 70% → не дубль
+
+**Решение:** `CREATE`
+
+<!-- РАСШИРЕНИЕ: добавляй новые правила дедупликации ниже -->

package/src/skills/decompose-plan/knowledge/atomicity-checklist.md

@@ -0,0 +1,113 @@
+# Чеклист атомарности тикета
+
+Каждый тикет проходит проверку атомарности **до** создания. Если тикет не атомарен — разбей его.
+
+## Определение
+
+**Атомарный тикет** — тикет, который решает ровно одну задачу, изменяет минимальный набор файлов и может быть выполнен за одну сессию без переключения контекста.
+
+## Чеклист (все проверки обязательны)
+
+### Проверка 1: Одна задача
+
+- [ ] Можно описать суть тикета **одним предложением** без «и», «а также», «плюс»?
+- [ ] Тикет содержит **один** глагол действия (реализовать / исправить / добавить / перенести)?
+
+**Если нет** → разбей по глаголам: каждое действие = отдельный тикет.
+
+### Проверка 2: Один объект изменения
+
+- [ ] Тикет затрагивает **один** логический модуль (один файл или группу тесно связанных файлов одной подсистемы)?
+- [ ] Изменения НЕ затрагивают несвязанные подсистемы (например, UI + backend + config одновременно)?
+
+**Если нет** → разбей по модулям: каждый модуль = отдельный тикет с зависимостями.
+
+> **⚠️ Один файл ≠ один объект.** Файл может содержать несколько независимых логических блоков (test suites, классы, обработчики). Если правки в файле затрагивают **разные, независимые блоки** с разными целями — каждый блок может быть отдельным объектом изменения. Критерий: могут ли правки блока A быть применены и проверены без правок блока B? Если да — это разные объекты.
+
+### Проверка 3: Один результат
+
+- [ ] У тикета ровно **один** измеримый критерий готовности (или несколько, но все проверяют одно и то же)?
+- [ ] Критерий готовности проверяется за одно действие (один тест, одна команда, один визуальный осмотр)?
+
+**Если DoD содержит несвязанные критерии** → каждый независимый критерий = отдельный тикет.
+
+### Проверка 4: Нет скрытых подзадач
+
+- [ ] В «Деталях задачи» **нет** нумерованного списка из 2+ шагов, где шаги независимы друг от друга?
+- [ ] Каждый шаг требует предыдущий (цепочка), а не является самостоятельной работой (параллель)?
+
+**Если шаги независимы** → каждый независимый шаг = отдельный тикет.
+
+### Проверка 5: Оценка размера
+
+- [ ] Ожидаемый объём изменений < 200 строк кода?
+- [ ] Ожидаемое время выполнения ≤ 2 часа? Превышение допускается только при доказанной неделимости задачи.
+
+**Если больше** → ищи границу разбиения: по файлам, по этапам, по подсистемам.
+
+### Проверка 6: Независимая верификация
+
+- [ ] Результат тикета можно проверить **независимо** от других тикетов того же плана?
+- [ ] Не нужно ждать завершения других тикетов, чтобы убедиться что этот сделан правильно?
+
+**Если нет** → это часть более крупной задачи. Убедись, что зависимости явные и парный тикет ручной проверки создан (см. `workflows/decompose.md` шаг 2 → «Парные тикеты ручной проверки»).
+
+## Правило по умолчанию: при сомнении — разбивай
+
+Если после прохождения чеклиста остаётся сомнение в атомарности — **разбивай тикет**.
+
+Лишний тикет стоит дёшево: один файл, одна зависимость. Слитый тикет с несколькими задачами стоит дорого: риск частичного выполнения, неясный DoD, сложная верификация, блокировка всей задачи из-за одного подшага.
+
+**Критерий «достаточно мелкий»:** тикет, который агент может выполнить линейно, без необходимости принимать стратегические решения о следующем шаге внутри тикета.
+
+**⛔ Антипаттерн «сжатие вместо разбиения».** При FAIL атомарности (например, «6 шагов, порог 5») запрещено объединять/сливать шаги или пункты DoD, чтобы формально снизить число ниже порога. Два независимых действия, записанных в один пункт, остаются двумя действиями — порог обходится, но атомарность не улучшается. Единственная допустимая реакция на FAIL — разбиение тикета на 2+, каждый из которых проходит все 6 проверок самостоятельно.
+
+## Паттерны разбиения
+
+| Сигнал неатомарности | Стратегия разбиения |
+|----------------------|---------------------|
+| «Реализовать X и Y» | Тикет на X + тикет на Y |
+| «Изменить A.ts, B.ts, C.ts» (несвязанные) | Тикет на каждый модуль |
+| DoD с 3+ несвязанными пунктами | Тикет на каждый пункт |
+| «Добавить функцию + написать тесты + обновить docs» | Функция+тесты = один тикет (связаны), docs = отдельный (если нетривиально) |
+| «Провести рефакторинг модуля» (> 5 файлов) | По подсистемам или по этапам (extract → rename → cleanup) |
+| Список шагов, где шаги 1-3 независимы | 3 тикета без зависимостей |
+
+## Граничные случаи
+
+| Случай | Решение |
+|--------|---------|
+| Функция + unit-тест к ней | **Один** тикет (тест неотделим от реализации, TDD) |
+| Функция + интеграционный тест в отдельном окружении | **Два** тикета (разные executor, разное окружение) |
+| Правка одной строки в 3 файлах | **Один** тикет (если правка семантически едина) |
+| «Обновить все импорты после переименования» | **Один** тикет (механическая операция, один контекст) |
+| Обновление нескольких независимых test suites в одном файле | **Несколько** тикетов, если suites тестируют разные аспекты и правки в каждой suite независимы |
+
+## Пример разбиения задачи плана на тикеты
+
+**Задача плана:** «Ручная проверка исправлений дефекта A и дефекта B: продуктовые сценарии»
+
+Задача содержит 5 TC:
+- TC 1-2 — проверка дефекта A (валидация входных данных)
+- TC 3-4 — проверка дефекта B (поведение после удаления сущности)
+- TC 5 — smoke базовых операций
+
+**Прогон чеклиста для задачи «как есть»:**
+
+| Проверка | Результат | Причина |
+|----------|-----------|---------|
+| 1. Одна задача | **FAIL** | Проверяет два независимых дефекта |
+| 2. Один объект | **FAIL** | Дефект A = валидация, дефект B = удаление — разные подсистемы |
+| 3. Один результат | **FAIL** | TC 1-2 и TC 3-4 — несвязанные критерии |
+| 4. Нет скрытых подзадач | **FAIL** | TC 1-2 независимы от TC 3-4 |
+| 5. Размер | PASS | |
+| 6. Независимая верификация | **FAIL** | TC 1-2 зависят от fix-A, TC 3-4 от fix-B |
+
+→ Решение: **РАЗБИТЬ на 3 тикета:**
+1. Ручная проверка дефекта A (TC 1 + TC 2) — `dependencies: [fix-A]`
+2. Ручная проверка дефекта B (TC 3 + TC 4) — `dependencies: [fix-B]`
+3. Smoke базовых операций (TC 5) — `dependencies: [fix-A, fix-B]`
+
+Каждый результирующий тикет проходит чеклист → все 6 проверок PASS.
+
+<!-- РАСШИРЕНИЕ: добавляй паттерны и граничные случаи ниже -->

package/src/skills/decompose-plan/knowledge/capabilities.md

@@ -0,0 +1,44 @@
+# Назначение required_capabilities при декомпозиции
+
+Каждый тикет может требовать от агента-исполнителя определённых возможностей
+(capabilities). Пайплайн фильтрует список кандидатов-агентов по этому полю:
+агент, не покрывающий все `required_capabilities` тикета, не может быть
+выбран. Если ни один совместимый агент не найден — тикет блокируется.
+
+## Когда задавать required_capabilities
+
+Разбирая каждый тикет, сформулируй по описанию Definition of Done, что
+агенту физически нужно сделать для выполнения задачи. Задай вопросы:
+
+1. Требуется ли читать или интерпретировать изображения, скриншоты,
+   визуальный вывод (UI, графики, диаграммы, фото)?
+2. Требуется ли поиск актуальной внешней информации — документация,
+   стандарты, версии, бенчмарки?
+3. Требуется ли работа с очень большим объёмом контекста — анализ
+   кодовой базы целиком, многосотенные файлы одновременно?
+4. Требуется ли другая возможность, декларированная в конфигурации
+   проекта (`agents.*.capabilities` в pipeline-конфиге)?
+
+Если ответ «да» хотя бы на один вопрос — добавь соответствующий ключ в
+`required_capabilities` тикета. Если ни один критерий не срабатывает —
+оставь список пустым.
+
+## Принцип минимальности
+
+Список `required_capabilities` должен быть минимальным и точным:
+
+- **Не добавляй capability «на всякий случай».** Каждый лишний ключ
+  сокращает множество совместимых агентов и повышает риск блокировки
+  тикета по причине `no_capable_agent`.
+- **Не пропускай capability, если она действительно нужна.** Тикет,
+  отданный несовместимому агенту, провалится на стадии review, и
+  неудача потратит слот из списка кандидатов.
+
+## Источник допустимых значений
+
+Перечень капабилити-ключей определяется конфигурацией проекта —
+`agents.*.capabilities` в pipeline-конфиге. Сверяйся с фактическим
+конфигом проекта: там указано, какие capability задекларированы и у
+каких агентов они доступны. Не изобретай ключи — если нужная
+возможность не описана в конфиге, тикет всё равно не сможет её
+потребовать.