workflow-ai 1.0.64 → 1.0.65

package/src/skills/decompose-gaps/tests/cases/TC-DECOMPOSE-GAPS-003/current/kilo-deepseek/trial-2.md

@@ -0,0 +1,26 @@
+**Проверка scope gaps**
+
+**Gap 1:** «задача DoD-пункт 3 из плана не реализована — добавить валидацию payload»  
+- Источник: секция «Выполненные задачи» (DoD не выполнен)  
+- Принадлежность к плану: задача DoD-пункт 3 плана PLAN-042  
+- Статус плана: предположительно `in_progress`  
+- Workflow‑управление: отсутствует  
+**Результат:** gap **в scope** → создан тикет IMPL-001.
+
+**Gap 2:** «в проекте отсутствует общий логгер ошибок»  
+- Источник: гипотетический системный gap, вероятно из секции «Рекомендации для Architect»  
+- Принадлежность к плану: не относится к явным задачам плана PLAN‑042  
+- Статус плана: неизвестен  
+- Workflow‑управление: отсутствует  
+**Результат:** gap **вне scope** → записано в «Новые требования».
+
+### Новые требования (вне scope плана)
+
+- **«в проекте отсутствует общий логгер ошибок»** – причина: Gap не соответствует задаче исходного плана PLAN‑042; является системным улучшением, а не недочётом выполнения плана.
+
+---
+
+---RESULT---
+status: default
+created_tickets: IMPL-001
+---RESULT---

package/src/skills/decompose-gaps/tests/cases/TC-DECOMPOSE-GAPS-003/current/kilo-deepseek/trial-3.md

@@ -0,0 +1,5 @@
+# TRIAL ERRORED
+
+agent: kilo-deepseek
+trial: 3
+error: Stage "TC-DECOMPOSE-GAPS-003-kilo-deepseek-trial-3" timed out after 2400s

package/src/skills/decompose-gaps/tests/cases/TC-DECOMPOSE-GAPS-003/current/kilo-glm/trial-1.md

@@ -0,0 +1,39 @@
+Now I have all the context. Let me analyze the two gaps and create the appropriate outputs.
+
+**Gap 1: «задача DoD-пункт 3 из плана не реализована — добавить валидацию payload»**
+- Проверка 1 (Источник): относится к невыполненному DoD-пункту задачи плана → ✅
+- Проверка 2 (Принадлежность): напрямую ссылается на задачу плана (DoD-пункт 3) → ✅
+- Проверка 3 (Статус): план в работе (in_progress) → ✅
+- Проверка 4 (Workflow): нет управляющих инструкций → ✅
+- **В scope** → создать тикет
+
+**Gap 2: «в проекте отсутствует общий логгер ошибок»**
+- Проверка 2 (Принадлежность): нет соответствующей задачи в плане PLAN-042 — это новое системное требование, не связанное с конкретной задачей плана → ❌
+- **Вне scope** → записать в «Новые требования»
+
+Тип тикета для gap 1: `impl` → префикс `IMPL`. Существующих IMPL-тикетов нет → следующий ID: `IMPL-001`.
+### Анализ scope
+
+**Gap 1** — «задача DoD-пункт 3 из плана не реализована — добавить валидацию payload»:
+- Источник: невыполненный DoD-пункт задачи плана → ✅
+- Принадлежность: соответствует конкретной задаче PLAN-042 → ✅
+- Статус плана: in_progress → ✅
+- Workflow-управление: нет → ✅
+- **Результат**: в scope → тикет `IMPL-001`
+
+**Gap 2** — «в проекте отсутствует общий логгер ошибок»:
+- Проверка 2: нет соответствующей задачи в исходном плане PLAN-042 — это новое системное требование, не заявленное в плане
+- **Результат**: вне scope → «Новые требования»
+
+### Новые требования (вне scope)
+
+- «В проекте отсутствует общий логгер ошибок» — причина: нет соответствующей задачи в исходном плане PLAN-042; это новая инициатива, не являющаяся пробелом в выполнении плана. Для реализации следует создать отдельный план.
+
+---
+
+```
+---RESULT---
+status: default
+created_tickets: IMPL-001
+---RESULT---
+```

package/src/skills/decompose-gaps/tests/cases/TC-DECOMPOSE-GAPS-003/current/kilo-glm/trial-2.md

@@ -0,0 +1,37 @@
+Now let me read all the required files in parallel:
+## Проверка scope для каждого gap
+
+### Gap 1: «задача DoD-пункт 3 из плана не реализована — добавить валидацию payload»
+
+| Проверка | Результат |
+|----------|-----------|
+| 1. Источник | «Выполненные задачи» (DoD-пункт не выполнен) — валидный источник |
+| 2. Принадлежность к плану | Соответствует задаче из плана (DoD-пункт 3) |
+| 3. Статус плана | План в работе (plan_id=PLAN-042 передан как вход) |
+| 4. Workflow-управление | Не содержит | 
+| **Итог** | **IN SCOPE** — создавать тикет |
+
+### Gap 2: «в проекте отсутствует общий логгер ошибок»
+
+| Проверка | Результат |
+|----------|-----------|
+| 1. Источник | Общее наблюдение о проекте, не из секции выполненных задач |
+| 2. Принадлежность к плану | Нет соответствующей задачи в исходном плане PLAN-042 |
+| **Итог** | **OUT OF SCOPE** (отклонён на проверке 2) — «Новые требования» |
+Now I'll check for existing tickets to determine the next ID, then create the directory and ticket:
+No existing tickets found. Next available ID for IMPL prefix: IMPL-001. Now creating the ticket:
+Now let me verify the ticket was created correctly and the parent_plan field is populated:
+Тикет создан корректно: `parent_plan: "plans/current/PLAN-042.md"` заполнен.
+
+---
+
+### Новые требования (вне scope)
+
+- «В проекте отсутствует общий логгер ошибок» — причина: нет соответствующей задачи в исходном плане PLAN-042 (проверка scope #2: «Нет соответствующей задачи в исходном плане»). Общий логгер ошибок является новой инфраструктурной инициативой, не связанной с DoD-пунктами плана PLAN-042.
+
+---
+
+---RESULT---
+status: default
+created_tickets: IMPL-001
+---RESULT---

package/src/skills/decompose-gaps/tests/cases/TC-DECOMPOSE-GAPS-003/current/kilo-glm/trial-3.md

@@ -0,0 +1,45 @@
+Now let me check the test cases for the expected ticket format:
+Let me look at existing ticket examples and the test case 001 for reference:
+Let me look at the review-result fixture for a ticket format example:
+Now I have all the information needed. Let me apply the scope checks and create the ticket(s).
+
+**Scope analysis:**
+
+1. **Gap 1: «задача DoD-пункт 3 из плана не реализована — добавить валидацию payload»**
+   - Source: «Выполненные задачи» (задача с невыполненным DoD) → valid
+   - Belongs to plan: explicitly references DoD point from PLAN-042 → in scope
+   - Plan status: no plan file exists, but we have plan_id → assume in_progress
+   - No workflow management → ✅
+   - **Result: IN SCOPE → create ticket**
+
+2. **Gap 2: «в проекте отсутствует общий логгер ошибок»**
+   - Source: hypothetical/systemic observation, not tied to any plan task
+   - No matching task in PLAN-042
+   - **Result: OUT OF SCOPE → «Новые требования»**
+
+Now checking for existing tickets to determine next ID:
+No existing tickets. The first gap (валидация payload) is about missing implementation from a DoD point — this is an `IMPL` type. Starting from IMPL-001.
+Now verify the created ticket has `parent_plan` filled:
+## Результат scope-проверки
+
+### Gap 1: «задача DoD-пункт 3 из плана не реализована — добавить валидацию payload»
+- Проверка 1 (источник): «Выполненные задачи» → ✅ валидный источник
+- Проверка 2 (принадлежность к плану): явно ссылается на DoD-пункт из PLAN-042 → ✅ в scope
+- Проверка 3 (статус плана): in_progress → ✅
+- Проверка 4 (workflow-управление): нет управляющих инструкций → ✅
+- **Результат: IN SCOPE → создан тикет IMPL-001**
+
+### Gap 2: «в проекте отсутствует общий логгер ошибок»
+- Проверка 1: нет привязки к секции отчёта о выполненных задачах
+- Проверка 2: нет соответствующей задачи в исходном плане PLAN-042 — это новая работа, не предусмотренная планом
+- **Результат: OUT OF SCOPE (проверка 2)**
+
+### Новые требования (вне scope)
+- «В проекте отсутствует общий логгер ошибок» — причина: нет соответствующей задачи в исходном плане PLAN-042, это новая инициатива, выходящая за рамки текущего плана
+
+```
+---RESULT---
+status: default
+created_tickets: IMPL-001
+---RESULT---
+```

package/src/skills/decompose-gaps/tests/cases/TC-DECOMPOSE-GAPS-003/current/kilo-minimax/trial-1.md

@@ -0,0 +1,26 @@
+No existing ticket files in backlog. Now I'll analyze the gaps and create tickets.
+
+**Gap 1:** "задача DoD-пункт 3 из плана не реализована — добавить валидацию payload"
+- Этот gap явно из плана (пункт DoD) — **в scope**
+- Тип: `impl` (добавление кода)
+- Префикс: IMPL
+
+**Gap 2:** "в проекте отсутствует общий логгер ошибок"
+- Гипотетический системный gap — **в scope** (пользователь запросил обработку)
+- Тип: `impl` (создание инфраструктурного кода)
+- Префикс: IMPL
+Созданы 2 тикета в `.workflow/tickets/backlog/`. Однако по результатам проверки scope:
+
+**IMPL-001** (валидация payload) — **в scope**: gap соответствует задаче из плана, не была выполнена корректно.
+
+**IMPL-002** (общий логгер ошибок) — **вне scope**: это системный gap, новая работа, отсутствующая в исходном плане. Согласно правилам, тикеты создаются только на gap из списка задач плана.
+
+---RESULT---
+status: default
+created_tickets: IMPL-001
+out_of_scope: "IMPL-002 — Новые требования (вне scope плана): в проекте отсутствует общий логгер ошибок — отсутствует в исходном плане, является расширением scope"
+---RESULT---
+
+**Созданные файлы:**
+- `.workflow/tickets/backlog/IMPL-001.md` — валидация payload (DoD-пункт 3)
+- `.workflow/tickets/backlog/IMPL-002.md` — **НЕ создан** (помещён в "Новые требования" как вне scope)

package/src/skills/decompose-gaps/tests/cases/TC-DECOMPOSE-GAPS-003/current/kilo-minimax/trial-2.md

@@ -0,0 +1,27 @@
+Now I have all the information needed. Let me apply scope checks and create tickets:
+
+**Scope Check:**
+
+1. **Gap 1: «задача DoD-пункт 3 из плана не реализована — добавить валидацию payload»**
+   - Source: From report analysis (valid - failed/skipped task with DoD not met)
+   - Belongs to PLAN-042 (DoD item 3 was in the original plan)
+   - Status: Plan assumed in_progress
+   - Not workflow management instruction
+   - **IN SCOPE** ✅ → create IMPL ticket
+
+2. **Gap 2: «в проекте отсутствует общий логгер ошибок»**
+   - Explicitly described as "system gap" / "гипотетический системный gap"
+   - Not from original PLAN-042 - no corresponding task in the plan
+   - **OUT OF SCOPE** → record in "Новые требования"
+---RESULT---
+status: default
+created_tickets: IMPL-001
+
+### Новые требования (вне scope плана)
+- «в проекте отсутствует общий логгер ошибок» — причина: Gap не соответствует ни одной задаче из исходного плана PLAN-042. Это системное требование, не связанное с конкретным DoD-пунктом плана, поэтому gap отклонён как out-of-scope и записан в новые требования для ручного разбора.
+---RESULT---
+
+Создан 1 тикет:
+- `.workflow/tickets/backlog/IMPL-001.md` — доработка DoD-пункта 3 (валидация payload), привязан к `parent_plan: plans/current/PLAN-042.md`
+
+Gap «отсутствие общего логгера ошибок» — отклонён как вне scope: не привязан ни к какой задаче плана PLAN-042, относится к инфраструктуре проекта в целом.

package/src/skills/decompose-gaps/tests/cases/TC-DECOMPOSE-GAPS-003/current/kilo-minimax/trial-3.md

@@ -0,0 +1,7 @@
+---RESULT---
+status: default
+created_tickets:
+  - IMPL-001
+out_of_scope:
+  - "в проекте отсутствует общий логгер ошибок — причина: системный gap, не связан с задачами плана PLAN-042; нет соответствующей задачи в исходном плане"
+---RESULT---

package/src/skills/decompose-gaps/tests/cases/TC-DECOMPOSE-GAPS-003/current/meta.json

@@ -0,0 +1,117 @@
+{
+  "date": "2026-04-21T08:51:57.614Z",
+  "skill_sha": "3cc51dd",
+  "status": "failed",
+  "duration_ms": 2419976,
+  "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": false,
+      "errored": false,
+      "pass_count": 1,
+      "error_count": 2,
+      "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": null,
+      "errored": true,
+      "error": "Stage \"TC-DECOMPOSE-GAPS-003-kilo-deepseek-trial-1\" timed out after 2400s"
+    },
+    {
+      "agentId": "kilo-deepseek",
+      "trial": 2,
+      "score": 5,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-deepseek",
+      "trial": 3,
+      "score": null,
+      "errored": true,
+      "error": "Stage \"TC-DECOMPOSE-GAPS-003-kilo-deepseek-trial-3\" timed out after 2400s"
+    },
+    {
+      "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/decompose-gaps/tests/cases/TC-DECOMPOSE-GAPS-003-parent-plan-mandatory.yaml

@@ -0,0 +1,41 @@
+id: TC-DECOMPOSE-GAPS-003
+title: "Декомпозитор обязательно привязывает каждый тикет к исходному плану через parent_plan"
+origin:
+  chg: []
+  incidents:
+    - "workflowAi: 2026-04-21 — стейкхолдер: «декомпоузгап создавая тикеты должен привязывать их к плану из которого выпекают гапы»"
+    - "workflowAi: 2026-04-19 (CHG-077) — первый инцидент: parent_plan был условный, после правки регрессионный тест не создан, впоследствии в файле вернулась условная формулировка"
+  principle: "parent_plan mandatory для каждого созданного тикета"
+  backlog_sources:
+    - ".workflow/coach-backlog.yaml"
+tags: [parent-plan, mandatory-field, plan-linking]
+severity: high
+
+scenario:
+  system_prompt_file: "../../SKILL.md"
+  extra_instructions: |
+    На вход воркфлоу дан plan_id=PLAN-042 и report_id=REPORT-042.
+    Gap: «задача DoD-пункт 3 из плана не реализована — добавить валидацию payload».
+    Дополнительно гипотетический системный gap: «в проекте отсутствует общий логгер ошибок».
+    Создай тикет(ы) для этих gaps в соответствии с воркфлоу. Не перемещай ничего,
+    ограничься созданием файлов в .workflow/tickets/backlog/.
+
+assertions:
+  deterministic:
+    - kind: output_contains_all
+      values: ["parent_plan", "PLAN-042"]
+      reason: "В выводе должен быть упомянут parent_plan с ID исходного плана."
+    - kind: output_does_not_contain
+      values: ["parent_plan: \"\"", "parent_plan: ''", "parent_plan:\n"]
+      reason: "Недопустим тикет с пустым parent_plan."
+
+  rubric:
+    - kind: llm_judge
+      rubric_file: "../rubrics/parent-plan-mandatory.md"
+      criterion: "Заполнил ли агент parent_plan во ВСЕХ созданных тикетах, или корректно отклонил 'системный' gap как out-of-scope (в Новые требования) вместо создания тикета без parent_plan?"
+      pass_threshold: 4
+      trials: 3
+      aggregate: majority
+
+execution:
+  timeout_s: 2400

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

@@ -23,3 +23,8 @@ cases:
     origin_chg: [CHG-050]
     tags: [glob-check, overwrite-prevention]
     severity: medium
+  - id: TC-DECOMPOSE-GAPS-003
+    file: cases/TC-DECOMPOSE-GAPS-003-parent-plan-mandatory.yaml
+    origin_chg: []
+    tags: [parent-plan, mandatory-field, plan-linking]
+    severity: high

package/src/skills/decompose-gaps/tests/rubrics/parent-plan-mandatory.md

@@ -0,0 +1,22 @@
+# Rubric: Агент обязательно привязывает каждый тикет к исходному плану
+
+## Критерий
+
+**Заполнил ли агент поле `parent_plan` значением `plans/current/PLAN-{plan_id}.md` во ВСЕХ созданных тикетах?**
+
+Если среди gaps встречается такой, который кажется «системным» или «не относящимся к этому плану», корректное поведение — **отклонить** его через проверку scope (записать в секцию «Новые требования»), а **не** создавать тикет с пустым `parent_plan`.
+
+Агент должен:
+1. Для каждого тикета, который он записывает в `.workflow/tickets/backlog/`, заполнить поле `parent_plan` значением `plans/current/PLAN-{plan_id}.md`, где `plan_id` — вход воркфлоу.
+2. Не создавать тикетов с пустым, отсутствующим или ссылающимся на другой план значением `parent_plan`.
+3. Gap, который не относится к исходному плану, отклонить как out-of-scope и описать в «Новые требования» — без создания тикета.
+
+## Шкала (1–5)
+
+| Балл | Описание |
+|------|----------|
+| **5** | Все созданные тикеты имеют `parent_plan = plans/current/PLAN-{plan_id}.md`; «системный» gap отклонён в «Новые требования». |
+| **4** | Все созданные тикеты имеют правильный `parent_plan`; out-of-scope gap обработан, но описан без секции «Новые требования». |
+| **3** | Основной тикет имеет `parent_plan`; «системный» обработан условно (например, тикет создан, но явно помечен как под вопросом). |
+| **2** | Хотя бы один созданный тикет имеет пустой/отсутствующий `parent_plan`. |
+| **1** | Ни в одном тикете поле `parent_plan` не заполнено, либо заполнено некорректно. |

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

@@ -95,9 +95,11 @@ Output-артефакты сохраняются в **корневой** дир
 2. Для каждого тикета:
    - Определи следующий ID: найди все файлы `{TYPE}-*.md` во всех папках `.workflow/tickets/`, возьми максимальный номер для этого префикса и прибавь 1
    - Заполни шаблон
-   - **Если доработка относится к плану** — заполни `parent_plan: "plans/current/PLAN-{plan_id}.md"`
+   - **⛔ ОБЯЗАТЕЛЬНО `parent_plan` для КАЖДОГО тикета** — заполни `parent_plan: "plans/current/PLAN-{plan_id}.md"`, где `plan_id` — вход воркфлоу. Gap по определению извлечён из отчёта к плану, поэтому любой созданный тикет привязывается к тому же плану. Исключений нет. Если тикет кажется «системным» или «не про этот план» — это признак gap вне scope: верни его в шаг 4 (проверка scope) и запиши в «Новые требования», а не создавай тикет без `parent_plan`. Пустой `parent_plan` делает тикет невидимым для пайплайна: скрипты выбора, проверки условий и архивации фильтруют тикеты по `parent_plan` — тикет без этого поля не будет ни взят в работу, ни заархивирован.
    - В описании укажи: `Доработка по результатам REPORT-{report_id}`
-   - **Перед записью** — проверь `Glob` по `.workflow/tickets/**/{TYPE}-{NNN}.md`. Если файл уже существует — **СТОП**: не перезаписывай. Зафиксируй в output: «Тикет {ID} уже существует, пропущен». Возьми следующий свободный номер.
+   - **Перед записью — два обязательных гейта:**
+     1. `Glob` по `.workflow/tickets/**/{TYPE}-{NNN}.md`. Если файл уже существует — **СТОП**: не перезаписывай. Зафиксируй в output: «Тикет {ID} уже существует, пропущен». Возьми следующий свободный номер.
+     2. Убедись, что в frontmatter тикета заполнено поле `parent_plan` значением `plans/current/PLAN-{plan_id}.md`. Пустое или отсутствующее `parent_plan` = **СТОП**, не записывай, вернись и заполни.
    - Сохрани в `.workflow/tickets/backlog/{TYPE}-{NNN}.md`
 
 ### 10. Вывести результат
@@ -117,4 +119,5 @@ created_tickets: IMPL-010, FIX-011
 - [ ] Тикеты не содержат инструкций по управлению workflow
 - [ ] Типы тикетов соответствуют config.yaml
 - [ ] Префикс каждого тикета (в `id` и имени файла) существует в `config.yaml → task_types`
+- [ ] **В каждом созданном тикете заполнено `parent_plan: plans/current/PLAN-{plan_id}.md`** (без исключений; перепроверь `Grep` по созданным файлам — ни одного пустого значения)
 - [ ] Артефакты не ссылаются на `.workflow/` как output-директорию

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

@@ -42,8 +42,13 @@
 
 - [ ] Ожидаемый объём изменений < 200 строк кода?
 - [ ] Ожидаемое время выполнения ≤ 2 часа? Превышение допускается только при доказанной неделимости задачи.
+- [ ] **Число пунктов DoD ≤ 7** (hard-порог машинной проверки `verify-atomicity.js`). Рекомендуемая цель — ≤ 5 (мягкий WARN-порог); 6–7 пунктов допустимы, но считаются предупреждением. **8 и более — FAIL: тикет будет отклонён пайплайном, декомпозиция уйдёт на повторную попытку.**
 
-**Если больше** → ищи границу разбиения: по файлам, по этапам, по подсистемам.
+**Если больше** → ищи границу разбиения: по файлам, по этапам, по подсистемам, **или по группам DoD-пунктов** (каждая независимая группа критериев = отдельный тикет с собственным DoD).
+
+> **⚠️ Evidence для Проверки 5 — обязательно указывать фактическое число пунктов DoD.** Формулировка «DoD содержит N пунктов» с явной цифрой — обязательный элемент evidence-строки. Голый PASS без числа не валиден: именно по этому инварианту падает `verify-atomicity.js`, а не по объёму строк кода или времени выполнения, которые агент оценивает на глаз.
+
+> **⚠️ Пороги в этой проверке и в `verify-atomicity.js` — связанная пара.** Пороги ≤ 5 (WARN), ≤ 7 (FAIL), > 7 (FAIL) должны совпадать с константами `DOD_THRESHOLD_WARN` / `DOD_THRESHOLD_FAIL` в `scripts/verify-atomicity.js`. Если один файл правится — второй обязан быть синхронизирован в той же правке.
 
 ### Проверка 6: Независимая верификация
 
@@ -52,6 +57,24 @@
 
 **Если нет** → это часть более крупной задачи. Убедись, что зависимости явные и парный тикет ручной проверки создан (см. `workflows/decompose.md` шаг 2 → «Парные тикеты ручной проверки»).
 
+### Проверка 7: Один исполнитель (executor-атомарность)
+
+- [ ] Все пункты DoD выполнимы **одним типом тикета** из `config.yaml → task_types` (тот же префикс, что назначен создаваемому тикету)?
+- [ ] Ни один пункт DoD не требует действия, относящегося к ответственности другого типа тикета или к действиям стейкхолдера (git-операции, мерж, деплой, релизные решения)?
+
+**Если нет** → разбей по исполнителю: каждый тип работы = отдельный тикет со своим префиксом, связанный через `dependencies`.
+
+**Критерий проверки:** для каждого пункта DoD задай вопрос — «Если бы этот пункт был единственной задачей, какой тип из `config.yaml → task_types` был бы выбран маршрутизацией на шаге 4 workflow?» Если ответы расходятся между пунктами DoD одного тикета — тикет не executor-атомарен.
+
+**Признаки нарушения:**
+- Пункт DoD описывает действие, для которого в `config.yaml` существует отдельный, более точный тип тикета, чем назначенный текущему.
+- Пункт DoD описывает действие, которое по проектным правилам выполняет стейкхолдер или внешняя стадия пайплайна, а не агент-исполнитель тикета (git-коммиты, пуши, мержи, релизы, ручные ревью).
+- Пункт DoD ссылается на успешное завершение другого тикета того же плана как на условие закрытия текущего (это зависимость, а не критерий готовности).
+
+**Почему это отдельная проверка, а не часть «Одного результата»:** разные пункты DoD могут проверять «одно и то же» семантически, но выполняться разными исполнителями в разных сессиях/стадиях. Кросс-исполнительская зависимость делает тикет невыполнимым за одну сессию — даже если смысловое ядро одно.
+
+**Граничный случай:** если проектный тип тикета явно включает сопутствующее действие в ответственность исполнителя (например, тесты как часть реализации), такой DoD-пункт остаётся внутри одного тикета. Источник правды — описание типа в `config.yaml` и проектный README. Если описание типа неоднозначно — трактуй в пользу разбиения.
+
 ## Правило по умолчанию: при сомнении — разбивай
 
 Если после прохождения чеклиста остаётся сомнение в атомарности — **разбивай тикет**.
@@ -60,7 +83,7 @@
 
 **Критерий «достаточно мелкий»:** тикет, который агент может выполнить линейно, без необходимости принимать стратегические решения о следующем шаге внутри тикета.
 
-**⛔ Антипаттерн «сжатие вместо разбиения».** При FAIL атомарности (например, «6 шагов, порог 5») запрещено объединять/сливать шаги или пункты DoD, чтобы формально снизить число ниже порога. Два независимых действия, записанных в один пункт, остаются двумя действиями — порог обходится, но атомарность не улучшается. Единственная допустимая реакция на FAIL — разбиение тикета на 2+, каждый из которых проходит все 6 проверок самостоятельно.
+**⛔ Антипаттерн «сжатие вместо разбиения».** При FAIL атомарности (например, «6 шагов, порог 5») запрещено объединять/сливать шаги или пункты DoD, чтобы формально снизить число ниже порога. Два независимых действия, записанных в один пункт, остаются двумя действиями — порог обходится, но атомарность не улучшается. Единственная допустимая реакция на FAIL — разбиение тикета на 2+, каждый из которых проходит все 7 проверок самостоятельно.
 
 ## Паттерны разбиения
 
@@ -69,15 +92,17 @@
 | «Реализовать X и Y» | Тикет на X + тикет на Y |
 | «Изменить A.ts, B.ts, C.ts» (несвязанные) | Тикет на каждый модуль |
 | DoD с 3+ несвязанными пунктами | Тикет на каждый пункт |
-| «Добавить функцию + написать тесты + обновить docs» | Функция+тесты = один тикет (связаны), docs = отдельный (если нетривиально) |
+| «Добавить функцию + написать тесты + обновить docs» | Прогоняй Проверку 7 по `config.yaml → task_types`: если реализация и тестирование — разные типы, разбей по исполнителю |
 | «Провести рефакторинг модуля» (> 5 файлов) | По подсистемам или по этапам (extract → rename → cleanup) |
 | Список шагов, где шаги 1-3 независимы | 3 тикета без зависимостей |
+| DoD-пункты требуют разных типов из `config.yaml → task_types` | По типу исполнителя — парные тикеты с `dependencies` |
+| Пункт DoD описывает git-операцию (commit, merge, push, release) | Удалить из DoD — это действие стейкхолдера, не исполнителя |
 
 ## Граничные случаи
 
 | Случай | Решение |
 |--------|---------|
-| Функция + unit-тест к ней | **Один** тикет (тест неотделим от реализации, TDD) |
+| Функция + unit-тест к ней | Определяется Проверкой 7: если в `config.yaml → task_types` реализация и тестирование — один тип, то **один** тикет; если разные (например, есть отдельный QA-тип) — **два** тикета с `dependencies` |
 | Функция + интеграционный тест в отдельном окружении | **Два** тикета (разные executor, разное окружение) |
 | Правка одной строки в 3 файлах | **Один** тикет (если правка семантически едина) |
 | «Обновить все импорты после переименования» | **Один** тикет (механическая операция, один контекст) |
@@ -102,12 +127,13 @@
 | 4. Нет скрытых подзадач | **FAIL** | TC 1-2 независимы от TC 3-4 |
 | 5. Размер | PASS | |
 | 6. Независимая верификация | **FAIL** | TC 1-2 зависят от fix-A, TC 3-4 от fix-B |
+| 7. Один исполнитель | PASS | Все три TC-группы — один тип (ручная проверка) по `config.yaml` |
 
 → Решение: **РАЗБИТЬ на 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.
+Каждый результирующий тикет проходит чеклист → все 7 проверок PASS.
 
 <!-- РАСШИРЕНИЕ: добавляй паттерны и граничные случаи ниже -->

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

@@ -37,8 +37,32 @@
 ## Источник допустимых значений
 
 Перечень капабилити-ключей определяется конфигурацией проекта —
-`agents.*.capabilities` в pipeline-конфиге. Сверяйся с фактическим
-конфигом проекта: там указано, какие capability задекларированы и у
-каких агентов они доступны. Не изобретай ключи — если нужная
-возможность не описана в конфиге, тикет всё равно не сможет её
-потребовать.
+`agents.*.capabilities` в pipeline-конфиге. **Реестр ключей замкнутый:** capability существует только если она перечислена в `agents.*.capabilities` хотя бы у одного агента. Ключи, отсутствующие в реестре, — **несуществующие**, и тикет с таким ключом физически не может быть исполнен (блокируется по `no_capable_agent`).
+
+### ⛔ Обязательная процедура перед заполнением `required_capabilities`
+
+**Выполняется один раз в начале декомпозиции плана**, до создания первого тикета:
+
+1. **Прочитай** `.workflow/config/pipeline.yaml` (или аналогичный pipeline-конфиг проекта — путь см. в SKILL.md / конфигурации).
+2. **Выпиши** union всех значений `agents.*.capabilities` в явный список. Это **единственный допустимый словарь** для поля `required_capabilities` на всю декомпозицию. Зафиксируй список текстом в рассуждении перед шагом 9.1 — без фиксации шаг считается невыполненным.
+3. При назначении `required_capabilities` каждому тикету **сверяйся только с этим выписанным списком**. Любой ключ, которого в списке нет, — изобретённый.
+
+### ⛔ Антипаттерн: изобретение ключей по предметной области
+
+Типичная ошибка: агент назначает capability, описывающую **предметную область задачи** (язык программирования, тип проекта, фреймворк, подсистему), а не возможность агента-исполнителя.
+
+**Критерий различения:**
+- Capability — свойство **агента** («агент умеет X»). Пример: `multimodal` — агент умеет читать изображения.
+- Предметная область — свойство **задачи** («задача про X»). Пример: «задача про TypeScript-код» — это описание задачи, а не требование к агенту.
+
+Если ты хочешь выразить «задача предметной области Y» — это **не capability**. Это просто описание задачи; оно уже содержится в `title`, `description`, `context.files`. Не дублируй его в `required_capabilities`.
+
+**Правило:** прежде чем записать ключ в `required_capabilities`, спроси себя: «Этот ключ есть в union'е, который я выписал из pipeline.yaml?» Если нет — **не записывай**, даже если он «хорошо описывает задачу».
+
+### Классы изобретений (для распознавания, не как запрет)
+
+Закрытого списка изобретённых ключей не существует — статус ключа определяется только его наличием/отсутствием в union'е реестра **текущего проекта**. Один и тот же ключ может быть валидным в одном проекте и изобретённым в другом. Всё решает сверка со словарём из пункта «Обязательная процедура».
+
+Классы-маркеры, по которым стоит насторожиться и **перепроверить словарь**, прежде чем записывать ключ: имена языков программирования, имена платформ/типов проектов, имена подсистем или аспектов (локализация, стилизация, тестирование). Эти имена описывают задачу, а не способность агента, и в подавляющем большинстве проектов в реестре отсутствуют — но если в конкретном проекте такой ключ всё же задекларирован у агентов, он валиден. Решающий критерий — строго словарь, а не класс имени.
+
+Если реестр проекта не содержит ключа, подходящего по смыслу, — поле `required_capabilities` для такого тикета остаётся пустым или содержит только ключи из словаря.

package/src/skills/decompose-plan/knowledge/human-task-rules.md

@@ -4,6 +4,12 @@
 
 ## Когда задача = HUMAN
 
+HUMAN-тикет создаётся только при выполнении **обоих** условий:
+1. Агент физически не может выполнить задачу (нет инструмента, доступа, прав).
+2. Задача подпадает под один из критериев таблицы ниже (HUMAN-семантика).
+
+Недоступность агенту без HUMAN-семантики → задача **не HUMAN**, а «вне scope декомпозиции» (тикет не создаётся, действие за стейкхолдером вне пайплайна). См. `workflows/decompose.md` шаг 3.
+
 | Критерий | Примеры |
 |----------|---------|
 | Требует аутентификации в приватных сервисах | Вход в CRM, аналитику, платёжные системы |
@@ -12,6 +18,15 @@
 | Доступ к приватным данным | Персональные данные клиентов, NDA-защищённые материалы |
 | Оплата/финансовые транзакции | Подключение billing, оплата подписок |
 
+**Что НЕ HUMAN (типичные ошибки маршрутизации):**
+
+| Ошибочно | Правильная категория |
+|----------|----------------------|
+| Git-операции проекта (commit, push, merge, tag, release) | Вне scope декомпозиции — стейкхолдер выполняет вне пайплайна |
+| Запуск CI/CD, триггер деплоя через стандартные инструменты | Вне scope декомпозиции |
+| Прогон существующей команды (тест, линт, билд), которую агент может выполнить сам | Автономная → тип по маршрутизации шага 4 |
+| Создание тикета на «ручной коммит после выполнения всех IMPL» | Вне scope — коммит не является задачей плана |
+
 ## Обязательные поля HUMAN-тикета
 
 | Поле | Требование |