workflow-ai 1.1.0 → 1.2.1

package/src/skills/decompose-plan/tests/cases/TC-DECOMPOSE-PLAN-006-dod-threshold.yaml

@@ -1,72 +0,0 @@
-id: TC-DECOMPOSE-PLAN-006
-title: "Декомпозитор соблюдает порог DoD ≤ 7 пунктов (Проверка 5) — разбивает тикет с толстым DoD"
-origin:
-  chg: []
-  incidents:
-    - "PulseProxy PLAN-014 (2026-04-20): decompose-plan на первой попытке создал IMPL-043 (8 пунктов DoD) и IMPL-045 (9 пунктов DoD). verify-atomicity.js FAIL → вторая декомпозиция (+8:36 мин). Root cause: Проверка 5 в atomicity-checklist.md упоминала только объём кода и время, но не число пунктов DoD, тогда как скрипт меряет именно этот инвариант (DOD_THRESHOLD_FAIL=7)."
-  principle: "Синхронизация инвариантов между чеклистом атомарности и verify-atomicity.js"
-  backlog_sources:
-    - ".workflow/coach-backlog.yaml"
-tags: [atomicity, dod, threshold, anti-pattern]
-severity: high
-
-scenario:
-  system_prompt_file: "../../SKILL.md"
-  extra_instructions: |
-    Декомпозируй следующую задачу плана на тикеты. Типы тикетов в проекте (из
-    `config.yaml → task_types`): IMPL (реализация), QA (автотесты), DOCS
-    (документация), ADMIN (инфраструктурные операции).
-
-    Перед созданием каждого тикета применяй чеклист атомарности (7 проверок).
-    Особое внимание — Проверке 5 «Оценка размера»: hard-порог verify-atomicity.js
-    по числу пунктов DoD = 7 (FAIL при >7). Если для задачи естественно выходит
-    больше 7 критериев готовности — это сигнал на разбиение, а не на сжатие
-    пунктов.
-  inputs:
-    - kind: inline
-      as: plan_content
-      content: |
-        Задача: Реализовать компонент выбора прокси по умолчанию (select-default-proxy-modal)
-          DoD:
-            - Файл src/popup/select-default-proxy-modal.ts создан по образцу public-proxies-modal.ts через ModalHelper
-            - Функция showSelectDefaultProxyModal(proxies) экспортируется и резолвит id выбранного прокси
-            - Закрытие крестиком или Esc резолвит null
-            - Edge case: при пустом списке прокси модалка не рендерит DOM и резолвит null сразу
-            - Заголовок модалки берётся из I18n.getMessage('selectDefaultProxyTitle')
-            - Модалка НЕ вызывает Storage.setDefaultProxy() внутри — запись в storage снаружи
-            - Модалка НЕ читает прокси из storage — принимает готовый список
-            - Каждый элемент списка отображает имя, host:port и флаг страны (если есть)
-
-assertions:
-  static:
-    - kind: skill_contains
-      file: "knowledge/atomicity-checklist.md"
-      pattern: "Число пунктов DoD"
-      reason: "В Проверке 5 должен быть явный пункт про число пунктов DoD."
-    - kind: skill_contains
-      file: "knowledge/atomicity-checklist.md"
-      pattern: "verify-atomicity.js"
-      reason: "Явная ссылка на скрипт, чтобы связь порогов была видна."
-    - kind: skill_contains
-      file: "knowledge/atomicity-checklist.md"
-      pattern: "7"
-      reason: "Числовое значение порога должно присутствовать в чеклисте."
-
-  deterministic:
-    - kind: output_matches
-      regex: "(5\\. )?Размер[\\s\\S]{0,400}(DoD|пункт)"
-      reason: "Проверка 5 должна явно упомянуть DoD-пункты в inline-таблице чеклиста."
-    - kind: output_does_not_contain
-      values: ["DoD содержит 8 пунктов", "DoD содержит 9 пунктов", "DoD содержит 10 пунктов"]
-      reason: "Ни один из созданных тикетов не должен декларировать DoD > 7 пунктов — это регрессия, verify-atomicity.js даст FAIL."
-
-  rubric:
-    - kind: llm_judge
-      rubric_file: "../rubrics/dod-threshold.md"
-      criterion: "Разбил ли агент задачу с 8+ пунктами DoD на тикеты с ≤ 7 пунктами каждый, и зафиксировал ли цифру числа пунктов DoD в evidence Проверки 5?"
-      pass_threshold: 4
-      trials: 3
-      aggregate: majority
-
-execution:
-  timeout_s: 2400

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

@@ -1,45 +0,0 @@
-version: 1
-skill: decompose-plan
-generated_at: "2026-04-17"
-
-execution:
-  target_agents:
-    - claude-sonnet
-    - kilo-glm
-    - kilo-minimax
-    - kilo-deepseek
-  judge_agent: claude-opus
-  default_timeout_s: 2400
-  baseline_ref: origin/main
-
-cases:
-  - id: TC-DECOMPOSE-PLAN-001
-    file: cases/TC-DECOMPOSE-PLAN-001-atomicity-no-1to1.yaml
-    origin_chg: [CHG-053, CHG-054, CHG-037, CHG-103, CHG-104]
-    tags: [atomicity, decomposition, anti-pattern]
-    severity: high
-  - id: TC-DECOMPOSE-PLAN-002
-    file: cases/TC-DECOMPOSE-PLAN-002-get-next-id-mandatory.yaml
-    origin_chg: [CHG-029, CHG-036]
-    tags: [id-generation, script-usage]
-    severity: high
-  - id: TC-DECOMPOSE-PLAN-003
-    file: cases/TC-DECOMPOSE-PLAN-003-verbatim-dod-transfer.yaml
-    origin_chg: [CHG-040]
-    tags: [dod-transfer, verbatim]
-    severity: high
-  - id: TC-DECOMPOSE-PLAN-004
-    file: cases/TC-DECOMPOSE-PLAN-004-executor-atomicity.yaml
-    origin_chg: []
-    tags: [atomicity, executor]
-    severity: high
-  - id: TC-DECOMPOSE-PLAN-005
-    file: cases/TC-DECOMPOSE-PLAN-005-capabilities-registry.yaml
-    origin_chg: [CHG-076]
-    tags: [capabilities, pipeline-contract, anti-pattern]
-    severity: critical
-  - id: TC-DECOMPOSE-PLAN-006
-    file: cases/TC-DECOMPOSE-PLAN-006-dod-threshold.yaml
-    origin_chg: []
-    tags: [atomicity, dod, threshold]
-    severity: high

package/src/skills/decompose-plan/tests/rubrics/atomicity-no-1to1.md

@@ -1,21 +0,0 @@
-# Rubric: Декомпозитор применяет чеклист атомарности, не маппит 1:1
-
-## Критерий
-
-**Разбил ли агент составную задачу плана на несколько атомарных тикетов, применив чеклист атомарности, и явно отказался ли от маппинга «одна задача плана = один тикет»?**
-
-Агент должен:
-1. Распознать в задаче плана несколько разных объектов работы или результатов (дефект А, дефект Б, smoke-тест — это три независимых артефакта).
-2. Применить чеклист атомарности к задаче плана до создания тикетов (пройти по проверкам либо явно сослаться на чеклист).
-3. Разбить составную задачу на отдельные атомарные тикеты — так, чтобы каждый тикет имел один объект работы и один DoD-пункт.
-4. Не допускать формулировок «1 задача плана = 1 тикет», «маппинг 1:1», а также объединения нескольких дефектов в один тикет «для удобства».
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Агент явно разбил составную задачу на атомарные тикеты (как минимум по одному на каждый дефект и smoke-тест), прошёл по чеклисту атомарности и обосновал разбиение. |
-| **4** | Разбиение выполнено корректно, но чеклист атомарности не отработан явно. |
-| **3** | Часть составной задачи разбита, часть объединена в один тикет без доказательства неделимости. |
-| **2** | Агент создал один тикет на всю составную задачу, сослался на «удобство» или «связанность». |
-| **1** | Применён маппинг 1:1 («одна задача плана = один тикет») без проверки атомарности. |

package/src/skills/decompose-plan/tests/rubrics/capabilities-registry.md

@@ -1,21 +0,0 @@
-# Rubric: Декомпозитор сверяет `required_capabilities` с реестром из pipeline-конфига
-
-## Критерий
-
-**Выписал ли агент явный `capabilities_registry` из `agents.*.capabilities` pipeline-конфига проекта до создания тикетов, и назначил ли `required_capabilities` строго из этого реестра — не изобретая ключей, описывающих предметную область задачи (язык, платформу, подсистему)?**
-
-Агент должен:
-1. До создания первого тикета прочитать pipeline-конфиг проекта (путь стандартно — `.workflow/config/pipeline.yaml`, либо как указано в конфиге проекта) и выписать в рассуждении явным списком union всех значений `agents.*.capabilities`. Эта выписка — единственный допустимый словарь для поля `required_capabilities` на всю декомпозицию.
-2. При заполнении `required_capabilities` каждого тикета сверять каждый ключ с этим словарём. Ключ, которого в словаре нет, — изобретённый, не записывается.
-3. Не подменять `required_capabilities` описанием предметной области задачи (имена языков программирования, типов проектов, платформ, подсистем), если эти имена не задекларированы в реестре.
-4. Если ни один ключ реестра не применим — оставить поле пустым, а не изобретать ключ «по смыслу».
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Агент явно выписал `capabilities_registry` из конфига до создания тикетов, у каждого созданного тикета `required_capabilities` — строго подмножество реестра (либо пусто). Изобретённых ключей нет. |
-| **4** | Реестр выписан неявно (агент перечислил допустимые ключи в рассуждении, но без явного названия «capabilities_registry»); все тикеты содержат только ключи из реестра или пустое поле. |
-| **3** | Реестр не выписан, но де-факто все `required_capabilities` ограничены ключами из реестра — совпадение по результату, не по процедуре. |
-| **2** | В одном или нескольких тикетах встречается хотя бы один изобретённый ключ (описание языка/платформы/подсистемы, отсутствующее в реестре). |
-| **1** | Поле `required_capabilities` массово заполнено именами предметной области (язык, фреймворк, платформа, аспект) без какой-либо сверки с реестром. |

package/src/skills/decompose-plan/tests/rubrics/dod-threshold.md

@@ -1,21 +0,0 @@
-# Rubric: Декомпозитор соблюдает порог числа пунктов DoD (Проверка 5)
-
-## Критерий
-
-**Если задача плана требует больше 7 пунктов DoD в одном тикете, разбил ли агент тикет на 2+ атомарных тикета так, чтобы каждый результирующий тикет содержал ≤ 7 пунктов DoD? И явно ли зафиксирована в inline-таблице чеклиста (Проверка 5) фактическая цифра числа пунктов DoD как evidence?**
-
-Агент должен:
-1. При декомпозиции задачи, естественно порождающей длинный DoD (8+ пунктов), распознать это на Проверке 5 и разбить тикет по группам независимых DoD-пунктов.
-2. Ни один из финально созданных тикетов не должен содержать > 7 пунктов DoD (hard-порог `verify-atomicity.js` → иначе FAIL → повторный прогон декомпозиции → потеря 5-10 минут пайплайна).
-3. Evidence-строка для Проверки 5 в inline-таблице должна содержать явное число пунктов DoD (например, «DoD содержит 5 пунктов, все проверяют создание компонента»), а не только «PASS».
-4. Если исходная задача слита из независимых групп критериев — каждая группа → отдельный тикет со своим префиксом (если тип разный) или своим суффиксом/номером (если тип один).
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Агент явно обнаружил на Проверке 5 превышение порога 7, разбил тикет на 2+ с DoD ≤ 7 у каждого. Evidence-строка содержит цифру числа пунктов. |
-| **4** | Все созданные тикеты содержат DoD ≤ 7; разбиение выполнено, но явное обнаружение «превышен порог» в рассуждении не зафиксировано. |
-| **3** | Один из тикетов имеет 8+ пунктов DoD (или агент оставил задачу в одном толстом тикете). Evidence-строка отсутствует или не содержит цифру. |
-| **2** | Несколько тикетов имеют 8+ пунктов DoD, разбиения по DoD нет совсем. |
-| **1** | Агент собрал весь DoD задачи в один тикет без прогона Проверки 5 в явном виде. |

package/src/skills/decompose-plan/tests/rubrics/executor-atomicity.md

@@ -1,21 +0,0 @@
-# Rubric: Декомпозитор применяет executor-атомарность (Проверка 7)
-
-## Критерий
-
-**Разбил ли агент задачу на отдельные тикеты, если пункты DoD требуют разных типов исполнителя по `config.yaml → task_types`, и удалил ли из DoD пункты, выполняемые стейкхолдером (git-операции)?**
-
-Агент должен:
-1. Пройти по пунктам DoD задачи плана и для каждого определить тип тикета из `config.yaml → task_types`, который был бы создан, если бы этот пункт был единственной задачей.
-2. Если ответы расходятся между пунктами одного тикета — разбить на парные тикеты со своими префиксами и `dependencies`.
-3. Git-операции (commit, merge, push, release) — **вне scope декомпозиции**: не попадают в DoD ни одного тикета **и** не заворачиваются в отдельный HUMAN-тикет. Двухступенчатая проверка HUMAN из `workflows/decompose.md` шаг 3: недоступность агенту — необходимое, но не достаточное условие HUMAN; git-операция недоступна агенту, но не подпадает под HUMAN-семантику из `knowledge/human-task-rules.md`.
-4. Не допускать пунктов DoD, ссылающихся на успешное завершение другого тикета того же плана как на критерий готовности (это зависимость, а не DoD).
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Агент применил Проверку 7 executor-атомарности явно: каждый пункт DoD прошёл маршрутизацию по типу, разнотипные пункты вынесены в парные тикеты, git-операции полностью выпали из scope (нет ни в DoD, ни как отдельный HUMAN-тикет), пункты-зависимости переведены в `dependencies`. |
-| **4** | Executor-атомарность соблюдена в результате, git-операции выпали из scope, но Проверка 7 не отработана явно в inline-таблице чеклиста. |
-| **3** | Git-операции убраны из DoD, но обёрнуты в отдельный HUMAN-тикет (fallback-антипаттерн «не может агент → HUMAN» без проверки HUMAN-семантики). |
-| **2** | Все пункты DoD оставлены в одном тикете, либо git-операции сохранены в DoD. |
-| **1** | Явное указание «один тикет удобнее» без прогона чеклиста; DoD смешивает реализацию, тестирование, документирование и коммит. |

package/src/skills/decompose-plan/tests/rubrics/get-next-id-mandatory.md

@@ -1,21 +0,0 @@
-# Rubric: Декомпозитор использует машинную аллокацию ID вместо ручного поиска
-
-## Критерий
-
-**Получил ли агент ID тикетов через машинную аллокацию (из `id_ranges_json` / скрипта `get-next-id.js`) вместо ручного сканирования существующих тикетов?**
-
-Агент должен:
-1. Использовать ID, выделенные инфраструктурой (переданные через контекст от вышестоящей стадии либо полученные вызовом скрипта аллокации ID).
-2. Не вычислять «максимальный существующий номер» самостоятельно — не сканировать директории тикетов вручную для определения следующего ID.
-3. Не изобретать номера без подтверждения уникальности через машинную проверку.
-4. При объяснении своих действий явно упоминать, что ID получены от инфраструктуры, а не определены вручную.
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Агент использует только машинно-выделенные ID, явно ссылается на источник машинной аллокации (контекст от инфраструктуры или скрипт аллокации), отказывается от ручного поиска. |
-| **4** | Агент использует машинную аллокацию, но явной ссылки на источник ID нет. |
-| **3** | Агент упоминает машинную аллокацию как «один из способов», допускает и ручной вариант. |
-| **2** | Агент смешивает ручной поиск с машинной аллокацией («посмотрел archive/, потом сверился со скриптом»). |
-| **1** | Агент вычисляет ID вручную — сканирует директории, берёт «максимум + 1», либо задаёт ID произвольно. |

package/src/skills/decompose-plan/tests/rubrics/verbatim-dod-transfer.md

@@ -1,21 +0,0 @@
-# Rubric: Декомпозитор переносит DoD из плана дословно без смягчения
-
-## Критерий
-
-**Перенёс ли агент формулировку DoD из плана в тикет дословно, сохранив все семантически значимые квалификаторы, и воздержался ли от перефразировки/смягчения?**
-
-Агент должен:
-1. Скопировать формулировку критерия из плана в DoD тикета буква-в-букву (включая специфические термины: «визуально соответствует макету Figma», названия артефактов, числовые параметры).
-2. Не заменять точные термины на общие («визуально соответствует макету Figma» → «соответствует дизайну» недопустимо).
-3. Не выбрасывать уточнения («макету Figma» → «макету» недопустимо).
-4. Если критерий плана не имеет формальной проверки, явно зафиксировать это в тикете (например, добавить шаг manual verification), но исходную формулировку не модифицировать.
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | DoD тикета содержит формулировку плана дословно; все уточнения и термины сохранены. |
-| **4** | Формулировка перенесена почти дословно, но есть мелкая стилистическая правка без потери семантики. |
-| **3** | Часть формулировки перенесена дословно, часть перефразирована. |
-| **2** | Формулировка ощутимо смягчена или обобщена (удалены квалификаторы, заменены точные термины). |
-| **1** | DoD полностью перефразирован, от исходной формулировки плана остались только общие понятия. |

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

@@ -1,305 +0,0 @@
-# Воркфлоу: Декомпозиция плана на тикеты
-
-Пошаговый алгоритм превращения высокоуровневого плана в атомарные тикеты.
-
-## Вход
-
-| Параметр | Описание |
-|----------|----------|
-| `plan_path` | Путь к плану (из Instructions промпта) |
-| `id_ranges_json` | **JSON-строка** со стартовыми номерами по префиксам, выделенная стадией `allocate-ticket-ids` до запуска декомпозиции. Формат: `{"PREFIX":N_start,...}`, например `{"QA":26,"HUMAN":2,"IMPL":12}`, где `N_start` — первый свободный номер для данного префикса. Декомпозитор парсит JSON (ментально — формат тривиально читаемый) и дальше работает с картой. Источник нумерации **только этот параметр** — декомпозитор не вызывает `get-next-id.js` и не сканирует `.workflow/tickets/` самостоятельно. Передача именно JSON-строки, а не объекта — техническое ограничение runner'а: при подстановке `$context.*` в инструкцию объекты превращаются в `[object Object]`, а скалярные строки подставляются корректно. |
-
-## Шаги
-
-### 1. Прочитать план
-
-```
-Путь: .workflow/plans/current/PLAN-{NNN}.md
-```
-
-Извлечь:
-- Список высокоуровневых задач
-- Зависимости между ними
-- Приоритеты
-- Контекст проекта
-- Секции «Включено в scope» и «Исключено из scope»
-
-**⛔ Не сканируй папку `plans/current/`.** Открой только файл, указанный в Instructions.
-
-### 2. Для каждой задачи определить тикеты
-
-→ Загрузи `knowledge/atomicity-checklist.md`
-
-**⛔ Задача плана ≠ тикет.** Задача плана — это кандидат на разбиение, а не готовый тикет. Одна задача плана может (и часто должна) превратиться в 2+ тикетов. Количество тикетов ≥ количества задач плана. Маппинг «1 задача = 1 тикет» — антипаттерн: он означает, что чеклист атомарности не был применён, а задачи плана были просто переформатированы в шаблон тикета.
-
-**ОБЯЗАТЕЛЬНО** для каждого тикета-кандидата — чеклист атомарности (7 проверок). Если хотя бы одна проверка не пройдена — разбей тикет по паттернам из чеклиста.
-
-**⛔ Единственная допустимая реакция на FAIL — разбиение на 2+ тикетов.** Объединение, сжатие или слияние шагов/пунктов внутри тикета для формального снижения числа ниже порога — **запрещено**. Такая стратегия не делает тикет атомарнее — она маскирует неатомарность, скрывая независимые действия внутри одного пункта. Если verify-atomicity вернул FAIL (например, «6 шагов, порог 5»), ответ — разделить тикет на два, а не объединить шаги 4 и 5 в один.
-
-**⛔ Обязательная фиксация результата чеклиста.** Перед записью каждого тикета в файл выпиши inline-таблицу результатов 7 проверок атомарности:
-
-```
-Тикет-кандидат: «{title}»
-| Проверка | Результат | Если FAIL — действие |
-|----------|-----------|----------------------|
-| 1. Одна задача | PASS/FAIL | ... |
-| 2. Один объект | PASS/FAIL | ... |
-| 3. Один результат | PASS/FAIL | ... |
-| 4. Нет скрытых подзадач | PASS/FAIL | ... |
-| 5. Размер | PASS/FAIL | ... |
-| 6. Независимая верификация | PASS/FAIL | ... |
-| 7. Один исполнитель | PASS/FAIL | ... |
-→ Решение: СОЗДАТЬ / РАЗБИТЬ на N тикетов
-```
-
-Если хотя бы одна проверка = FAIL → тикет **не создаётся** в текущем виде. Разбей по паттернам из чеклиста и повтори проверку для каждого результирующего тикета. Таблица без FAIL → тикет можно создавать.
-
-**⛔ Верификация каждого PASS.** Голый PASS без обоснования — невалиден. Для каждой проверки, помеченной PASS, обязательна колонка «Evidence» с **цитатой из содержимого тикета**, подтверждающей результат. Формат расширенной таблицы:
-
-```
-| Проверка | Результат | Evidence / Действие |
-|----------|-----------|---------------------|
-| 1. Одна задача | PASS | Title: «{дословный title}» — один глагол «{глагол}» |
-| 2. Один объект | PASS | Файлы: {список}. Независимых логических блоков: {N}. Критерий: правки блока A не могут быть применены без блока B |
-| 3. Один результат | PASS | DoD содержит {N} пунктов, все проверяют: «{что именно}» |
-| 4. Нет скрытых подзадач | PASS | Шаги: {N}. Зависимость: шаг K требует шаг K-1 (цепочка) |
-```
-
-Если при заполнении evidence обнаруживается, что факты противоречат PASS (например, title содержит 2+ глагола, или шаги параллельны) — **измени результат на FAIL** и разбей тикет. Антипаттерн: написать PASS, потому что «в целом задача одна», проигнорировав конкретные факты (количество глаголов, количество независимых шагов, количество несвязанных DoD-пунктов). Факты первичны — интуиция вторична.
-
-Критерии хорошего тикета:
-- Одна задача (одно действие, один глагол)
-- Один объект изменения (один модуль / подсистема)
-- Один измеримый результат (DoD проверяется за одно действие)
-- Нет скрытых независимых подзадач
-- Объём ≤ 200 строк кода, время ≤ 2 часа (максимум 4)
-- Результат проверяем независимо от других тикетов
-
-**Парные тикеты ручной проверки:**
-
-**Условие А — по содержимому плана:** Для каждой задачи плана проверь: есть ли секция «Верификация» (или аналог: «Проверка», «Acceptance Criteria» с конкретным сценарием)? Если **да** и верификация требует отдельного окружения или действий, недоступных в рамках основного тикета (ручное тестирование, проверка в sandbox, E2E-сценарий) — создай **парный тикет ручной проверки**.
-
-**Условие Б — по затронутым файлам:** Если задача меняет файлы, влияющие на observable поведение продукта — парный тикет создаётся **независимо от** наличия секции «Верификация» в плане. Загрузи `../shared/README.md` и проверь наличие реестра observable-инвариантов (или аналогичного списка observable-зоны / файловых триггеров). Сопоставь файлы, затрагиваемые задачей, с этим реестром; при пересечении — создай парный тикет, явно ссылающийся на конкретные пункты реестра.
-
-**Условие В — массовый рефакторинг:** Если план в сумме затрагивает >2 файлов из observable-зоны проекта **или** модифицирует декларативный manifest продукта, **в дополнение** к парным тикетам создай **один сводный тикет regression sweep** с проходом по полному реестру observable-инвариантов из `../shared/`. Этот тикет — последний в цепочке зависимостей плана (зависит от всех тикетов реализации).
-
-> **Что считать «observable-зоной» и «декларативным manifest»** — определяется **исключительно** проектным `../shared/`. Скил не знает заранее, как устроен продукт, какой файл является его manifest'ом и какие форматы считать declarative. Если в `../shared/` нет реестра observable-инвариантов или списка файловых триггеров для regression sweep — это пробел shared. Сообщи стейкхолдеру об отсутствующем реестре и **не применяй** Условия Б, В, пока shared не дополнен. Не изобретай критерии в workflow декомпозиции.
-
-**Парный тикет (для всех трёх условий) содержит:**
-- `dependencies` на основной тикет
-- Сценарий верификации: либо из плана (Условие А), либо ссылка на конкретные пункты реестра observable-инвариантов из `../shared/` (Условия Б, В)
-- **Тип тикета** — выбрать из `config.yaml → task_types` тот, который в этом проекте соответствует **ручной проверке наблюдаемого поведения** (не review кода, не запуск автотестов). Если такого типа в конфиге нет — это пробел конфига, эскалируй стейкхолдеру. **Не изобретай префикс** (см. шаг 4 этого же workflow).
-- В описании явное требование: «Evidence обязательно из реального runtime продукта (живая среда исполнения, а не изолированный тест конструкторов). Запуск существующих автотестов на те же файлы **не является** evidence ручной проверки — эти тесты уже были зелёными до создания этого тикета, их повторный прогон тавтологичен.»
-
-**Когда НЕ создавать парный тикет ручной проверки:**
-- Верификация — это просто запуск автотестов или проверка сборки **И** задача не затрагивает observable-зону (Условия Б, В не выполнены).
-- Задача — чистый рефакторинг внутренних модулей без изменения публичного API и без изменения observable поведения продукта.
-
-**⛔ Антипаттерн:** одна сводная задача «Ручная проверка задач 1-N» в конце плана, охватывающая несколько независимых observable-областей. Каждая задача с observable эффектом получает **свой** парный тикет рядом, плюс при необходимости — **один** сводный тикет regression sweep для cross-area прохода.
-
-**Условие Г — подготовка тестового окружения:** Если парный тикет ручной проверки требует конкретного состояния среды (наличие данных в определённых статусах, специальная конфигурация, seed-файлы, fixtures), которое не возникает автоматически при обычной работе продукта — создай **prep-тикет** (тип по `config.yaml → task_types` — выбери тот, который соответствует подготовке инфраструктуры или окружения), который:
-- Подготавливает необходимое окружение для тест-сценария
-- Является `dependency` для тикета ручной проверки
-- В DoD описывает конкретное конечное состояние окружения, достаточное для начала проверки
-
-**Критерий:** если тестировщик не может начать проверку сразу после выполнения основных тикетов реализации и должен вручную создавать тестовые данные или конфигурацию — нужен prep-тикет. Если проверяемое поведение наблюдаемо при обычном использовании продукта — prep-тикет не нужен.
-
-### 3. Оценить автономность каждой задачи
-
-→ Загрузи `knowledge/human-task-rules.md`
-
-Маршрутизация — **двухступенчатая проверка**, оба условия обязательны для HUMAN:
-
-1. **Условие недоступности:** агент физически не может выполнить задачу (нет инструмента, нет доступа, нет прав).
-2. **Условие HUMAN-семантики:** задача подпадает под один из критериев таблицы «Когда задача = HUMAN» из `knowledge/human-task-rules.md` (внешние системы с аутентификацией, физические действия, бизнес-решения, приватные данные, финансовые транзакции).
-
-| Категория | Критерий | Действие |
-|-----------|----------|----------|
-| **Полностью автономная** | Агент может выполнить все шаги | `executor_type: agent`, тип по маршрутизации шага 4 |
-| **Полностью ручная** | Оба условия (недоступность **и** HUMAN-семантика) выполнены | Префикс `HUMAN`, `executor_type: human` |
-| **Гибридная** | Часть — агент, часть подпадает под оба условия HUMAN | Разбить на 2 тикета с зависимостью |
-| **Вне scope декомпозиции** | Недоступность агенту **есть**, но HUMAN-семантика **не подтверждена** | Тикет не создаётся; действие выполняется стейкхолдером вне пайплайна; при необходимости — строка в «Рекомендации для следующего плана» |
-
-**⛔ Антипаттерн «fallback в HUMAN»:** получить FAIL на условии 1 (агент не может) и сразу назначить префикс `HUMAN`, не проверив условие 2. Недоступность агенту — необходимое, но не достаточное условие HUMAN. Типичные ошибки маршрутизации: git-операции проекта (commit, push, merge, release, tag), CI/CD-триггеры, ручной деплой через стандартные инструменты стейкхолдера — это **не HUMAN**, потому что не соответствуют HUMAN-семантике из `knowledge/human-task-rules.md`. Они выпадают из scope декомпозиции целиком.
-
-**Как отличить HUMAN от «вне scope»:** задай два вопроса подряд.
-- Вопрос 1: может ли агент технически выполнить это действие сейчас? Если да — категория «автономная», HUMAN не рассматривается.
-- Вопрос 2 (только при «нет» на вопрос 1): задача относится к одному из критериев таблицы «Когда задача = HUMAN»? Если да — HUMAN. Если нет — «вне scope декомпозиции».
-
-### 4. Определить тип каждого тикета
-
-Прочитай актуальные типы из `.workflow/config/config.yaml` → секция `task_types`. Используй **только** префиксы из конфига.
-
-**⛔ ЗАПРЕТ на изобретение префиксов:**
-1. Прочитай все значения `prefix` из `config.yaml → task_types` — это **закрытый список** допустимых префиксов.
-2. Для каждого тикета выбери префикс **только** из этого списка.
-3. Если ни один тип не подходит точно — выбери ближайший по смыслу из существующих в конфиге.
-4. **Никогда** не придумывай префиксы, которых нет в конфиге (даже если они кажутся логичными).
-
-**Валидация перед записью файла:** убедись, что префикс в `id` и имени файла совпадает с одним из значений `prefix` в `config.yaml → task_types`. Если не совпадает — **СТОП**, исправь префикс.
-
-**Маршрутизация по объекту работы:**
-
-| Объект работы | Признак | Тип тикета |
-|---------------|---------|------------|
-| Скилы (`.workflow/src/skills/`) | Создание, правка, аудит SKILL.md, workflows/, knowledge/ | тип скила-улучшителя (см. config.yaml) |
-| Код продукта | Исходный код проекта (src/, lib/, app/) | `impl` / `fix` |
-| Конфигурация workflow | `.workflow/config/`, `.workflow/templates/`, `.workflow/src/scripts/` | `impl` / `admin` |
-| Документация продукта | README.md проекта, docs/ | `docs` |
-
-### 5. Определить зависимости
-
-Для каждого тикета:
-- `dependencies` — задачи, которые должны быть выполнены ДО этой
-- `conditions` — дополнительные условия (дата, файл, одобрение)
-
-Типы условий: `tasks_completed`, `date_after`, `date_before`, `file_exists`, `file_not_exists`, `file_contains`, `manual_approval`.
-
-### 6. Scope-guard
-
-→ Загрузи `knowledge/scope-guard-checklist.md`
-
-**ОБЯЗАТЕЛЬНО** перед созданием каждого тикета — чеклист scope. Тикеты вне scope → секция «Рекомендации для следующего плана».
-
-### 7. Дедупликация
-
-→ Загрузи `algorithms/deduplication.md`
-
-**ОБЯЗАТЕЛЬНО** перед созданием каждого тикета — проверка на дубли во **ВСЕХ** папках `tickets/`.
-
-**Автоматическая проверка скриптом:**
-
-1. Вызови скрипт с параметрами создаваемого тикета:
-   ```bash
-   node .workflow/src/skills/decompose-plan/scripts/check-duplicates.js --title "Заголовок тикета" --scope "Описание scope работы"
-   ```
-2. Прочитай JSON из `---RESULT---` — список кандидатов-дубликатов с процентами совпадения
-3. На основе данных скрипта и алгоритма из `algorithms/deduplication.md` прими финальное решение: **CREATE** / **SKIP** / **OVERRIDE**
-
-> Скрипт — вспомогательный инструмент. Финальное решение всегда за агентом.
-
-### 8. Назначить приоритеты
-
-| Приоритет | Значение |
-|-----------|----------|
-| 1 | Critical — блокирует всё |
-| 2 | High — важно для прогресса |
-| 3 | Medium — стандартная работа |
-| 4 | Low — можно отложить |
-| 5 | Someday — когда-нибудь |
-
-### 9. Создать тикеты
-
-#### 9.A ⛔ СТОП-ГЕЙТ: дословный перенос формулировок критериев из плана (выполняется ДО стоп-гейта 9.B и до любых Write/Edit)
-
-Источник правды для критериев задачи — **план**. При переносе формулировок критериев (Acceptance Criteria, Definition of Done, условия приёмки, перечни проверок) из плана в тикет действует правило **семантической неизменности**:
-
-1. **Смягчающие преобразования запрещены.** Нельзя удалять, перефразировать в сторону ослабления или «подтягивать к общей формулировке» элементы, задающие границу критерия. Элементы, которые составляют смысловое ядро и **обязаны** переноситься в тикет без изменений либо с эквивалентной семантикой:
-   - Отрицания и запреты: обороты вида «не X», «без Y», «кроме Z», «исключая», «не допускается».
-   - Уточнения в скобках и после тире, задающие границу: «(не X)», «(включая Y)», «(за исключением Z)», «— минимум N».
-   - Количественные пороги: «не менее N», «ровно N», «≥ N», «≤ N», «не более N% diff».
-   - Парные ограничения: «X и Y одновременно», «X, но не Y», «только при Z».
-   - Референсы на конкретные артефакты/данные: имена файлов, селекторы, ID элементов, конкретные значения — переносятся дословно.
-2. **Обогащение разрешено.** Тикет может **добавлять** детали, раскрывать контекст, ссылаться на знания проекта, приводить примеры — всё, что усиливает ту же планку. Запрещено только **ослабление**.
-3. **Переформулировка допускается** только при соблюдении теста эквивалентности: новая формулировка в тикете должна **однозначно отвергать** любую ситуацию, которую отвергает формулировка плана. Если существует сценарий, проходящий по тикету, но не проходящий по плану — переформулировка неэквивалентна и запрещена.
-
-**Обязательная процедура diff-а формулировок перед записью тикета:**
-
-Для каждого критерия тикета, соответствующего критерию плана:
-1. Выпиши **дословную** строку критерия из плана (со всеми скобками, тире, отрицаниями, цифрами).
-2. Выпиши **дословную** строку критерия, которую собираешься записать в тикет.
-3. Построчное сопоставление: для каждого элемента из списка выше (отрицания, уточнения, пороги, парные ограничения, референсы) — присутствует ли он в строке тикета?
-4. Если хотя бы один элемент из плана отсутствует в тикете и нет эквивалентной формулировки — **СТОП**: верни уточняющий элемент в тикет дословно. Не продолжай до устранения расхождения.
-5. Если в плане есть элемент, эквивалент которого в тикете спорен, — предпочти **дословный перенос** переформулировке. Дословность никогда не бывает ошибкой; переформулировка — может быть.
-
-**Антипаттерн (тихий семантический drift):** взять длинную формулировку критерия плана, «сгладить» её до короткой «общего смысла» формулировки в тикете, удалив уточнения в скобках или отрицания как «косметику». Это уничтожает отличительный признак, ради которого критерий был сформулирован, и превращает приёмку в тавтологию (исполнитель проверяет ослабленную формулировку и честно рапортует PASS, а реальный критерий плана остаётся невыполненным). Уточнение в скобках/после тире почти никогда не бывает косметикой — это то, ради чего автор плана уточнял критерий.
-
-**Почему это стоп-гейт перед созданием тикетов:** после записи тикета формулировка разойдётся по всей цепочке — исполнитель реализует тесты под ослабленную формулировку, ревьюер принимает результат по ослабленной формулировке, багнутое поведение проходит приёмку. Исправление задним числом требует переоткрытия тикета и частичного перевыполнения — проще один раз свериться перед записью.
-
-#### 9.B ⛔ СТОП-ГЕЙТ: использование `id_ranges` со входа стадии (выполняется до любых Write/Edit)
-
-До создания **любого** файла тикета:
-
-1. Прочитай параметр `id_ranges_json` со входа стадии (см. секцию «Вход»). Это **JSON-строка** вида `{"PREFIX":N_start,...}`, уже выделенная стадией `allocate-ticket-ids` до запуска декомпозиции. **Распарси её** (формат тривиальный — плоский объект со скалярными значениями) и получи карту `id_ranges = { PREFIX: N_start, ... }`. **Ты не вызываешь `get-next-id.js` и не сканируешь `.workflow/tickets/` самостоятельно** — нумерация полностью определена на входе.
-2. Составь множество уникальных префиксов, которые появятся в этой декомпозиции (по результатам шага 4).
-3. Для **каждого** префикса из множества убедись, что он присутствует в распарсенной карте. Если какого-то префикса нет — это **инфраструктурная ошибка** (рассинхрон между `config.yaml → task_types` и результатом маршрутизации на шаге 4, либо сбой стадии `allocate-ticket-ids`, либо `id_ranges_json` пришёл пустым/некорректным JSON). **СТОП**, сообщи о проблеме и не продолжай декомпозицию. **Не изобретай `N_start` самостоятельно и не используй ручной алгоритм как fallback.**
-4. Все тикеты данного префикса в рамках текущей декомпозиции нумеруй **строго последовательно** от `id_ranges[PREFIX]`: первый получает `{PREFIX}-{N_start}`, второй `{PREFIX}-{N_start+1}`, и так далее. **Никогда не начинай нумерацию с 001** и не перезапускай её.
-5. Зафиксируй фактически использованный диапазон в финальном `---RESULT---` стадии в виде секции:
-   ```
-   ids_allocated_from:
-     {PREFIX_A}: {N_start_A}
-     {PREFIX_B}: {N_start_B}
-   ```
-   Значения — те же, что пришли во входном `id_ranges` для использованных префиксов. Эта секция — обязательная часть контракта стадии декомпозиции. Её отсутствие означает, что СТОП-гейт был пропущен, и декомпозиция считается невалидной.
-
-**Почему источник нумерации — входной параметр, а не вызов скрипта внутри декомпозиции:**
-
-- Историческая причина: текстовая норма «вызови `get-next-id.js`» держалась только на дисциплине агента. Fallback-агенты с коротким окном внимания (инцидент 2026-04-08, PLAN-008: fallback qwen после падения Sonnet с 529) её игнорировали и создавали тикеты, начиная с номера 001, порождая коллизии с архивными и завершёнными ID.
-- Архитектурный принцип: решения про ID принимает инфраструктура (отдельная стадия пайплайна), а не агент. Агент-декомпозитор получает готовую карту на входе и физически не может «передумать» или «забыть» — у него нет альтернативы.
-- Коллизия с архивными/завершёнными тикетами становится невозможной **by design**, потому что стадия `allocate-ticket-ids` рекурсивно сканирует все поддиректории `.workflow/tickets/` (включая `archive/`, `done/`, `review/`, `blocked/`) **до** начала декомпозиции.
-
-**Антипаттерн:** «возьму номера из головы, раз скрипт теперь не вызывается напрямую». `id_ranges` — **единственный** допустимый источник. Любое отклонение (включая «начну с 001, потом исправлю») ломает ссылочную целостность: после записи файла ID уже попадает в перекрёстные ссылки (`depends_on`, `parent_plan`, упоминания в плане и отчётах) — переименование становится масштабной правкой с риском рассинхрона.
-
-#### 9.C ⛔ СТОП-ГЕЙТ: выписка реестра `required_capabilities` из конфига (выполняется до любых Write/Edit тикетов)
-
-До создания **любого** файла тикета обязательно выполни процедуру из `knowledge/capabilities.md` → «Обязательная процедура перед заполнением `required_capabilities`»:
-
-1. **Прочитай** pipeline-конфиг проекта (стандартный путь — `.workflow/config/pipeline.yaml`; если в проекте другой — ориентируйся на фактический). Агенты и их capabilities — в секции `agents.*.capabilities`.
-2. **Выпиши в рассуждении явным списком** union всех значений `agents.*.capabilities` из конфига. Например (иллюстрация формата, не значения):
-   ```
-   capabilities_registry: [<ключ_1>, <ключ_2>, ...]
-   ```
-   Конкретные значения берутся **только** из фактического конфига текущего проекта — не из памяти, не из других проектов.
-3. Эта выписка — **единственный допустимый словарь** для поля `required_capabilities` на всю декомпозицию. При заполнении поля на шаге 9.1 каждый ключ должен присутствовать в `capabilities_registry`. Ключ, которого в выписке нет, — изобретённый, его нельзя записывать в тикет.
-
-**Без явной фиксации `capabilities_registry` в рассуждении стоп-гейт считается пропущенным.** Отсутствие выписки = нарушение контракта стадии.
-
-**Почему это стоп-гейт:** тикет с изобретённым capability физически не может быть исполнен — ни один агент не покрывает несуществующий ключ, пайплайн блокирует execute-task по `no_capable_agent`. Цикл retry → blocked расходует слоты попыток и блокирует весь план. Исправление задним числом требует ручной правки тикетов + перезапуска — проще один раз свериться с реестром перед записью.
-
-**Антипаттерн (описание задачи вместо способности агента):** записать в `required_capabilities` ключ, описывающий **предметную область задачи** (язык, платформу, подсистему), а не способность агента-исполнителя. Подробнее см. `knowledge/capabilities.md` → «Антипаттерн: изобретение ключей по предметной области». Критерий отсечения: если ключа нет в `capabilities_registry` — не записывай, как бы хорошо он ни «описывал задачу».
-
-#### 9.1 Создание каждого тикета
-
-Для **каждого** тикета:
-
-1. Прочитай шаблон: `.workflow/templates/ticket-template.md`
-2. ID тикета — **только** из диапазона, полученного на входе стадии через `id_ranges_json` (см. 9.B). План **никогда** не задаёт ID тикетов и не является источником нумерации. Если в плане встретилось что-то похожее на ID (например, `XXX-005`) — это **игнорируется**, трактуется максимум как hint для маппинга «строка плана → тикет», но не как идентификатор.
-
-   > **⛔ Не используй ручной алгоритм как fallback.** Если на входе стадии отсутствует `id_ranges_json`, JSON не парсится, или в распарсенной карте нет нужного префикса — это инфраструктурная ошибка (сбой стадии `allocate-ticket-ids`), а не повод изобретать ID самостоятельно. Сообщи о проблеме и **остановись**.
-
-3. Заполни шаблон, обязательно `parent_plan`
-
-   > **⛔ Структура заголовков тикета должна точно соответствовать шаблону.** Секция DoD обязана быть на уровне `##` (`## Критерии готовности (Definition of Done)` или `## Definition of Done`) и находиться как самостоятельный блок верхнего уровня — **не вкладывай её внутрь другой секции** (`## Детали задачи` и т.п.). Нарушение уровня заголовка (например, `###` вместо `##`) делает тикет невидимым для автоматических проверок пайплайна (verify-artifacts) и приведёт к бесконечному циклу ретраев.
-
-   > **⛔ Валидация `required_capabilities` по реестру (СТОП-гейт на каждый тикет).** Перед записью тикета пройди по каждому ключу, который собираешься положить в `required_capabilities`, и убедись, что он присутствует в `capabilities_registry`, выписанном в 9.C. Если ключа нет в реестре — **не записывай его**: это изобретённый ключ, тикет будет немедленно заблокирован пайплайном по `no_capable_agent`. Допустимые реакции: (а) убрать ключ, если это описание задачи (язык, платформа, подсистема), а не способность агента; (б) заменить на ключ из реестра, если смысл сохраняется; (в) оставить поле `required_capabilities` пустым, если ни один ключ реестра не подходит. Подробности — `knowledge/capabilities.md`.
-
-4. Сохрани в `.workflow/tickets/backlog/{TYPE}-{NNN}.md`
-5. **Пост-валидация уникальности** (обязательно после каждого сохранения):
-   - Выполни `Glob` по `.workflow/tickets/**/{TYPE}-{NNN}.md`
-   - Если найдено **более одного** совпадения → **СТОП**: только что созданный файл коллизирует с существующим (гонка, ручная правка, баг скрипта, пропуск СТОП-гейта). Удали только что созданный файл, вернись к 9.B и перевыдели диапазон заново, повтори с шага 1. Не продолжай декомпозицию, пока коллизия не устранена.
-
-**Правила:**
-- **Все задачи** плана должны получить тикеты (включая отложенные)
-- `output`-артефакты **вне** `.workflow/` — в корневой директории проекта
-- Не указывай инструменты исполнителя — только `required_capabilities`
-
-### 10. Обновить план
-
-Добавь в план ссылки на созданные тикеты.
-
-> **⛔ Не трогай `status` плана.** Декомпозитор **никогда** не устанавливает `status: active` в frontmatter плана. Переключение `status: approved → active` выполняется стадией `verify-atomicity` пайплайна — **только** после успешной машинной проверки атомарности всех созданных тикетов. Если декомпозитор поставит `status: active` здесь, план уйдёт в работу даже при провалившейся атомарности, а тикеты с нарушениями попадут в backlog как готовые к исполнению.
-
-### 11. Вывести результат
-
-```
----RESULT---
-status: default
----RESULT---
-```
-
-## Выход
-
-- Тикеты в `.workflow/tickets/backlog/`
-- Обновлённый план со ссылками
-
-<!-- РАСШИРЕНИЕ: добавляй дополнительные шаги декомпозиции ниже -->