workflow-ai 1.0.62 → 1.0.64

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

@@ -0,0 +1,21 @@
+# 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

@@ -0,0 +1,272 @@
+# Воркфлоу: Декомпозиция плана на тикеты
+
+Пошаговый алгоритм превращения высокоуровневого плана в атомарные тикеты.
+
+## Вход
+
+| Параметр | Описание |
+|----------|----------|
+| `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 тикет» — антипаттерн: он означает, что чеклист атомарности не был применён, а задачи плана были просто переформатированы в шаблон тикета.
+
+**ОБЯЗАТЕЛЬНО** для каждого тикета-кандидата — чеклист атомарности (6 проверок). Если хотя бы одна проверка не пройдена — разбей тикет по паттернам из чеклиста.
+
+**⛔ Единственная допустимая реакция на FAIL — разбиение на 2+ тикетов.** Объединение, сжатие или слияние шагов/пунктов внутри тикета для формального снижения числа ниже порога — **запрещено**. Такая стратегия не делает тикет атомарнее — она маскирует неатомарность, скрывая независимые действия внутри одного пункта. Если verify-atomicity вернул FAIL (например, «6 шагов, порог 5»), ответ — разделить тикет на два, а не объединить шаги 4 и 5 в один.
+
+**⛔ Обязательная фиксация результата чеклиста.** Перед записью каждого тикета в файл выпиши inline-таблицу результатов 6 проверок атомарности:
+
+```
+Тикет-кандидат: «{title}»
+| Проверка | Результат | Если FAIL — действие |
+|----------|-----------|----------------------|
+| 1. Одна задача | PASS/FAIL | ... |
+| 2. Один объект | PASS/FAIL | ... |
+| 3. Один результат | PASS/FAIL | ... |
+| 4. Нет скрытых подзадач | PASS/FAIL | ... |
+| 5. Размер | PASS/FAIL | ... |
+| 6. Независимая верификация | 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`
+
+| Категория | Критерий | Действие |
+|-----------|----------|----------|
+| **Полностью автономная** | Агент может выполнить все шаги | `executor_type: agent` |
+| **Полностью ручная** | Требует действий, недоступных агенту | Префикс `HUMAN`, `executor_type: human` |
+| **Гибридная** | Часть — агент, часть — человек | Разбить на 2 тикета с зависимостью |
+
+### 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.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) и приведёт к бесконечному циклу ретраев.
+
+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/`
+- Обновлённый план со ссылками
+
+<!-- РАСШИРЕНИЕ: добавляй дополнительные шаги декомпозиции ниже -->

package/src/skills/deep-research/README.md

@@ -0,0 +1,36 @@
+# Deep Research — Agent Skill
+
+Агент-исследователь для глубокого анализа тем. Получает задачи на исследование от других скилов и формирует структурированные текстовые отчёты с данными, источниками и выводами.
+
+## Структура
+
+```
+deep-research/
+├── SKILL.md              # Ядро: роль, маршрутизация, принципы
+├── workflows/            # market, competitor, trend, benchmark, technology, custom, base-checklist
+├── knowledge/            # research-methodology, source-evaluation, data-validation, perplexity-config
+├── algorithms/           # source-scoring, synthesis
+└── templates/            # research-report, brief-summary
+```
+
+## Как это работает
+
+1. Любой скил проекта создаёт тикет `RSH-*` с исследовательским вопросом
+2. Deep Research определяет тип (MARKET/COMPETITOR/TREND/BENCHMARK/TECHNOLOGY/CUSTOM)
+3. Загружает соответствующий workflow
+4. Проводит исследование: поиск → фильтрация → анализ → синтез
+5. Формирует отчёт с источниками, уровнями уверенности, выводами
+
+## Как расширять
+
+### Новый тип исследования
+1. Создай файл в `workflows/{type}.md`
+2. Добавь запись в таблицу маршрутизации в `SKILL.md`
+
+### Новый knowledge-модуль
+1. Создай файл в `knowledge/{module}.md`
+2. Добавь запись в таблицу загрузки знаний в `SKILL.md`
+
+### Новый шаблон вывода
+1. Создай файл в `templates/{template}.md`
+2. Добавь запись в таблицу шаблонов в `SKILL.md`

package/src/skills/deep-research/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: deep-research
+description: >
+  Скилл агента-исследователя для workflow-ai. Выполняет глубокий ресерч по заданной
+  теме: собирает данные из интернета, анализирует источники, синтезирует выводы
+  и формирует структурированный текстовый отчёт с исследованием.
+ticket_prefix: RSH
+---
+
+# Deep Research — Agent Skill
+
+## Роль
+
+Ты — исследователь-аналитик системы workflow-ai. Твоя задача — проводить глубокие исследования по заданным темам, собирать и верифицировать данные из множества источников, анализировать найденное и формировать структурированные текстовые отчёты с выводами и рекомендациями.
+
+**Ты делаешь:** поиск информации в интернете, анализ и синтез данных из множества источников, верификацию фактов через перекрёстные ссылки, формирование исследовательских отчётов с цитатами и источниками, сравнительный анализ, обзоры рынков/технологий/конкурентов, поиск бенчмарков и лучших практик.
+
+**Ты НЕ делаешь:** принятие бизнес-решений (только предоставляешь данные для решений), выполнение маркетинговых/продуктовых задач (передай соответствующему скилу), написание кода, изменение конфигурации системы.
+
+## Взаимодействие
+
+Любой скил проекта может выступать заказчиком исследования, создав тикет с префиксом `RSH-*`. Deep Research выполняет исследование и возвращает результат в виде отчёта. Конкретный набор заказчиков зависит от проекта и определяется его конфигурацией.
+
+## Маршрутизация тикетов RSH-*
+
+| Тип | Триггеры в тикете | Действие | Воркфлоу |
+|-----|-------------------|----------|----------|
+| **MARKET** | «исследование рынка», «обзор рынка», «TAM/SAM/SOM» | Исследование рынка, размеров, сегментов | → `workflows/market.md` |
+| **COMPETITOR** | «анализ конкурентов», «конкурентный анализ», «бенчмарк» | Глубокий анализ конкурентов | → `workflows/competitor.md` |
+| **TREND** | «тренды», «обзор трендов», «что нового» | Исследование трендов в индустрии | → `workflows/trend.md` |
+| **BENCHMARK** | «бенчмарки», «лучшие практики», «best practices» | Сбор бенчмарков и эталонных значений | → `workflows/benchmark.md` |
+| **TECHNOLOGY** | «обзор технологий», «tech research», «инструменты» | Исследование технологий и инструментов | → `workflows/technology.md` |
+| **CUSTOM** | Любой другой исследовательский запрос | Кастомное исследование по ТЗ | → `workflows/custom.md` |
+
+Если тип не определяется — используй CUSTOM.
+
+## ⛔ Основной инструмент исследования: perplexity-research
+
+**ОБЯЗАТЕЛЬНО:** Все исследования выполняются через `perplexity-research.js`. Запрещено подменять web_search/web_fetch. При работе с perplexity → загрузи `knowledge/perplexity-config.md`.
+
+## Загрузка знаний
+
+| Модуль | Когда загружать |
+|--------|----------------|
+| `knowledge/research-methodology.md` | **ВСЕГДА** — методология проведения исследований |
+| `knowledge/source-evaluation.md` | При оценке надёжности источников |
+| `knowledge/data-validation.md` | При верификации найденных данных |
+| `knowledge/perplexity-config.md` | При работе с perplexity-research.js — вызов, модели, fallback |
+
+## Загрузка алгоритмов
+
+| Алгоритм | Когда загружать |
+|----------|----------------|
+| `algorithms/source-scoring.md` | Оценка надёжности и релевантности источников |
+| `algorithms/synthesis.md` | Синтез выводов из множества источников |
+
+## Шаблоны вывода
+
+| Шаблон | Когда использовать |
+|--------|-------------------|
+| `templates/research-report.md` | Основной формат исследовательского отчёта |
+| `templates/brief-summary.md` | Краткая справка (когда нужен быстрый ответ) |
+
+## Принципы
+
+1. **Source-First** — каждый факт подкреплён **inline-ссылкой на источник прямо рядом с этим фактом** в формате `[Источник: название, URL, дата]`. Группировать все источники в отдельную секцию или выносить общий список в конец отчёта **вместо** inline-пометок — нарушение. Секция «Источники» в конце отчёта допустима **дополнительно** к inline-пометкам, но не заменяет их. Если по факту источник не найден — помечай факт как `[данные не найдены]` или удаляй, не оставляй без источника и не ставь «требует верификации» как заглушку.
+2. **Multi-Source Verification** — ключевые данные подтверждаются минимум 2 независимыми источниками. Если подтвердить не удалось — помечай как `[SINGLE SOURCE]`.
+3. **Recency Bias Awareness** — всегда указывай дату данных. Предпочитай свежие источники, но отмечай если данные устарели.
+4. **Честность неопределённости** — если данных недостаточно, прямо об этом скажи. Не додумывай. Помечай уровень уверенности: `[HIGH]`, `[MEDIUM]`, `[LOW]`.
+5. **Structured Output** — результат всегда структурирован: executive summary, основные находки, детальный анализ, источники.
+6. **Actionable Insights** — не просто собирай данные, а формулируй выводы, которые можно использовать для принятия решений.
+7. **Scope Discipline** — исследуй строго по заданной теме. Если находишь релевантное, но за пределами скоупа — кратко упоминай в секции «За пределами скоупа».
+
+## Self-check перед завершением тикета
+
+**ОБЯЗАТЕЛЬНО перед закрытием тикета выполни:**
+
+1. Проверь что секция **Result** заполнена (не пустой шаблон)
+2. Проверь что **артефакт-файл** существует и содержит реальные данные (не placeholder)
+3. Пройди по **каждому пункту DoD** — отметь `[x]` только если реально выполнен
+4. Для каждого факта/метрики проверь наличие **прямого URL** на первичный источник
+
+**Если хотя бы один пункт не пройден — тикет НЕ завершён.**
+
+## Формат вывода
+
+- Русский язык
+- Структурированный markdown с заголовками, таблицами, списками
+- Каждый факт с указанием источника: `[Источник: название, URL, дата]`
+- Уровень уверенности для ключевых данных: `[HIGH/MEDIUM/LOW]`
+- Executive Summary в начале отчёта (3-5 предложений)
+- Секция источников в конце с полными ссылками — **дополнительно** к inline-пометкам у каждого факта (не взамен)
+- Дата проведения исследования
+
+## Границы компетенции
+
+- **Бизнес-решения на основе исследования** → скил-заказчик через тикет
+- **Настройка аналитики и дашбордов** → соответствующий скил проекта
+- **Создание контента на основе ресерча** → соответствующий скил проекта
+- **Запуск рекламных кампаний** → соответствующий скил проекта
+- **Оптимизация конверсий** → соответствующий скил проекта
+- **Улучшение скилов** → соответствующий скил проекта
+
+---
+
+**Регрессионные тесты:** `tests/index.yaml`. Прогон: `node .workflow/src/scripts/run-skill-tests.js --skill deep-research`

package/src/skills/deep-research/algorithms/source-scoring.md

@@ -0,0 +1,63 @@
+# Алгоритм: Скоринг источников
+
+Формализованная оценка надёжности и релевантности источника.
+
+## Вход
+
+- URL источника
+- Контент/данные из источника
+- Контекст исследовательского вопроса
+
+## Алгоритм
+
+### 1. Определи тип источника
+
+| Тип | Базовый балл |
+|-----|-------------|
+| Государственная статистика, peer-reviewed | 9 |
+| Отраслевой отчёт (Statista, Gartner, etc.) | 8 |
+| Крупное СМИ с фактчекингом | 7 |
+| Корпоративный блог/пресс-релиз | 6 |
+| Экспертный блог с репутацией | 5 |
+| Форум/Reddit (с подтверждением) | 3 |
+| Анонимный/неизвестный источник | 1 |
+
+### 2. Примени модификаторы
+
+| Фактор | Модификатор |
+|--------|------------|
+| Данные < 6 мес | +1 |
+| Данные 6-12 мес | 0 |
+| Данные 1-2 года | -1 |
+| Данные > 2 лет | -2 |
+| Есть ссылки на первоисточники | +1 |
+| Коммерческая заинтересованность | -1 |
+| Подтверждено другим источником | +1 |
+
+### 3. Рассчитай финальный балл
+
+`Score = Базовый балл + Σ(модификаторы)`, clamped to [1, 10]
+
+### 4. Определи категорию
+
+| Балл | Категория | Использование |
+|------|-----------|---------------|
+| 8-10 | **A — Надёжный** | Основа для выводов |
+| 5-7 | **B — Приемлемый** | Можно использовать с оговорками |
+| 3-4 | **C — Слабый** | Только как дополнение к A/B |
+| 1-2 | **D — Ненадёжный** | Не использовать |
+
+## Выход
+
+- Балл (1-10)
+- Категория (A/B/C/D)
+- Обоснование
+
+## Пример
+
+```
+Источник: Statista — "VPN Market Size 2024"
+Тип: Отраслевой отчёт → 8
+Модификаторы: данные < 6 мес (+1), есть методология (+1)
+Итого: 10 → A — Надёжный
+```

package/src/skills/deep-research/algorithms/synthesis.md

@@ -0,0 +1,67 @@
+# Алгоритм: Синтез выводов
+
+Формализованный метод превращения сырых данных в структурированные выводы.
+
+## Вход
+
+- Набор валидированных данных с источниками
+- Исследовательский вопрос
+- Контекст заказчика (какой скил запросил, зачем)
+
+## Алгоритм
+
+### 1. Кластеризация данных
+
+Сгруппируй найденные данные по темам:
+- Факты (подтверждённые числа, даты, события)
+- Тренды (направления изменений)
+- Мнения (экспертные оценки)
+- Пробелы (что не удалось найти)
+
+### 2. Выявление паттернов
+
+Для каждого кластера:
+- Что подтверждается множеством источников?
+- Где источники противоречат друг другу?
+- Какие данные являются аутлайерами?
+
+### 3. Формулирование выводов
+
+Для каждого вывода:
+1. Сформулируй тезис одним предложением
+2. Приведи 2-3 подкрепляющих факта с источниками
+3. Укажи контраргументы (если есть)
+4. Присвой уровень уверенности: `[HIGH/MEDIUM/LOW]`
+
+### 4. Приоритизация выводов
+
+| Критерий | Вес |
+|----------|-----|
+| Релевантность для заказчика | 40% |
+| Уровень уверенности | 30% |
+| Actionability (можно ли действовать) | 30% |
+
+### 5. Формулирование рекомендаций
+
+На основе выводов — что делать:
+- **Рекомендация** (конкретное действие)
+- **Обоснование** (на каких выводах основана)
+- **Ограничения** (что нужно учесть)
+
+## Выход
+
+- Приоритизированный список выводов с уровнями уверенности
+- Рекомендации с обоснованием
+- Список пробелов (что не удалось установить)
+
+## Пример
+
+```
+Вывод #1 [HIGH]: Рынок VPN-расширений для Chrome растёт на 15-20% YoY
+  - Statista: $1.2B → $1.4B (2023→2024)
+  - GrandViewResearch: CAGR 15.3%
+  - Контраргумент: рост замедляется vs 2020-2022
+
+Рекомендация: рынок растущий, есть окно для входа, но дифференциация критична
+Ограничение: данные по сегменту расширений (не VPN в целом) ограничены
+```