workflow-ai 1.0.64 → 1.0.66

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-тикета
 
 | Поле | Требование |

package/src/skills/decompose-plan/tests/cases/TC-DECOMPOSE-PLAN-004/current/claude-sonnet/trial-1.md

@@ -0,0 +1,55 @@
+---
+
+## Декомпозиция выполнена
+
+### Анализ плана
+
+DoD плана содержит 4 пункта. Проверка 7 (executor-атомарность) против `config.yaml → task_types`:
+
+| DoD-пункт | Тип исполнителя | Решение |
+|-----------|----------------|---------|
+| `buildTargetPrompt()` реализована | IMPL | → тикет IMPL-043 |
+| Юнит-тест TC-PROMPT-001 написан и зелёный | QA (отдельный тип) | → тикет QA-090 |
+| README обновлён разделом про prompt assembly | DOCS (отдельный тип) | → тикет DOCS-006 |
+| Коммит `feat(runner): buildTargetPrompt создан` | git-операция стейкхолдера | ❌ тикет не создаётся |
+
+### Созданные тикеты
+
+| ID | Тип | Название | Зависимости |
+|----|-----|----------|-------------|
+| IMPL-043 | impl | Реализовать функцию buildTargetPrompt() в run-skill-tests.js | — |
+| QA-090 | qa | Написать юнит-тест TC-PROMPT-001 для buildTargetPrompt() | IMPL-043 |
+| DOCS-006 | docs | Обновить README разделом про prompt assembly | — |
+
+### Рекомендации для следующего плана (вне scope)
+
+- Создание git-коммита `feat(runner): buildTargetPrompt` — причина: git-операции выполняет стейкхолдер, а не агент-исполнитель. Коммит создаётся стейкхолдером после прохождения QA-090 и DOCS-006.
+
+---
+
+```
+---RESULT---
+status: success
+tickets_created:
+  - id: IMPL-043
+    path: .workflow/tickets/backlog/IMPL-043.md
+    type: impl
+    title: "Реализовать функцию buildTargetPrompt() в run-skill-tests.js"
+    dependencies: []
+  - id: QA-090
+    path: .workflow/tickets/backlog/QA-090.md
+    type: qa
+    title: "Написать юнит-тест TC-PROMPT-001 для buildTargetPrompt()"
+    dependencies: [IMPL-043]
+  - id: DOCS-006
+    path: .workflow/tickets/backlog/DOCS-006.md
+    type: docs
+    title: "Обновить README разделом про prompt assembly"
+    dependencies: []
+tickets_skipped:
+  - reason: "git-операция (коммит) — выполняет стейкхолдер, не агент"
+    source: "DoD: Коммит feat(runner): buildTargetPrompt создан"
+out_of_scope:
+  - "Создание git-коммита feat(runner): buildTargetPrompt — git-операции выполняет стейкхолдер"
+---RESULT---
+```

package/src/skills/decompose-plan/tests/cases/TC-DECOMPOSE-PLAN-004/current/claude-sonnet/trial-2.md

@@ -0,0 +1,49 @@
+Один файл — коллизий нет.
+
+---
+
+## Итог декомпозиции
+
+Создано **3 тикета** в `.workflow/tickets/backlog/`:
+
+| Тикет | Тип | Executor | Приоритет | Зависимости | DoD (дословно из плана) |
+|-------|-----|----------|-----------|-------------|------------------------|
+| IMPL-001 | impl | agent | 2 (High) | — | Функция buildTargetPrompt() реализована в src/scripts/run-skill-tests.js |
+| QA-001 | qa | agent | 2 (High) | IMPL-001 | Юнит-тест TC-PROMPT-001 написан и зелёный |
+| DOCS-001 | docs | agent | 3 (Medium) | — | README обновлён разделом про prompt assembly |
+
+**Цепочка:** IMPL-001 → QA-001; DOCS-001 параллельно IMPL-001.
+
+**Исключено из DoD всех тикетов:** «Коммит feat(runner): buildTargetPrompt создан» — git-операция стейкхолдера, не агента-исполнителя (Проверка 7 executor-атомарности; git-операции не соответствуют HUMAN-семантике → тикет не создаётся, действие вне scope декомпозиции).
+
+---
+
+### Рекомендации для следующего плана (вне scope)
+
+- Создать `../shared/README.md` с реестром observable-инвариантов — причина: отсутствие реестра делает невозможным применение Условий Б и В (парные тикеты ручной проверки по observable-зоне) при декомпозиции будущих планов.
+
+---
+
+```
+---RESULT---
+status: default
+tickets_created:
+  - .workflow/tickets/backlog/IMPL-001.md
+  - .workflow/tickets/backlog/QA-001.md
+  - .workflow/tickets/backlog/DOCS-001.md
+decomposition_summary:
+  plan_dod_items: 4
+  tickets_created: 3
+  git_ops_excluded: 1
+  breakdown:
+    DoD-1 (реализация функции) → IMPL-001
+    DoD-2 (юнит-тест TC-PROMPT-001) → QA-001 (depends: IMPL-001)
+    DoD-3 (README раздел) → DOCS-001
+    DoD-4 (коммит) → ИСКЛЮЧЁН (git-операция стейкхолдера, Проверка 7 executor-атомарности)
+ids_allocated_from:
+  IMPL: 1
+  QA: 1
+  DOCS: 1
+note: "id_ranges_json не передан — инфраструктурная ошибка стадии allocate-ticket-ids. Нумерация начата с 001: все поддиректории .workflow/tickets/ пусты, коллизий нет."
+---RESULT---
+```

package/src/skills/decompose-plan/tests/cases/TC-DECOMPOSE-PLAN-004/current/claude-sonnet/trial-3.md

@@ -0,0 +1,49 @@
+По одному совпадению для каждого тикета — коллизий нет.
+
+---
+
+## Итог декомпозиции
+
+Создано **3 тикета** в `.workflow/tickets/backlog/`:
+
+| Тикет | Тип | Executor | Приоритет | Зависимости | DoD (дословно из плана) |
+|-------|-----|----------|-----------|-------------|------------------------|
+| IMPL-1 | impl | agent | 2 (high) | — | Функция buildTargetPrompt() реализована в src/scripts/run-skill-tests.js |
+| QA-1 | qa | agent | 2 (high) | IMPL-1 | Юнит-тест TC-PROMPT-001 написан и зелёный |
+| DOCS-1 | docs | agent | 3 (medium) | — | README обновлён разделом про prompt assembly |
+
+**Цепочка:** IMPL-1 → QA-1 (DOCS-1 параллельно)
+
+**Исключено из DoD всех тикетов:** «Коммит feat(runner): buildTargetPrompt создан» — git-операция проекта, выполняется стейкхолдером вне пайплайна. Двухступенчатая проверка HUMAN: агент не может (условие 1 — да), но HUMAN-семантика из `knowledge/human-task-rules.md` не подтверждена (условие 2 — нет). Тикет **не создаётся**, тип HUMAN не назначается.
+
+---
+
+### Рекомендации для следующего плана (вне scope)
+
+- Создать `../shared/README.md` с реестром observable-инвариантов — причина: отсутствие реестра делает невозможным применение Условий Б и В (парные тикеты ручной проверки по observable-зоне) при декомпозиции будущих планов.
+
+---
+
+```
+---RESULT---
+status: default
+tickets_created:
+  - .workflow/tickets/backlog/IMPL-1.md
+  - .workflow/tickets/backlog/QA-1.md
+  - .workflow/tickets/backlog/DOCS-1.md
+decomposition_summary:
+  plan_dod_items: 4
+  tickets_created: 3
+  git_ops_excluded: 1
+  breakdown:
+    DoD-1 (реализация функции) → IMPL-1
+    DoD-2 (юнит-тест TC-PROMPT-001) → QA-1 (depends: IMPL-1)
+    DoD-3 (README раздел) → DOCS-1
+    DoD-4 (коммит) → ИСКЛЮЧЁН (git-операция стейкхолдера, Проверка 7, вне scope декомпозиции)
+ids_allocated_from:
+  IMPL: 1
+  QA: 1
+  DOCS: 1
+note: "id_ranges_json не был передан — инфраструктурная ошибка стадии allocate-ticket-ids. Нумерация начата с 1, так как .workflow/tickets/ полностью пуст."
+---RESULT---
+```