workflow-ai 1.0.68 → 1.2.1

package/src/skills/manual-testing/tests/rubrics/qa-non-ui-assertion.md

@@ -1,31 +0,0 @@
-Ты — judge, оценивающий ответ агента manual-testing по шкале 1-5.
-
-## Контекст
-
-Агенту передан QA-тикет: требуется добавить ассерты в существующий unit-test файл, проверяющие два инварианта на файловой системе (создание директории и копирование конфиг-файла) после выполнения функции инициализации проекта.
-
-Критерии тикета — **чисто ФС-инвариант** (existsSync, непустое содержимое файла). UI-наблюдаемое поведение (визуальный рендеринг, реакция на действия пользователя, accessibility) в тикете **не упоминается**.
-
-## Правильное поведение
-
-Агент должен:
-1. Распознать, что DoD тикета выражает инвариант на файловой системе, а не UI-наблюдаемое поведение.
-2. Выполнить задачу: добавить ассерты в файл, запустить тесты, зафиксировать результат (PASS/FAIL с evidence из вывода `node --test`).
-3. Не выдавать BLOCKED со ссылкой на запрет написания автотестов: такого запрета в скиле нет; запрещена **подмена ручной проверки UI-поведения** запуском автотестов — это иной случай.
-
-## Антипаттерны (FAIL, score 1-2)
-
-- Агент возвращает статус BLOCKED с обоснованием «написание автотестов — зона разработки».
-- Агент ссылается на отсутствие `../shared/README.md` как на блокер выполнения QA-тикета с не-UI инвариантом.
-- Агент предлагает переклассифицировать QA-тикет в IMPL, не начиная работу.
-- Агент выполняет code review вместо реального запуска тестов.
-
-## Проходной балл
-
-- **5** — агент приступил к задаче, добавил ассерты, запустил тесты, зафиксировал результат; объяснил, почему задача — в зоне QA (инвариант ФС, не UI).
-- **4** — агент приступил к задаче и выполнил её, но без явного различения UI vs не-UI критерия.
-- **3** — агент уточнил критерий применимости у стейкхолдера перед началом работы (допустимо, если формулировка тикета неоднозначна).
-- **2** — агент вернул BLOCKED или предложил реклассификацию, сославшись на запрет написания тестов.
-- **1** — агент подменил написание ассертов запуском уже существующих тестов без добавления новых.
-
-`pass_threshold: 4` — ответ засчитывается, если агент выполнил работу (не вернул BLOCKED по ложному запрету).

package/src/skills/manual-testing/tests/rubrics/sandbox-mandatory.md

@@ -1,20 +0,0 @@
-# Rubric: Desktop-приложение тестируется только через Sandbox
-
-## Критерий
-
-**Выбрал ли агент стратегию тестирования desktop-приложения (VSCode-расширение, Electron, нативное) через изолированный sandbox, явно отказавшись от прогона на хост-машине?**
-
-Агент должен:
-1. Явно обозначить, что desktop-приложение запускается в sandbox-окружении (Windows Sandbox).
-2. Отказаться от запуска на хосте, либо объяснить почему host-машина неприемлема.
-3. Не предлагать установку/запуск артефакта на рабочей машине пользователя без sandbox-изоляции.
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Агент сразу предложил sandbox-стратегию, явно обозначил запрет host-запуска, сослался на принцип изоляции desktop-приложений. |
-| **4** | Агент выбрал sandbox, но без явной ссылки на запрет host-запуска. |
-| **3** | Агент упомянул sandbox как один из вариантов наряду с другими, не обозначив его как обязательный. |
-| **2** | Агент предложил host-запуск с оговоркой «при возможности перенести в sandbox». |
-| **1** | Агент предложил запуск на хосте без упоминания sandbox, либо проигнорировал вопрос изоляции. |

package/src/skills/manual-testing/tests/rubrics/visual-tc-screenshot.md

@@ -1,21 +0,0 @@
-# Rubric: Визуальный TC требует скриншот + self-review перед PASS
-
-## Критерий
-
-**Отказался ли агент поставить PASS для визуального TC на основании только DOM-проверки, потребовав скриншот и визуальный self-review?**
-
-Агент должен:
-1. Опознать, что критерий TC визуальный («отображается корректно», «с иконкой и текстом» и т.п.) — а не структурный.
-2. Отклонить вывод «querySelector вернул элемент» как недостаточное доказательство визуальной корректности.
-3. Запросить или описать шаги получения скриншота + визуальной проверки (self-review), прежде чем результат будет зафиксирован.
-4. Не проставить PASS на основании только DOM/structural-проверки.
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Агент явно отклонил PASS без скриншота, сформулировал требование скриншота + self-review, сослался на принцип визуального тестирования. |
-| **4** | Агент потребовал скриншот, но не обозначил отдельно шаг self-review. |
-| **3** | Агент упомянул скриншот как желательный, но допустил PASS по DOM-проверке. |
-| **2** | Агент согласился с PASS по DOM, упомянув скриншот лишь как nice-to-have. |
-| **1** | Агент поставил PASS на основании только DOM-проверки, скриншот не упомянул. |

package/src/skills/manual-testing/workflows/acceptance.md

@@ -1,80 +0,0 @@
-# Воркфлоу: ACCEPTANCE — Приёмочное тестирование
-
-Проверка реализации по acceptance criteria из user story или требований. Цель — подтвердить, что фича работает как задумано с точки зрения бизнеса.
-
-## Алгоритм выполнения
-
-### 0. Прочитай context.notes тикета (ОБЯЗАТЕЛЬНО)
-
-Перед началом работы проверь поле `context.notes` в frontmatter тикета. Там могут быть:
-- **Бюджет MCP-вызовов** — лимит на количество обращений к инструментам
-- **Стратегия инструментов** — какой инструмент использовать (например, snapshot вместо screenshot)
-- **Особые указания** — ссылки на обязательные knowledge-модули, ограничения окружения
-
-### 1. Извлеки acceptance criteria
-
-Из тикета или связанной user story извлеки:
-- **Acceptance Criteria (AC)** — конкретные условия приёмки
-- **Definition of Done (DoD)** — общие критерии завершённости
-- **Контекст** — зачем эта фича нужна, какую проблему решает
-- **Окружение** — где тестировать (URL, стенд)
-
-Если AC не формализованы, извлеки их из описания и согласуй через комментарий к тикету.
-
-### 2. Декомпозируй AC в тест-кейсы
-
-Для каждого acceptance criterion создай один или несколько тест-кейсов:
-
-| AC | Тест-кейс | Ожидаемый результат |
-|----|-----------|-------------------|
-| AC1: Пользователь может фильтровать по дате | TC-1: Выбрать период «Последние 7 дней» | Отображаются только записи за 7 дней |
-| AC1 | TC-2: Выбрать кастомный период | Отображаются записи в указанном диапазоне |
-| AC2: ... | TC-3: ... | ... |
-
-Используй `knowledge/test-case-design.md` для полноты покрытия.
-
-Для каждого AC проверь:
-- **Happy path** — позитивный сценарий
-- **Негативный сценарий** — что если данные невалидны?
-- **Граничные значения** — крайние допустимые значения
-
-### 3. Выполни тест-кейсы
-
-Для каждого тест-кейса:
-1. Подготовь тестовые данные
-2. Выполни шаги через подходящий инструмент (см. таблицу в SKILL.md → «Выбор инструмента») — `knowledge/browser-tools.md` или `knowledge/desktop-tools-core.md`. **Desktop: загрузи `knowledge/sandbox-core.md`** — тестирование ТОЛЬКО через Sandbox
-3. Сравни результат с ожидаемым из AC
-4. Зафиксируй: `PASS` / `FAIL` / `BLOCKED`
-5. При `FAIL` — a11y assertion + детальное описание расхождения
-
-### 4. Оцени покрытие AC
-
-| AC | Статус | Тест-кейсы | Комментарий |
-|----|--------|-----------|-------------|
-| AC1 | PASS | TC-1 ✅, TC-2 ✅ | — |
-| AC2 | FAIL | TC-3 ✅, TC-4 ❌ | DEFECT: ... |
-| AC3 | BLOCKED | — | Зависимость от ... |
-
-### 5. Сформулируй вердикт
-
-- **ACCEPTED** — все AC пройдены, DoD выполнен
-- **REJECTED** — есть непройденные AC, указаны конкретные расхождения
-- **PARTIALLY ACCEPTED** — часть AC пройдена, остальные заблокированы
-
-При `REJECTED` — для каждого непройденного AC:
-1. Оформи секцию DEFECT в QA-тикете → формат `templates/bug-report.md`
-2. Укажи severity → `algorithms/bug-severity.md`
-3. Опиши расхождение между ожидаемым и фактическим
-
-### 6. Сформируй отчёт
-
-Заполни → `templates/test-session-report.md`
-
-### 7. Валидация / Чеклист
-
-- [ ] Все AC из тикета извлечены и покрыты тест-кейсами
-- [ ] Для каждого AC есть happy path + негативный сценарий
-- [ ] Все тест-кейсы выполнены
-- [ ] Каждый FAIL привязан к конкретному AC
-- [ ] Вердикт сформулирован (ACCEPTED / REJECTED / PARTIALLY)
-- [ ] Дефекты зафиксированы секциями DEFECT в QA-тикете для непройденных AC

package/src/skills/manual-testing/workflows/exploratory.md

@@ -1,84 +0,0 @@
-# Воркфлоу: EXPLORATORY — Исследовательское тестирование
-
-Свободное исследование приложения для поиска неочевидных багов, UX-проблем и аномалий, которые не покрыты формальными тест-кейсами.
-
-## Алгоритм выполнения
-
-### 0. Прочитай context.notes тикета (ОБЯЗАТЕЛЬНО)
-
-Перед началом работы проверь поле `context.notes` в frontmatter тикета. Там могут быть:
-- **Бюджет MCP-вызовов** — лимит на количество обращений к инструментам
-- **Стратегия инструментов** — какой инструмент использовать (например, snapshot вместо screenshot)
-- **Особые указания** — ссылки на обязательные knowledge-модули, ограничения окружения
-
-### 1. Определи charter (цель сессии)
-
-Из тикета извлеки или сформулируй сам:
-- **Область исследования** — какой модуль/страницу/фичу исследовать
-- **Фокус** — что именно ищем (баги, UX-проблемы, edge cases, security)
-- **Ограничение по времени** — таймбокс сессии (рекомендуется 30-60 минут)
-
-Формат charter: *«Исследовать [область] с целью обнаружить [тип проблем] используя [подход/технику]»*
-
-Пример: *«Исследовать форму оформления заказа с целью обнаружить edge cases при невалидных данных, используя boundary value analysis»*
-
-### 2. Выбери технику исследования
-
-| Техника | Когда применять |
-|---------|----------------|
-| **Freestyle** | Первичное знакомство с фичей, общий обзор |
-| **Boundary Values** | Поля ввода, числовые параметры, лимиты |
-| **Error Guessing** | Основан на опыте — что обычно ломается |
-| **Negative Testing** | Невалидные данные, пустые поля, спецсимволы |
-| **State Transitions** | Проверка переходов между состояниями (заказ: создан → оплачен → отменён) |
-| **Interruptions** | Прерывания: закрыть вкладку, потерять сеть, назад/вперёд |
-| **Cross-browser** | Проверка в разных браузерах и разрешениях |
-
-Загрузи `knowledge/test-case-design.md` для деталей по каждой технике.
-
-### 3. Проведи сессию исследования
-
-Во время сессии:
-1. Открой целевую область через подходящий инструмент — `knowledge/browser-tools.md` или `knowledge/desktop-tools-core.md`. **Desktop: загрузи `knowledge/sandbox-core.md`** — тестирование ТОЛЬКО через Sandbox
-2. Следуй выбранной технике, но не ограничивай себя ей
-3. **Фиксируй всё** — a11y tree assertions, наблюдения, подозрительное поведение
-4. При обнаружении бага — немедленно зафиксируй:
-   - A11y tree assertion (текстовое подтверждение)
-   - Точные шаги воспроизведения
-   - URL и состояние
-5. Попробуй воспроизвести баг повторно для подтверждения
-6. Записывай также «нормальное» поведение, которое кажется неочевидным
-
-### 4. Оформи находки
-
-Для каждого найденного дефекта:
-1. Минимизируй шаги воспроизведения
-2. Определи severity → `algorithms/bug-severity.md`
-3. Оформи секцию DEFECT в QA-тикете → формат `templates/bug-report.md`
-
-Для наблюдений (не баги, но стоит обратить внимание):
-- UX-неудобства
-- Несоответствия в дизайне
-- Медленные загрузки
-- Непонятные формулировки
-
-### 5. Сформируй отчёт о сессии
-
-Заполни → `templates/test-session-report.md`
-
-Включи:
-- Charter сессии
-- Затраченное время
-- Покрытые области (что успел проверить)
-- Непокрытые области (что осталось)
-- Список найденных багов с severity
-- Наблюдения и рекомендации
-
-### 6. Валидация / Чеклист
-
-- [ ] Charter сформулирован до начала тестирования
-- [ ] Каждый баг имеет evidence (a11y assertion + шаги воспроизведения)
-- [ ] Баги оформлены секциями DEFECT в QA-тикете
-- [ ] Записаны наблюдения (даже если не баги)
-- [ ] Отчёт о сессии заполнен
-- [ ] Указаны непокрытые области для будущих сессий

package/src/skills/manual-testing/workflows/regression.md

@@ -1,76 +0,0 @@
-# Воркфлоу: REGRESSION — Регрессионное тестирование
-
-Полная проверка существующей функциональности по набору тест-кейсов для уверенности, что новые изменения не сломали ранее работавшее.
-
-## Алгоритм выполнения
-
-### 0. Прочитай context.notes тикета (ОБЯЗАТЕЛЬНО)
-
-Перед началом работы проверь поле `context.notes` в frontmatter тикета. Там могут быть:
-- **Бюджет MCP-вызовов** — лимит на количество обращений к инструментам
-- **Стратегия инструментов** — какой инструмент использовать (например, snapshot вместо screenshot)
-- **Особые указания** — ссылки на обязательные knowledge-модули, ограничения окружения
-
-### 1. Определи скоуп регрессии
-
-Из тикета извлеки:
-- **Что изменилось** — какие фичи/модули затронуты
-- **Тест-сьют** — если указан конкретный набор тест-кейсов, используй его
-- **Окружение** — URL стенда, браузеры, устройства
-- **Дедлайн** — если время ограничено, используй risk-based подход
-
-### 2. Сформируй набор тест-кейсов
-
-Если тест-сьют не указан:
-1. Определи затронутые модули по описанию изменений
-2. Подбери тест-кейсы, покрывающие эти модули
-3. Добавь тест-кейсы на смежную функциональность (интеграционные точки)
-4. Приоритизируй → `algorithms/test-prioritization.md`
-
-Группируй тест-кейсы:
-- **P0** — критический путь (всегда выполняются)
-- **P1** — основные сценарии (выполняются при наличии времени)
-- **P2** — edge cases (выполняются при полной регрессии)
-
-### 3. Выполни тест-кейсы
-
-Для каждого тест-кейса:
-1. Прочитай предусловия и подготовь данные
-2. Определи инструмент (см. таблицу в SKILL.md → «Выбор инструмента»). **Desktop: загрузи `knowledge/sandbox-core.md`** — тестирование ТОЛЬКО через Sandbox
-3. Выполни шаги через выбранный инструмент — `knowledge/browser-tools.md` или `knowledge/desktop-tools-core.md`
-4. Сравни фактический результат с ожидаемым
-4. Зафиксируй статус: `PASS` / `FAIL` / `BLOCKED` / `SKIPPED`
-5. При `FAIL` — a11y assertion + шаги воспроизведения + секция DEFECT в QA-тикете → формат `templates/bug-report.md`
-
-### 4. Отслеживай прогресс
-
-Веди таблицу прогресса:
-
-| # | Тест-кейс | Приоритет | Статус | Комментарий |
-|---|-----------|-----------|--------|-------------|
-| 1 | TC-001: Логин | P0 | PASS | — |
-| 2 | TC-002: Регистрация | P0 | FAIL | DEFECT: ... |
-| 3 | ... | ... | ... | ... |
-
-### 5. Анализируй результаты
-
-После завершения всех тест-кейсов:
-- Подсчитай статистику: всего / pass / fail / blocked / skipped
-- Определи блокирующие баги (CRITICAL/HIGH severity)
-- Сформулируй вердикт:
-  - **REGRESSION PASSED** — нет FAIL на P0/P1, нет CRITICAL/HIGH багов
-  - **REGRESSION FAILED** — есть блокирующие дефекты
-  - **REGRESSION PASSED WITH ISSUES** — есть MEDIUM/LOW баги, не блокируют релиз
-
-### 6. Сформируй отчёт
-
-Заполни отчёт → `templates/test-session-report.md`
-
-### 7. Валидация / Чеклист
-
-- [ ] Все P0 тест-кейсы выполнены
-- [ ] P1 тест-кейсы выполнены (или обосновано, почему пропущены)
-- [ ] Каждый FAIL имеет секцию DEFECT в тикете с severity
-- [ ] Итоговая статистика подсчитана
-- [ ] Вердикт сформулирован
-- [ ] Отчёт заполнен

package/src/skills/manual-testing/workflows/smoke.md

@@ -1,109 +0,0 @@
-# Воркфлоу: SMOKE — Smoke-тестирование
-
-Быстрая проверка критических сценариев после деплоя или сборки для подтверждения базовой работоспособности.
-
-## Алгоритм выполнения
-
-### 0. Прочитай context.notes тикета (ОБЯЗАТЕЛЬНО)
-
-Перед началом работы проверь поле `context.notes` в frontmatter тикета. Там могут быть:
-- **Бюджет MCP-вызовов** — лимит на количество обращений к инструментам. Планируй тестирование в рамках бюджета
-- **Стратегия инструментов** — какой инструмент использовать (например, snapshot вместо screenshot)
-- **Особые указания** — ссылки на обязательные knowledge-модули, ограничения окружения
-
-**Если бюджет указан — распредели его по тест-кейсам заранее (например, 80 вызовов / 8 TC = ~10 на TC). Если при выполнении расход превышает план — переключись на экономный режим: меньше промежуточных скриншотов, используй Snapshot (с a11y tree) вместо Screenshot + угадывания координат.**
-
-### 0a. Определи предмет тестирования (ОБЯЗАТЕЛЬНО)
-
-Прежде чем начинать подготовку окружения — определи **что именно** ты тестируешь:
-
-- **UI приложения** (визуальные элементы, горячие клавиши, меню) → тестируй **через UI**: запусти приложение, используй Click/Shortcut/Snapshot. **НЕ запускай продукт из терминала** — CLI и UI это разные code paths.
-- **CLI-инструмент** → тестируй из терминала.
-- **API** → тестируй через cURL/HTTP.
-
-Загрузи `../shared/*` (product-ui-map.md) для карты UI-точек входа (команды, горячие клавиши, views). Не изобретай способ запуска — используй задокументированные точки входа.
-
-### 1. Определи скоуп
-
-Из тикета извлеки:
-- **URL окружения** — какой стенд тестировать
-- **Что задеплоено** — какие изменения вошли (PR, коммиты, фичи)
-- **Критические сценарии** — если указаны в тикете, используй их; иначе определи сам
-
-Если критические сценарии не указаны, определи их по принципу:
-- Главная страница загружается
-- Авторизация работает
-- Ключевой бизнес-flow проходит (зависит от продукта)
-- API отвечает корректно
-
-### 2. Подготовь чеклист
-
-Создай короткий чеклист из 5-15 проверок. Каждая проверка:
-
-| # | Сценарий | Ожидаемый результат | Статус |
-|---|----------|-------------------|--------|
-| 1 | Открыть главную страницу | Страница загружается, нет ошибок в консоли | — |
-| 2 | ... | ... | — |
-
-Загрузи `algorithms/test-prioritization.md` для приоритизации при ограниченном времени.
-
-### 2a. Реальные данные vs тестовые заглушки (ОБЯЗАТЕЛЬНО)
-
-Если тикет требует smoke-тест конкретного функционала продукта (не инфраструктуры тестирования), **используй реальную конфигурацию продукта**, а не тестовые заглушки. Тестовый пайплайн/заглушка может маскировать дефекты, которые проявляются только с реальными данными (имена стадий, форматы полей, маппинги).
-
-**Правило:** если smoke-чеклист тикета описывает проверку конкретных runtime-значений (иконки, статусы, форматы label), запускай продукт с реальной конфигурацией. Stub-пайплайн допустим только для проверки инфраструктуры запуска (CI, деплой, connectivity).
-
-### 3. Выполни проверки
-
-Определи тип приложения и выбери инструмент (см. таблицу в SKILL.md → «Выбор инструмента»).
-**Desktop-приложения: загрузи `knowledge/sandbox-core.md`** — тестирование ТОЛЬКО через Sandbox.
-
-Для каждого сценария:
-1. Открой целевое приложение (браузер или desktop)
-2. Выполни действия (клики, ввод данных)
-3. Проверь ожидаемый результат. **Если элемент находится в списке, dropdown или скроллируемой области — прокрути в обоих направлениях (вверх И вниз), прежде чем делать вывод об отсутствии.** Dropdown может быть открыт в середине или в конце списка — элемент может находиться **выше** текущей видимой области. Не утверждай «элемента нет», если не просмотрел список полностью в обе стороны
-4. Запиши a11y tree assertion (текстовое подтверждение результата)
-5. Запиши статус: `PASS` / `FAIL` / `BLOCKED`
-
-Загрузи `knowledge/browser-tools.md` или `knowledge/desktop-tools-core.md` для справки по командам.
-
-### 3a. Budget Guard (ОБЯЗАТЕЛЬНО при наличии бюджета)
-
-Если в `context.notes` указан бюджет MCP-вызовов — **отслеживай расход**:
-
-- Если потрачено **>50% бюджета** и выполнено **<50% TC** — немедленно переключись в экономный режим: пометь текущий TC как OBSERVATION/BLOCKED и переходи к следующему. Не уходи в расследование причин (создание дополнительных тест-файлов, перебор форматов, многократный Refresh и т.д.)
-- **Жёсткий порог:** TC > 12 MCP-вызовов = **BLOCKED**, без исключений. Зафиксируй что наблюдалось и переходи к следующему TC
-- **Rabbit hole detection:** текущее действие не входит в шаги TC? → СТОП. Расследование инфраструктуры, создание собственных инструментов, установка CLI при UI-тестировании — всё это rabbit holes. Подробнее: `algorithms/mcp-budget.md` → «Rabbit hole detection»
-- **Rabbit hole индикатор:** 3+ MCP-вызова на один и тот же элемент UI (повторный Snapshot/Refresh/Click без изменения результата) = остановись
-
-### 4. При обнаружении FAIL
-
-1. Зафиксируй a11y tree assertion проблемы
-2. Проверь консоль браузера / Developer Console на ошибки
-3. Запиши минимальные шаги воспроизведения
-4. Оформи секцию DEFECT в QA-тикете → формат `templates/bug-report.md`
-5. Определи severity → `algorithms/bug-severity.md`
-
-### 4a. Если DoD/тикет не совпадает с реальностью, но реальность корректна
-
-Бывает, что ожидаемый результат в DoD или тикете ошибочен. Если реальное поведение **корректно**, а неправ тикет:
-
-- Отметь тест-кейс как **OBSERVATION** (не FAIL)
-- В комментарии укажи: «Реальность корректна, DoD/тикет содержит неточность. Рекомендация: обновить [что именно]»
-- **Не создавай баг-репорт** — это не баг продукта
-
-### 5. Сформируй отчёт
-
-Заполни отчёт → `templates/test-session-report.md`
-
-Обязательно включи:
-- Окружение (URL, браузер, дата/время)
-- Таблицу результатов по каждому сценарию
-- Итоговый вердикт: **SMOKE PASSED** / **SMOKE FAILED**
-- Список зафиксированных дефектов (если есть)
-
-### 6. Валидация / Чеклист
-
-- [ ] Все критические сценарии проверены
-- [ ] Каждый FAIL имеет evidence (a11y assertion + шаги) и секцию DEFECT в тикете
-- [ ] Отчёт заполнен с итоговым вердиктом

package/src/skills/manual-testing/workflows/test-plan.md

@@ -1,75 +0,0 @@
-# Воркфлоу: TEST-PLAN — Создание тест-плана
-
-Создание тест-плана и набора тест-кейсов для фичи, модуля или релиза.
-
-## Алгоритм выполнения
-
-### 0. Прочитай context.notes тикета (ОБЯЗАТЕЛЬНО)
-
-Перед началом работы проверь поле `context.notes` в frontmatter тикета. Там могут быть:
-- **Особые указания** — ссылки на обязательные knowledge-модули, ограничения
-- **Scope уточнения** — что включить/исключить из тест-плана
-
-### 1. Собери входные данные
-
-Из тикета извлеки:
-- **Что тестируем** — фича, модуль, эпик, релиз
-- **Требования / User Stories** — на основе чего строить тест-кейсы
-- **Scope** — что входит и что НЕ входит в тестирование
-- **Окружение** — браузеры, устройства, стенды
-- **Ограничения** — время, ресурсы, зависимости
-
-### 2. Определи стратегию тестирования
-
-Загрузи `knowledge/testing-types.md` и выбери подходящие типы:
-
-| Тип тестирования | Применимость | Обоснование |
-|-----------------|-------------|-------------|
-| Smoke | Да/Нет | ... |
-| Functional | Да/Нет | ... |
-| Cross-browser | Да/Нет | ... |
-| Accessibility | Да/Нет | ... |
-| ... | ... | ... |
-
-### 3. Спроектируй тест-кейсы
-
-Для каждого требования / user story:
-1. Извлеки acceptance criteria
-2. Примени техники проектирования → `knowledge/test-case-design.md`
-3. Создай тест-кейсы → `templates/test-case.md`
-
-Техники проектирования:
-- **Equivalence Partitioning** — для полей ввода
-- **Boundary Value Analysis** — для числовых ограничений
-- **Decision Table** — для комбинаций условий
-- **State Transition** — для объектов с состояниями
-
-### 4. Приоритизируй тест-кейсы
-
-Загрузи `algorithms/test-prioritization.md` и присвой приоритеты:
-
-- **P0 (Critical)** — если падает, релиз невозможен
-- **P1 (High)** — основные сценарии, должны быть протестированы
-- **P2 (Medium)** — edge cases и secondary flows
-- **P3 (Low)** — nice-to-have, cosmetic
-
-### 5. Оформи тест-план
-
-Заполни → `templates/test-plan.md`
-
-Включи:
-- Scope и out-of-scope
-- Стратегию тестирования
-- Матрицу окружений (браузеры × устройства)
-- Полный список тест-кейсов с приоритетами
-- Критерии входа и выхода
-- Риски и митигации
-
-### 6. Валидация / Чеклист
-
-- [ ] Каждое требование покрыто хотя бы одним тест-кейсом
-- [ ] Тест-кейсы содержат конкретные тестовые данные (не «валидный email», а «user@test.com»)
-- [ ] Приоритеты проставлены для всех тест-кейсов
-- [ ] Есть негативные сценарии, не только happy path
-- [ ] Scope и out-of-scope чётко определены
-- [ ] Тест-план заполнен по шаблону

package/src/skills/review-result/README.md

@@ -1,59 +0,0 @@
-# review-result
-
-Скил ревью результата выполнения задачи. Проверяет соответствие результата критериям готовности (Definition of Done) из тикета и верифицирует реальность артефактов.
-
-## Структура
-
-```
-review-result/
-├── SKILL.md                          # Ядро: роль, принципы, таблицы загрузки
-├── README.md                         # Документация (этот файл)
-├── workflows/
-│   └── review.md                     # Основной воркфлоу проверки результата
-├── knowledge/
-│   └── dod-patterns.md               # Паттерны DoD по типам тикетов
-└── algorithms/
-    └── verification.md               # Алгоритм верификации реальных изменений
-```
-
-## Как это работает
-
-1. Тикет перемещается в `review/`
-2. Скил загружает `workflows/review.md`
-3. Быстрый выход: если последнее ревью `passed` или `skipped` → сразу `passed`
-4. Парсинг DoD из тикета
-5. Для каждого пункта DoD — определение типа проверки (по `knowledge/dod-patterns.md`)
-6. Сверка Result с требованиями
-7. Верификация файлов (по `algorithms/verification.md`) для нечеловеческих исполнителей
-8. Вердикт: `passed` или `failed` + issues
-9. Запись результата ревью в таблицу тикета
-
-**Принцип Evidence-Based:** каждый `[x]` в DoD подтверждается реальным артефактом.
-
-## Как расширять
-
-### Добавить новый knowledge-модуль
-
-1. Создай файл в `knowledge/` с маркером `<!-- РАСШИРЕНИЕ: ... -->`
-2. Добавь запись в таблицу «Загрузка знаний» в `SKILL.md`
-
-### Добавить новый паттерн DoD
-
-1. Добавь строку в соответствующую таблицу типа тикета в `knowledge/dod-patterns.md` после маркера расширения
-
-### Добавить новый шаг верификации
-
-1. Добавь шаг в `algorithms/verification.md`
-2. При необходимости добавь граничный случай в таблицу
-
-### Добавить новый тип проверки
-
-1. Опиши тип в `workflows/review.md` → таблица «Тип проверки»
-2. Добавь паттерн в `knowledge/dod-patterns.md`
-
-## Примеры расширений
-
-**Новый knowledge: «risk-areas.md»**
-- Создать `knowledge/risk-areas.md` — области повышенного риска, требующие дополнительных проверок
-- Добавить в таблицу загрузки SKILL.md: «При ревью тикетов в критических модулях»
-- В `workflows/review.md` — добавить шаг проверки risk-areas между 3 и 3.5