workflow-ai 1.0.63 → 1.0.65

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

@@ -0,0 +1,97 @@
+# Воркфлоу: 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

@@ -0,0 +1,39 @@
+# 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/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: create-plan
+description: >
+  Создать стратегический план для проекта. Используй когда нужно спланировать
+  новую функциональность, проект или задачу. Создаёт самодостаточный файл плана
+  в .workflow/plans/current/ по шаблону со SMART-целями, справочными данными,
+  scope, рисками и критериями успеха. План содержит ВСЕ данные, необходимые
+  исполнителям — без обращения к внешним документам.
+---
+
+# Создание плана
+
+Этот skill создаёт стратегический план для достижения цели.
+
+## Роль
+
+Ты — архитектор планов. Твоя задача — создать **самодостаточный** план, по которому агенты-исполнители смогут выполнить все задачи **без обращения к исходному ТЗ или другим внешним документам**.
+
+**Ты делаешь:** извлечение всех конкретных данных из входного документа, формулирование SMART-целей, определение scope, декомпозиция на задачи с полными деталями, анализ рисков, определение критериев успеха.
+
+**Ты НЕ делаешь:** декомпозицию на тикеты (это задача скила декомпозиции), выполнение задач, принятие решений за стейкхолдера по scope.
+
+## Когда использовать
+
+- Начинается новый проект или крупная задача
+- Нужно переосмыслить направление после отчёта
+- Требуется структурированный план с декомпозицией
+
+## Маршрутизация
+
+| Сценарий | Воркфлоу |
+|----------|----------|
+| Создание плана из ТЗ / спецификации / задачи | → `workflows/create.md` |
+
+## Загрузка знаний
+
+| Модуль | Когда загружать |
+|--------|----------------|
+| `knowledge/plan-completeness.md` | **ВСЕГДА** — чеклист полноты плана, правила извлечения данных из ТЗ |
+| `knowledge/plan-lifecycle.md` | **ВСЕГДА** — статусы планов и правила их установки |
+| `knowledge/task-verification-pairs.md` | При наличии в плане задач тестирования/верификации ИЛИ задач, изменяющих код — правила TC-структуры: data assertions, entry points, config variations, persistence и парные задачи верификации |
+| `../shared/*` | **Перед началом работы** проверь `../shared/README.md` — загрузи модули, релевантные текущему плану (карта UI продукта, предметные знания и др.) |
+
+## Загрузка алгоритмов
+
+Подгружай из `algorithms/` когда нужен формализованный метод:
+
+| Алгоритм | Когда загружать |
+|----------|----------------|
+| `algorithms/risk-assessment.md` | При создании секции рисков плана — матрица вероятность × влияние, категории, митигация |
+
+## Принципы
+
+1. **Самодостаточность** — план содержит ВСЕ данные для исполнения. Если данных нет в плане — их нет у исполнителей. Никаких ссылок "см. ТЗ" или "URL уже создан".
+2. **Конкретность** — credentials, URLs, параметры, конфигурации, code blocks — всё это переносится в план как есть.
+3. **Полнота задач** — каждая задача содержит: какие файлы затрагиваются, какие значения использовать, edge cases, предупреждения.
+4. **Самопроверка** — перед сохранением обязательна проверка по чеклисту из `knowledge/plan-completeness.md`.
+5. **SMART-цели** — цель плана конкретна, измерима, достижима, релевантна, ограничена во времени.
+6. **Верификация изменений кода** — каждая задача, изменяющая код продукта, сопровождается парными задачами: ручная проверка и актуализация автотестов. См. `knowledge/task-verification-pairs.md`.
+7. **Актуализация shared knowledge** — если план меняет внешнее поведение продукта (новые команды, views, настройки, API, горячие клавиши, UI-элементы), добавь в план задачу на обновление соответствующих модулей в `../shared/`. Устаревший shared knowledge приводит к ошибкам во всех скилах-потребителях (планирование нереалистичных тест-кейсов, слепое тестирование, лишние MCP-вызовы).
+8. **Гранулярность задач** — каждая задача плана должна описывать **одно действие** (один глагол) над **одним объектом**. Задача «Исправить X — сигнатура, порядок, удаление Y» содержит 3 независимых действия и должна быть разбита на 3 задачи уже на этапе плана. Декомпозитор работает со структурой плана как с якорем — крупная задача провоцирует маппинг «1 задача = 1 тикет», даже если чеклист атомарности требует разбиения. **Self-check:** перед сохранением плана для каждой задачи проверь: содержит ли название задачи 2+ глагола через запятую, «и», «а также», «плюс»? Содержат ли нумерованные шаги независимые (параллельные) действия? Если да — разбей задачу в плане.
+
+## Правило назначения исполнителей
+
+Не назначай HUMAN, если агент может выполнить задачу автономно. Агент имеет доступ к:
+- **Playwright MCP-browser** — открывает URL в браузере, включая аутентифицированные сервисы (если сессия активна)
+- **WebSearch / WebFetch** — публичные данные
+- **Файлы проекта** — данные в корне
+
+HUMAN назначается только когда агент **подтверждённо** не может получить доступ (2FA, оплата, физические действия). При неопределённости — назначай агента с `fallback: HUMAN`.
+
+## Формат вывода
+
+- Русский язык
+- Markdown с таблицами и code blocks
+- Секция "Справочные данные" обязательна при создании из ТЗ
+- Все конкретные значения — в code blocks или таблицах
+
+## Границы компетенции
+
+- **Декомпозиция на тикеты** → скил декомпозиции
+- **Анализ отчётов** → скил анализа отчётов
+- **Выполнение задач** → скил выполнения задач
+
+## Пример использования
+
+```
+Создай план на основе ТЗ dev-tasks-plan007.md
+```
+
+## Результат
+
+Файл `.workflow/plans/current/PLAN-{NNN}.md` с:
+- Целью и контекстом
+- **Справочными данными** (все credentials, URLs, параметры, конфигурации из ТЗ)
+- Scope (включено/исключено)
+- Высокоуровневыми задачами с конкретными деталями
+- Рисками и митигацией
+- Критериями успеха
+
+
+---
+
+**Регрессионные тесты:** `tests/index.yaml`. Прогон: `node .workflow/src/scripts/run-skill-tests.js --skill create-plan`

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

@@ -0,0 +1,73 @@
+# Алгоритм: Оценка рисков плана
+
+## Вход
+
+Описание задач плана, контекст проекта, внешние зависимости.
+
+## Матрица рисков
+
+Риск = **Вероятность (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

@@ -0,0 +1,67 @@
+# Полнота плана: чеклист для самопроверки
+
+План — это **единственный источник правды** для исполнителей. Если данных нет в плане, их нет у агентов. Исполнители **не имеют доступа** к исходному ТЗ, переписке, устным договорённостям.
+
+## Принцип: план = самодостаточный документ
+
+> Агент-исполнитель, получив тикет из плана, должен иметь **всё необходимое** для реализации без обращения к другим документам.
+
+## Чеклист извлечения данных из ТЗ
+
+При создании плана на основе внешнего документа (ТЗ, спецификация, 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

@@ -0,0 +1,33 @@
+# Жизненный цикл статусов плана
+
+Каждый план проходит через определённые статусы. Скил `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` без активации плана.
+
+<!-- РАСШИРЕНИЕ: добавляй новые статусы и правила ниже -->

package/src/skills/create-plan/knowledge/task-verification-pairs.md

@@ -0,0 +1,151 @@
+# Парные задачи верификации
+
+Каждая задача плана, которая изменяет код продукта, должна сопровождаться задачами верификации. Набор парных задач зависит от характера изменения.
+
+## Правило
+
+Если задача плана предполагает **изменение кода продукта** (исправление, доработка, новая функциональность), определи для неё необходимые задачи верификации:
+
+1. **Актуализация автотестов** (обязательна всегда) — добавление или обновление unit/integration-тестов, покрывающих изменённое поведение
+2. **Ручная проверка** (если изменение наблюдаемо пользователем) — тестировщик вручную проверяет исправление по шагам воспроизведения или acceptance criteria
+
+## Определение набора парных задач
+
+Для каждой задачи, изменяющей код, архитектор определяет какие верификационные задачи нужны, задавая два вопроса:
+
+1. **Может ли пользователь заметить изменение?** (видимый эффект в UI, поведении, выводе) → если да, нужна **ручная проверка**
+2. **Можно ли покрыть изменение автоматическим тестом?** (есть вход/выход, поведение формализуемо) → если да, нужна **актуализация автотестов**
+
+| Ответы на вопросы | Автотесты | Ручная проверка |
+|---|---|---|
+| Пользователь заметит + можно покрыть тестом | Да | Да |
+| Пользователь заметит + нельзя покрыть тестом (чисто визуальное) | Нет | Да |
+| Пользователь не заметит + можно покрыть тестом | Да | Нет |
+| Пользователь не заметит + нельзя покрыть тестом | Обосновать в плане, почему верификация не нужна |
+
+Если не очевидно — включай обе задачи (лучше проверить лишний раз).
+
+## Структура группы задач
+
+```
+# Полная группа (изменение с наблюдаемым эффектом):
+Задача N:   Изменение кода (исполнитель: agent)
+Задача N+1: Ручная проверка задачи N (исполнитель: agent, зависимость: задача N)
+Задача N+2: Актуализация автотестов для задачи N (исполнитель: agent, зависимость: задача N)
+
+# Сокращённая группа (внутреннее изменение без UI-эффекта):
+Задача N:   Изменение кода (исполнитель: agent)
+Задача N+1: Актуализация автотестов для задачи N (исполнитель: agent, зависимость: задача N)
+```
+
+## Когда применять
+
+- **Применяется:** задача изменяет исходный код продукта (логику, UI, стили, конфигурацию продукта)
+- **НЕ применяется:** задача изменяет только документацию, тестовые утилиты (mock, test helpers), workflow-артефакты, или является чисто исследовательской
+
+## Исключения
+
+Объединение ручных проверок нескольких задач в одну сводную задачу **по умолчанию запрещено**. Каждая задача изменения кода с наблюдаемым эффектом получает **свою** парную задачу ручной проверки рядом — не в конце плана.
+
+**Когда сводная задача допустима** (все условия одновременно):
+1. Объединяемые задачи изменяют **один и тот же UI-объект** (одна view, один компонент, один экран) — а не несколько независимых областей продукта
+2. Каждая отдельная проверка тривиальна (1-2 шага) — иначе сводный сценарий распухает и теряет фокус
+3. В плане **явно перечислены** ID объединяемых задач и обоснование, почему раздельная проверка избыточна
+
+**Антипаттерн:** одна задача «Ручная проверка задач 1-7» в конце плана, охватывающая разные UI-области. Это не сводная проверка — это пропуск парных задач. Декомпозитор не сможет создать корректные парные тикеты, верификация теряет связь с исходной задачей, ревью затрудняется.
+
+## Self-check перед сохранением плана
+
+Перед записью файла плана пройди по списку задач и для **каждой** задачи, изменяющей код продукта с наблюдаемым эффектом, ответь:
+
+1. Есть ли рядом с этой задачей парная задача ручной проверки именно для неё?
+2. Если ручная проверка вынесена в сводную задачу — выполнены ли все три условия из секции «Исключения»?
+3. Если не выполнены — разбей сводную задачу на парные и помести каждую рядом с её основной задачей.
+
+Если задача изменения кода найдена без парной ручной проверки и без обоснованного исключения — план **не готов к сохранению**.
+
+## Data assertions в QA-задачах
+
+Каждый тест-кейс в QA-задаче плана должен содержать **ожидаемое значение**, а не только ожидаемое наличие элемента.
+
+### Правило
+
+Вместо «компонент X находится в состоянии Y» → «компонент X показывает конкретное значение `Z`».
+
+### Критерий применения
+
+Задай вопрос: **«Может ли значение измениться между запусками или зависит от входных данных?»**
+
+| Ответ | Тип данных | Примеры | Нужен data assertion |
+|-------|-----------|---------|----------------------|
+| Да | Динамические: счётчики, имена, время, параметризованные статусы | «Прогресс: 3 из 5» | ✅ Да |
+| Нет | Статические: иконки, фиксированные подписи, кнопки | «Кнопка «Открыть» видна» | ❌ Нет |
+
+### Примеры переформулировки
+
+| Слабое (только наличие) | Сильное (data assertion) |
+|-------------------------|--------------------------|
+| «Статус-строка показывает Running» | «Статус-строка показывает `Running \| <имя текущего шага>`» |
+| «История содержит записи» | «История содержит N записей, каждая с временем > 0s» |
+
+### Ограничения
+
+- Не требуй data assertion для непредсказуемых значений (случайные ID, временны́е метки с миллисекундной точностью) — в таких случаях проверяй формат: «timestamp соответствует паттерну `ISO 8601`»
+- Одна проверка значения на ключевой динамический элемент достаточна — не раздувай тест-кейс
+
+<!-- РАСШИРЕНИЕ: добавляй уточнения и исключения ниже -->
+
+## Entry points и config variations в QA-задачах
+
+При создании QA-задачи для функции/команды необходимо перечислить ВСЕ способы её вызова и все конфигурации, влияющие на поведение.
+
+### Правило
+
+Для каждой тестируемой функции/команды выполни 4 шага:
+
+1. **Определи все entry points** — изучи проектный манифест (конфиг, декларацию расширения/плагина) и код, чтобы найти ВСЕ точки входа (меню, сочетания клавиш, inline UI, контекстное меню, программный API). Каждый entry point — потенциально отдельный TC.
+
+2. **Покрой каждый entry point TC-ом** — не ограничивайся «основным» способом запуска. Функция считается протестированной только если каждый задекларированный entry point проверен отдельно.
+
+3. **Определи config variations** — найди все конфигурационные параметры, влияющие на поведение функции: допустимые значения, граничные значения, отсутствие опциональных параметров. Каждая значимая вариация — отдельный TC или параметризованный шаг.
+
+4. **Добавь persistence TC для stateful-функций** — если функция сохраняет данные (история, кэш, настройки), включи TC: данные сохраняются после перезапуска приложения и корректно накапливаются при повторных запусках.
+
+### Критерий применения
+
+Задай вопрос: **«Может ли пользователь вызвать эту функцию более чем одним способом?»**
+
+| Ответ | Действие |
+|-------|----------|
+| Да | Перечислить все entry points, добавить TC на каждый |
+| Нет | Один TC на единственный entry point |
+
+И: **«Зависит ли поведение от конфигурации или сохраняет ли функция данные между сессиями?»**
+
+| Ответ | Действие |
+|-------|----------|
+| Да, конфиг влияет | TC для каждого значения/варианта, влияющего на поведение |
+| Да, данные сохраняются | TC на persistence и накопление |
+| Нет | Конфигурационные и persistence TC не нужны |
+
+### Пример структуры анализа entry points (абстрактный)
+
+```
+Функция: «Запустить проверку»
+
+Entry points (из манифеста и кода):
+  [ ] Главное меню → «App: Run Check»
+  [ ] Клавиатурное сочетание → Ctrl+Shift+R
+  [ ] Контекстное меню → правый клик → «Run Check»
+  [ ] Inline-кнопка → иконка ▶ в строке элемента
+  [ ] Программный API → app.runCheck()
+
+Config variations:
+  [ ] mode = fast (по умолчанию)
+  [ ] mode = full
+  [ ] mode отсутствует (edge case)
+
+Persistence (если stateful):
+  [ ] История запусков сохраняется после перезапуска
+  [ ] Накопление: N запусков → N записей в истории
+```