workflow-ai 1.1.0 → 1.3.0

package/src/skills/coach/workflows/improve.md.legacy

@@ -1,60 +0,0 @@
-# Воркфлоу: IMPROVE — Точечное улучшение скила
-
-Внесение конкретных улучшений в существующий скил на основе аудита, анализа или запроса.
-
-## Алгоритм выполнения
-
-### 0. Бэклог → SKILL.md «Обязательный шаг: Бэклог коуча». Не вноси повторно правки из `applied_changes`.
-
-### 1. Определи scope улучшения
-
-Из тикета извлеки:
-- Какой скил улучшаем?
-- Какая конкретная проблема или потребность?
-- Есть ли ссылка на аудит/анализ с рекомендациями?
-
-### 2. Изучи текущее состояние
-
-Прочитай файлы скила, которые затрагивает улучшение. Пойми текущую логику прежде чем менять.
-
-### 3. Определи тип улучшения
-
-| Тип | Действие |
-|-----|----------|
-| **Новый воркфлоу** | Создай `workflows/new-type.md`, добавь в маршрутизацию SKILL.md |
-| **Новые знания** | Создай/дополни файл в `knowledge/`, добавь в таблицу загрузки |
-| **Новый алгоритм** | Создай `algorithms/new-algo.md`, добавь в таблицу загрузки |
-| **Новый шаблон** | Создай `templates/new-template.md`, укажи в воркфлоу |
-| **Уточнение воркфлоу** | Добавь/исправь шаги в существующем воркфлоу |
-| **Обогащение knowledge** | Дополни существующий файл в knowledge/ после маркера расширения |
-| **Рефакторинг** | Реструктуризация без изменения поведения |
-
-### 4. Исследование (если нужно)
-
-Если улучшение требует новых знаний:
-- Поищи в интернете лучшие практики, фреймворки, методологии
-- Адаптируй найденное под формат knowledge/ или algorithms/
-- Укажи источник
-
-### 5. Внесение изменений
-
-- Следуй принципу минимальных изменений
-- Не ломай существующие ссылки и интеграции
-- Добавляй, а не переписывай (если не рефакторинг)
-- Обнови README.md если структура изменилась
-
-### 6. Валидация
-
-- Проверь все ссылки из SKILL.md
-- Убедись что новые файлы упомянуты в таблицах загрузки
-- Проверь консистентность терминологии
-
-### 7. Документирование
-
-Сформируй план улучшений → `templates/improvement-plan.md` с:
-- Что изменено и почему
-- Какие файлы затронуты
-- Ожидаемый эффект
-- Как проверить результат
-
-### 8. Обновление бэклога → SKILL.md «Обязательный шаг: Бэклог коуча»

package/src/skills/coach/workflows/research.md

@@ -1,55 +0,0 @@
-# Воркфлоу: RESEARCH — Исследование и поиск знаний
-
-Поиск лучших практик, фреймворков и подходов в интернете для обогащения скилов.
-
-## Алгоритм выполнения
-
-### 1. Определи цель исследования
-
-Из тикета извлеки:
-- Для какого скила ищем знания?
-- Какой домен / тема?
-- Какой тип знаний нужен: методология, метрики, бенчмарки, инструменты?
-
-### 2. Сформулируй поисковые запросы
-
-Составь 3–5 поисковых запросов на русском и английском:
-
-| Тип запроса | Пример |
-|-------------|--------|
-| Лучшие практики | «best practices [domain] framework 2025» |
-| Методологии | «[domain] methodology checklist» |
-| Метрики и бенчмарки | «[domain] KPI benchmarks SaaS» |
-| Инструменты | «[domain] tools stack comparison» |
-| Антипаттерны | «[domain] common mistakes pitfalls» |
-
-### 3. Поиск и фильтрация
-
-- Выполни поиск в интернете
-- Отфильтруй результаты по релевантности и актуальности (приоритет — свежие источники)
-- Извлеки ключевые идеи, фреймворки, чеклисты
-
-### 4. Адаптация под формат скила
-
-Преобразуй найденное в формат модулей скила:
-
-| Найденное | Куда добавить |
-|-----------|--------------|
-| Фреймворк принятия решений | `algorithms/` |
-| Набор метрик или бенчмарков | `knowledge/` |
-| Чеклист или пошаговый процесс | `workflows/` или `knowledge/` |
-| Шаблон документа | `templates/` |
-
-### 5. Интеграция
-
-- Создай или дополни соответствующие файлы в скиле
-- Добавь ссылки в таблицы загрузки SKILL.md
-- Укажи источник информации и дату получения
-
-### 6. Оформление результата
-
-Результат исследования:
-- Краткое резюме найденного
-- Список источников с кратким описанием каждого
-- Конкретные изменения, внесённые в скил
-- Рекомендации для дальнейшего исследования

package/src/skills/coach/workflows/review.md

@@ -1,52 +0,0 @@
-# Воркфлоу: REVIEW — Ревью скила
-
-Быстрое ревью структуры и качества скила с фокусом на конкретные аспекты.
-
-## Алгоритм выполнения
-
-### 0. Создание теста → `workflows/test.md`
-
-Перед началом ревью создай регрессионный тест для скила. Следуй воркфлоу `workflows/test.md`.
-
-### 1. Определи фокус ревью
-
-Из тикета извлеки: какой аспект проверить?
-
-| Фокус | Что проверять |
-|-------|--------------|
-| **Структура** | Полнота директорий и файлов, ссылочная целостность |
-| **Качество промптов** | Чёткость инструкций, отсутствие двусмысленности |
-| **Покрытие** | Все ли сценарии обработаны, нет ли пробелов |
-| **Консистентность** | Единообразие терминов, форматов, стиля |
-| **Актуальность** | Не устарели ли знания, бенчмарки, инструменты |
-
-Если фокус не указан — проведи ревью по всем аспектам.
-
-### 2. Чтение и анализ
-
-Прочитай все файлы скила. Чеклист по типам файлов:
-
-| Тип файла | Критерии |
-|-----------|----------|
-| **SKILL.md** | Роль конкретна, RACI чёткий, маршрутизация полна, таблицы загрузки полны, принципы actionable, формат вывода специфицирован |
-| **Workflows** | Каждый шаг — действие, ссылки на knowledge/algorithms, критерии завершения, нет дублирования |
-| **Knowledge** | Структурировано (таблицы/списки), маркеры `<!-- РАСШИРЕНИЕ -->`, источники указаны |
-| **Algorithms** | Формализован (шаги/пороги/формулы), вход/выход определён, примеры |
-| **Templates** | Поля обязательны или помечены, формат единообразен, placeholder-подсказки |
-
-### 3. Формирование замечаний
-
-Для каждого замечания укажи:
-- **Файл и секция** — где проблема
-- **Приоритет** — CRITICAL / HIGH / MEDIUM / LOW
-- **Проблема** — что не так
-- **Рекомендация** — как исправить
-
-### 4. Сообщить пользователю verdict runner'а и список затронутых файлов
-
-Сообщи пользователю:
-
-- **Список затронутых файлов:** `SKILL.md` и/или `workflows/`, `tests/cases/{id}.yaml`, `tests/index.yaml`, `tests/cases/{id}/current/`
-- **Verdict** из прогона тестов (шаг 0).
-
-**Остановиться.**

package/src/skills/coach/workflows/review.md.legacy

@@ -1,48 +0,0 @@
-# Воркфлоу: REVIEW — Ревью скила
-
-Быстрое ревью структуры и качества скила с фокусом на конкретные аспекты.
-
-## Алгоритм выполнения
-
-### 0. Бэклог → SKILL.md «Обязательный шаг: Бэклог коуча». Учитывай `applied_changes` при формировании замечаний.
-
-### 1. Определи фокус ревью
-
-Из тикета извлеки: какой аспект проверить?
-
-| Фокус | Что проверять |
-|-------|--------------|
-| **Структура** | Полнота директорий и файлов, ссылочная целостность |
-| **Качество промптов** | Чёткость инструкций, отсутствие двусмысленности |
-| **Покрытие** | Все ли сценарии обработаны, нет ли пробелов |
-| **Консистентность** | Единообразие терминов, форматов, стиля |
-| **Актуальность** | Не устарели ли знания, бенчмарки, инструменты |
-
-Если фокус не указан — проведи ревью по всем аспектам.
-
-### 2. Чтение и анализ
-
-Прочитай все файлы скила. Чеклист по типам файлов:
-
-| Тип файла | Критерии |
-|-----------|----------|
-| **SKILL.md** | Роль конкретна, RACI чёткий, маршрутизация полна, таблицы загрузки полны, принципы actionable, формат вывода специфицирован |
-| **Workflows** | Каждый шаг — действие, ссылки на knowledge/algorithms, критерии завершения, нет дублирования |
-| **Knowledge** | Структурировано (таблицы/списки), маркеры `<!-- РАСШИРЕНИЕ -->`, источники указаны |
-| **Algorithms** | Формализован (шаги/пороги/формулы), вход/выход определён, примеры |
-| **Templates** | Поля обязательны или помечены, формат единообразен, placeholder-подсказки |
-
-### 3. Формирование замечаний
-
-Для каждого замечания укажи:
-- **Файл и секция** — где проблема
-- **Приоритет** — CRITICAL / HIGH / MEDIUM / LOW
-- **Проблема** — что не так
-- **Рекомендация** — как исправить
-
-### 4. Итоговая оценка
-
-- Общая оценка: READY / NEEDS_WORK / MAJOR_ISSUES
-- Количество замечаний по приоритетам
-- Топ-3 вещи, которые сделаны хорошо
-- Топ-3 вещи, которые нужно исправить

package/src/skills/coach/workflows/test.md

@@ -1,97 +0,0 @@
-# Воркфлоу: TEST — Авторство тест-кейса регрессионного теста скила
-
-> **⚠️ DRAFT — не активирован.** Подключение к маршрутизации SKILL.md произойдёт в отдельной задаче.
-
-Воркфлоу описывает, как коуч создаёт регрессионный тест для скила при обнаружении инцидента.
-
-**Знания:** загрузи `knowledge/test-authorship.md` перед выполнением шагов.
-
-## Шаги 1–5: Подготовительный этап
-
-### Шаг 1. CHG-идентификатор не нужен
-
-Тест-кейс — это не изменение скила, а фиксация инцидента. Поэтому:
-
-- **Не создавай** CHG-запись в `applied_changes[]` бэклога.
-- Инцидент фиксируется через поле `origin` непосредственно в YAML тест-кейса.
-
-### Шаг 2. Получить ID тест-кейса
-
-Вызови скрипт из корня проекта:
-
-```
-node .workflow/src/scripts/get-next-test-id.js --skill <имя-скила>
-```
-
-Скрипт вернёт следующий свободный ID в формате `TC-<SKILL>-NNN`.
-Используй именно этот ID — не генерируй вручную.
-
-### Шаг 3. Выбор слоёв (L0 / L1 / L2)
-
-Полная логика выбора — в `knowledge/test-authorship.md`, раздел «Дерево выбора слоя».
-
-Краткие правила:
-
-| Слой | Когда использовать |
-|------|--------------------|
-| **L0** static | **Всегда** — если нужно проверить наличие инварианта в записанном файле. |
-| **L1** deterministic | Когда у output есть наблюдаемая сигнатура (структура YAML/JSON, формат ID, наличие ключей). |
-| **L2** rubric | Когда нужно проверить **принцип рассуждения** агента, а не конкретный текст. |
-
-Правило минимума: сомневаешься между L0 и L1 — выбирай L0. L2 — только если L0/L1 физически неприменимы.
-
-### Шаг 4. Построить фикстуру
-
-- Возьми **реальный артефакт**, в котором произошёл инцидент (лог, тикет, отчёт).
-- Вырежи **±20 строк вокруг инцидента** — не копируй весь файл.
-- Для log-фикстур: только шаги, где произошёл инцидент + 5 строк контекста до и после.
-- Критерий минимума: убери строку → тест перестаёт проверять нужное поведение? Если нет — строка лишняя.
-
-Сохрани фикстуру в `tests/fixtures/` скила.
-
-### Шаг 5. Написать YAML тест-кейса и проверить `index.yaml`
-
-1. Создай файл `tests/cases/<ID>.yaml` по структуре существующих кейсов в `tests/cases/`.
-2. В поле `origin` укажи ID инцидента (CHG или ссылку на артефакт).
-3. Проверь `tests/index.yaml` скила:
-   - Содержит ли он актуальный список `target_agents[]`?
-   - Если список устарел — обнови его, сверившись с `pipeline.yaml` проекта.
-4. Добавь запись о новом кейсе в секцию `cases:` файла `tests/index.yaml`.
-
-## Шаги 6–9: Исполнительный этап
-
-### Шаг 6. Прогон тестов
-
-Запусти скрипт из корня проекта:
-
-```
-node .workflow/src/scripts/run-skill-tests.js --skill <name> --relevant <TC-NNN>
-```
-
-Где `<name>` — имя скила, `<TC-NNN>` — ID тест-кейса, созданного на шаге 2.
-
-### Шаг 7. Проверка verdict из `---RESULT---`
-
-Прочитай поле `verdict` в блоке `---RESULT---` вывода скрипта:
-
-| Verdict | Действие |
-|---------|----------|
-| `ready_for_user_review` | Перейти к шагу 8. |
-| `regression_detected` | Доработать скил или тест, вернуться к шагу 6. |
-| `relevant_case_failed` | Доработать скил или тест, вернуться к шагу 6. |
-| `no_baseline_failures` | Доработать скил или тест, вернуться к шагу 6. |
-
-### Шаг 8. Сообщить пользователю
-
-Сообщи пользователю:
-
-- **Список затронутых файлов:** `SKILL.md` и/или `workflows/`, `tests/cases/{id}.yaml`, `tests/index.yaml`, `tests/cases/{id}/current/`
-- **Verdict** из шага 7.
-
-**Остановиться.** Коуч не делает ничего сверх этого — коммит на стороне пользователя (шаг 9).
-
-### Шаг 9. Коммит делает исключительно пользователь
-
-Коуч **не выполняет** `git add`, `git commit`, `git push`, `git checkout`, `git reset` ни в каком виде.
-
-В `applied_changes[]` бэклога **не пишем** — история правки живёт в git (скил + тест коммитятся пользователем одним коммитом).

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

@@ -1,39 +0,0 @@
-# Create Plan — Agent Skill
-
-Архитектор планов. Создаёт самодостаточные стратегические планы из ТЗ, спецификаций и задач. План содержит все данные, необходимые исполнителям — SMART-цели, справочные данные, scope, риски и критерии успеха.
-
-## Структура
-
-```
-create-plan/
-├── SKILL.md                          # Ядро: роль, маршрутизация, принципы
-├── README.md                         # Документация
-├── algorithms/
-│   └── risk-assessment.md            # Матрица рисков, критерии, митигация
-├── workflows/
-│   └── create.md                     # Создание плана из ТЗ / спецификации
-└── knowledge/
-    ├── plan-completeness.md          # Чеклист полноты плана
-    ├── plan-lifecycle.md             # Статусы планов
-    └── task-verification-pairs.md    # Парные задачи верификации
-```
-
-## Как это работает
-
-1. Скил получает запрос на создание плана (из ТЗ, спецификации или задачи)
-2. Загружает `knowledge/plan-completeness.md` — чеклист полноты
-3. Определяет сценарий и загружает `workflows/create.md`
-4. Извлекает все конкретные данные из входного документа (credentials, URLs, параметры)
-5. Формирует план: SMART-цели, справочные данные, scope, задачи, риски, критерии успеха
-6. Проверяет план по чеклисту полноты
-7. Сохраняет результат в `.workflow/plans/current/PLAN-{NNN}.md`
-
-## Как расширять
-
-### Новый тип воркфлоу
-1. Создай файл в `workflows/{type}.md`
-2. Добавь запись в таблицу маршрутизации в `SKILL.md`
-
-### Новый knowledge-модуль
-1. Создай файл в `knowledge/{module}.md`
-2. Добавь запись в таблицу загрузки знаний в `SKILL.md`

package/src/skills/create-plan/algorithms/risk-assessment.md

@@ -1,73 +0,0 @@
-# Алгоритм: Оценка рисков плана
-
-## Вход
-
-Описание задач плана, контекст проекта, внешние зависимости.
-
-## Матрица рисков
-
-Риск = **Вероятность (1–3)** × **Влияние (1–3)**. Итоговый уровень:
-
-| Вероятность \ Влияние | 1 (Низкое) | 2 (Среднее) | 3 (Высокое) |
-|----------------------:|:----------:|:-----------:|:-----------:|
-| **3 (Высокая)**       | MEDIUM (3) | HIGH (6)    | CRITICAL (9)|
-| **2 (Средняя)**       | LOW (2)    | MEDIUM (4)  | HIGH (6)    |
-| **1 (Низкая)**        | LOW (1)    | LOW (2)     | MEDIUM (3)  |
-
-## Критерии вероятности
-
-| Уровень | Определение | Пример |
-|:-------:|-------------|--------|
-| 1 | Маловероятно, требует стечения обстоятельств | Сторонний API изменит контракт во время спринта |
-| 2 | Возможно, случалось ранее или есть предпосылки | Интеграция потребует доработки из-за недокументированного поведения |
-| 3 | Почти наверняка, есть объективные признаки | Задача зависит от компонента, находящегося в активной разработке другой командой |
-
-## Критерии влияния
-
-| Уровень | Определение | Пример |
-|:-------:|-------------|--------|
-| 1 | Задержка ≤1 дня, обходной путь очевиден | Мелкий баг в утилите, можно пропатчить на месте |
-| 2 | Задержка 2–5 дней или частичное снижение качества | Нужен рефакторинг смежного модуля для интеграции |
-| 3 | Блокер: задержка >5 дней, пересмотр scope или архитектуры | Ключевая зависимость недоступна, альтернатива требует переделки |
-
-## Категории рисков
-
-При идентификации рисков проверь каждую категорию:
-
-| Категория | На что обращать внимание |
-|-----------|--------------------------|
-| **Технические** | Незнакомые технологии, сложные интеграции, legacy-код без тестов, производительность |
-| **Ресурсные** | Доступность исполнителей, context budget агентов, необходимость ручных действий (HUMAN) |
-| **Зависимости** | Внешние API, сторонние библиотеки, блокирующие задачи других команд, merge freeze |
-| **Внешние** | Изменения требований, compliance-ограничения, доступность сред (staging, sandbox) |
-
-## Стратегии митигации
-
-| Уровень риска | Действие |
-|:-------------:|----------|
-| CRITICAL (6–9) | Обязательная митигация в плане. Определи fallback-вариант и условие переключения |
-| HIGH (4–6) | Митигация рекомендована. Укажи план Б или запасной подход |
-| MEDIUM (3–4) | Упомяни в секции рисков. Митигация по необходимости |
-| LOW (1–2) | Фиксируй только если влияние = 3 (может перейти в MEDIUM при росте вероятности) |
-
-## Применение
-
-1. Составь список задач плана
-2. Для каждой задачи пройди по 4 категориям — идентифицируй конкретные риски
-3. Оцени вероятность и влияние каждого риска по критериям выше
-4. Рассчитай уровень по матрице
-5. Для CRITICAL/HIGH — опиши митигацию и fallback
-6. Запиши в секцию «Риски и зависимости» плана
-
-### Пример
-
-> **Риск:** Sandbox нестабилен — MCP disconnect при длительных сессиях
-> **Категория:** Техническая / Зависимости
-> **Вероятность:** 3 (подтверждено инцидентами QA-004, QA-006)
-> **Влияние:** 2 (задержка 2-3 дня, обходной путь — restart + continuation)
-> **Уровень:** HIGH (6)
-> **Митигация:** Ограничить сессию до N тест-кейсов, стратегия continuation
-
-## Выход
-
-Таблица рисков в плане: риск, категория, вероятность, влияние, уровень, митигация.

package/src/skills/create-plan/knowledge/plan-completeness.md

@@ -1,67 +0,0 @@
-# Полнота плана: чеклист для самопроверки
-
-План — это **единственный источник правды** для исполнителей. Если данных нет в плане, их нет у агентов. Исполнители **не имеют доступа** к исходному ТЗ, переписке, устным договорённостям.
-
-## Принцип: план = самодостаточный документ
-
-> Агент-исполнитель, получив тикет из плана, должен иметь **всё необходимое** для реализации без обращения к другим документам.
-
-## Чеклист извлечения данных из ТЗ
-
-При создании плана на основе внешнего документа (ТЗ, спецификация, RFC, задача от стейкхолдера) — **извлеки и перенеси в план ВСЕ конкретные данные**:
-
-### Обязательно переносить
-
-| Категория | Примеры | Куда в плане |
-|-----------|---------|-------------|
-| **Credentials / ключи / токены** | API keys, secret keys, measurement IDs, tokens | Секция "Справочные данные" |
-| **URLs и endpoints** | API endpoints, формы, debug URLs, webhook URLs | Секция "Справочные данные" |
-| **Конфигурационные значения** | Константы, интервалы, лимиты, имена alarm'ов, storage keys | Секция "Справочные данные" |
-| **Permissions / манифесты** | JSON-фрагменты, YAML-конфигурации, строки для конфигов | Секция "Справочные данные" |
-| **Карты файлов** | Какой код → в какой файл → при каком триггере → с какими параметрами | Секция "Справочные данные" (таблица) |
-| **Параметры событий/запросов** | Имена, типы, описания, допустимые значения каждого параметра | Секция "Справочные данные" (таблица) |
-| **Схемы данных** | Storage keys, типы полей, форматы, валидация | Секция "Справочные данные" |
-| **Бизнес-логика и edge cases** | Порядок операций, условия (ДО/ПОСЛЕ), only-if логика | Описание задач |
-| **Troubleshooting** | Типичные ошибки, причины, решения | Задача тестирования |
-| **Внешние ресурсы** | Описания форм, структура опросов, тексты | Секция "Справочные данные" |
-
-### НЕ переносить (оставить в scope исключений)
-
-- Инструкции по настройке внешних сервисов (если это ручная работа вне scope)
-- Общие описания подходов (если они очевидны из контекста)
-- Дублирование одних и тех же данных в нескольких местах плана
-
-## Красные флаги неполного плана
-
-Если в плане встречаются следующие формулировки — это сигнал, что данные не перенесены:
-
-| Формулировка в плане | Проблема |
-|---------------------|----------|
-| "URL из ТЗ" / "URL уже создан" | URL не указан — исполнитель его не знает |
-| "см. документацию" / "описано в спецификации" | Исполнитель не имеет доступа к спецификации |
-| "настроить credentials" (без значений) | Какие credentials? Где взять? |
-| "добавить параметры" (без списка) | Какие параметры? Какие типы? |
-| "интегрировать событие" (без деталей) | Какое имя? Какие params? В какой файл? При каком триггере? |
-| "обновить конфиг" (без конкретного JSON/YAML) | Что именно добавить? |
-
-## Секция "Справочные данные" в плане
-
-Каждый план, основанный на внешнем ТЗ, **должен содержать** секцию "Справочные данные" между "Контекст" и "Scope". Эта секция — справочник для всех задач плана.
-
-Структура секции:
-```markdown
-## Справочные данные
-
-### {Подсекция по категории}
-{Таблицы, code blocks, конкретные значения}
-```
-
-Подсекции определяются содержимым ТЗ. Типичные:
-- Credentials / API keys
-- URLs и endpoints
-- Карта событий / API / маршрутов
-- Схема данных (storage, DB, state)
-- Конфигурации (manifests, permissions, configs)
-- Константы и интервалы
-
-<!-- РАСШИРЕНИЕ: добавляй новые категории данных для извлечения ниже -->

package/src/skills/create-plan/knowledge/plan-lifecycle.md

@@ -1,33 +0,0 @@
-# Жизненный цикл статусов плана
-
-Каждый план проходит через определённые статусы. Скил `create-plan` должен знать их, чтобы корректно устанавливать начальный статус и не использовать невалидные значения.
-
-## Статусы
-
-```
-draft → approved → active → completed → archived
-```
-
-| Статус | Описание | Кто устанавливает |
-|--------|----------|-------------------|
-| `draft` | Черновик. План создан, но ещё не утверждён стейкхолдером | Скил `create-plan` при создании |
-| `approved` | Утверждён стейкхолдером. Готов к декомпозиции на тикеты | Стейкхолдер после ревью плана |
-| `active` | В работе. Тикеты созданы и прошли машинную проверку атомарности | Pipeline: стадия `verify-atomicity` при `status: passed` (не декомпозитор) |
-| `completed` | Все тикеты плана завершены | Pipeline после завершения всех тикетов |
-| `archived` | Архивирован. Перемещён в `plans/archive/` | Команда `workflow.archivePlan` |
-
-## Правила для скила create-plan
-
-1. **Всегда создавай план со статусом `draft`** — план должен пройти ревью и утверждение стейкхолдером
-2. **Не ставь `approved` автоматически** — утверждение делает стейкхолдер
-3. **Не ставь `active`** — этот статус устанавливается после декомпозиции
-
-## Связь с pipeline
-
-Скрипт `check-plan-decomposed.js` сканирует планы в `plans/current/` и декомпозирует **только** планы со статусом `approved`. Планы в `draft` пропускаются.
-
-Это значит: пока стейкхолдер не утвердит план (`status: approved`), pipeline **не будет** его декомпозировать.
-
-**Переход `approved → active`** выполняется стадией `verify-atomicity` пайплайна (`src/skills/decompose-plan/scripts/verify-atomicity.js`), **не** декомпозитором и **не** скилом `create-plan`. Условие перехода: все тикеты плана прошли машинную проверку атомарности (`status: passed`). Если атомарность упала и счётчик попыток `atomicity_check_attempts` достиг `max: 3` — план остаётся в `approved`, в работу не уходит; стадия `increment-atomicity-counter` передаёт управление в `check-conditions` без активации плана.
-
-<!-- РАСШИРЕНИЕ: добавляй новые статусы и правила ниже -->