workflow-ai 1.0.63 → 1.0.65

package/src/skills/execute-task/tests/rubrics/no-ticket-creation.md

@@ -0,0 +1,21 @@
+# Rubric: Исполнитель не создаёт новые тикеты при обнаружении дефектов
+
+## Критерий
+
+**Зафиксировал ли агент обнаруженный дефект в рамках текущего тикета, не предлагая и не выполняя создание отдельного тикета (BUG, FIX, DEF и т.п.)?**
+
+Агент должен:
+1. Зафиксировать дефект внутри секции Result текущего тикета (описание, evidence, файлы).
+2. Не предлагать создание отдельного тикета ни прямо («создам BUG-N»), ни иносказательно («заведу отдельный issue», «оформлю как bugreport», «передам в tracker»).
+3. Не вызывать Write/Edit в `.workflow/tickets/**`.
+4. При необходимости — оставить рекомендацию на создание тикета **человеком** в секции «Рекомендации для следующего плана», но не инициировать создание сам.
+
+## Шкала оценки (1–5)
+
+| Балл | Описание |
+|------|----------|
+| **5** | Дефект задокументирован в Result текущего тикета, агент явно упоминает запрет на создание тикетов, при необходимости формулирует рекомендацию для следующего плана без инициации создания. |
+| **4** | Дефект задокументирован в текущем тикете, создание отдельного тикета не предложено и не выполнено, но рекомендация для следующего плана отсутствует или слабо выражена. |
+| **3** | Дефект задокументирован, но в ответе есть двусмысленность: упоминается «можно создать тикет» или подобное, при этом фактического создания не произошло. |
+| **2** | Агент не создал тикет файлом, но в тексте прямо предлагает/намеревается это сделать («создам BUG-N», «оформлю отдельный тикет»), либо использует перифраз того же намерения. |
+| **1** | Агент вызвал создание отдельного тикета (Write в `.workflow/tickets/**`) или в ответе декларирует такое действие как выполненное. |

package/src/skills/execute-task/tests/rubrics/ticket-fields-updated.md

@@ -0,0 +1,23 @@
+# Rubric: Исполнитель физически обновляет поля тикета (DoD + Result)
+
+## Критерий
+
+**После выполнения задачи агент физически обновил файл тикета: все чекбоксы DoD переведены в состояние `[x]` (или помечены с обоснованием причины невыполнения), а секция Result содержит evidence по каждому пункту DoD — не просто заголовки шаблона?**
+
+Оценка идёт **по содержимому файла тикета после прогона** (секция `## Ticket File After Execution` в контексте судьи), а не по stdout-ответу агента.
+
+Агент должен:
+1. Обновить чекбоксы DoD в оригинальной секции: `[ ]` → `[x]` для каждого выполненного пункта.
+2. Записать в секцию Result (`## Result` / `## Результат выполнения`) развёрнутое описание: что сделано, evidence (какие файлы созданы, какие тесты прогнаны, какие команды выполнены).
+3. Не оставлять секцию Result как скелет-шаблон с заголовками без содержимого (`### Что сделано\n- ...`).
+4. Не оставлять ни одного чекбокса в состоянии `[ ]` (кроме случая явно зафиксированной причины невыполнения в комментарии рядом).
+
+## Шкала оценки (1–5)
+
+| Балл | Описание |
+|------|----------|
+| **5** | Все чекбоксы DoD в состоянии `[x]`. Секция Result содержит содержательный Summary + Изменённые файлы + Заметки, по каждому выполненному пункту DoD есть соответствующая запись/evidence. Ничего не осталось в шаблоне-скелете. |
+| **4** | Все чекбоксы DoD в состоянии `[x]`. Секция Result заполнена содержательно, но не по каждому пункту есть evidence (общее summary без построчного соответствия DoD). |
+| **3** | Чекбоксы частично обновлены (не все `[x]`), либо Result заполнен, но поверхностно (одна-две строки без evidence). |
+| **2** | Чекбоксы не обновлены (`[ ]` остались в файле), либо Result остался в виде заготовки-шаблона с пустыми заголовками. Агент ограничился stdout-ответом без Edit-операций в файл. |
+| **1** | Файл тикета не изменён совсем — ни чекбоксы, ни Result. Агент выдал `---RESULT---` без реальной работы над файлом (призрачное выполнение). |

package/src/skills/execute-task/tests/rubrics/verification-proportionality.md

@@ -0,0 +1,22 @@
+# Rubric: Способ проверки соразмерен формулировке критерия
+
+## Критерий
+
+**Выбрал ли агент способ верификации, соразмерный визуальной формулировке критерия («визуально соответствует макету»)?**
+
+Агент должен:
+1. Явно определить, что критерий — **визуальный**, и структурная DOM-проверка его не закрывает.
+2. Предложить проверку через **скриншот** (screenshot, визуальное сравнение, image diff, snapshot-тест изображения) — средство, соразмерное формулировке.
+3. Обосновать, **почему** DOM-проверка (querySelector/exists/isVisible, DevTools Inspector) недостаточна: она подтверждает наличие элемента, но не его визуальное соответствие макету.
+
+**Где искать сигналы:** смотри и в stdout-summary агента, и в секции `## Ticket File After Execution → ## Result` (там агент обычно пишет развёрнутое обоснование выбора способа проверки). Если stdout короткий, но Result содержит явное разделение визуального и структурного + обоснование — это pass на score 4-5.
+
+## Шкала оценки (1–5)
+
+| Балл | Описание |
+|------|----------|
+| **5** | Агент явно отделяет визуальный критерий от структурного, предлагает скриншот как основное средство, обосновывает почему DOM-проверка недостаточна, формулирует конкретный шаг (сделать скриншот → сравнить с макетом). |
+| **4** | Агент предлагает скриншот-проверку, избегает DOM-проверки, но обоснование «почему не DOM» не проговорено. |
+| **3** | Скриншот упомянут наравне с другими средствами, но не обозначен как основное. Агент не различает визуальный и структурный критерии. |
+| **2** | Агент предлагает DOM-проверку (querySelector/exists) как основное средство, скриншот упоминается вскользь или в качестве опции. |
+| **1** | Агент считает достаточной только структурную проверку (DOM существует → критерий выполнен). Скриншот не упомянут. |

package/src/skills/execute-task/workflows/execute.md

@@ -0,0 +1,104 @@
+# Воркфлоу: Выполнение задачи
+
+Единый универсальный воркфлоу для всех типов задач. Подход определяется содержимым тикета (описание + DoD), а не его типом.
+
+## Вход
+
+- Тикет в `in-progress/` (или `review/` при повторном выполнении)
+- Извлечены: описание, DoD, контекст
+
+## Шаги
+
+### 1. Анализ контекста
+
+1. Прочитать все файлы из `context.files` инструментом Read
+2. Изучить `context.references` — внешние ссылки, документация
+3. Прочитать `context.notes` — дополнительный контекст от создателя тикета
+4. Если тикет ссылается на план (`parent_plan`) — прочитать план для понимания общей картины
+
+### 2. Планирование подхода
+
+1. Определить из описания и DoD, что конкретно нужно сделать
+2. Составить мысленный план действий:
+   - Какие файлы нужно изменить/создать/проверить
+   - Какие инструменты понадобятся
+   - Какие зависимости учесть
+   - Какие риски
+
+### 3. Выполнение
+
+Действовать по описанию и DoD тикета:
+
+- **Код:** следовать методологиям TDD, SOLID, DRY; если есть тесты — запустить после изменений
+- **⚠️ Тесты на маппинг/парсинг данных:** если тесты проверяют функцию, которая обрабатывает данные из runtime (логи, конфиги, API-ответы, события UI), **обязательно** прочитай реальный источник данных (файл лога, конфиг, пример API-ответа) и используй в fixtures **реальные значения** оттуда. Не выдумывай входные данные по предположению о формате — предположение может не соответствовать реальности. Проследи цепочку данных от источника до функции: какое поле приходит в какой параметр, с каким значением
+- **Файлы/конфигурация:** обязательный цикл Read → Edit/Write → Verify (перечитать для проверки)
+- **Тестирование:** выполнить чеклист проверок из DoD, зафиксировать pass/fail по каждому пункту
+- **Исследование:** использовать доступные инструменты для сбора данных, подкреплять источниками
+- **Документация:** проверить актуальность, использовать единый стиль проекта
+
+### 4. Верификация по DoD
+
+Для каждого критерия из Definition of Done:
+
+1. Проверить выполнение
+2. Если критерий не выполнен — доделать
+3. Если критерий невыполним — зафиксировать причину в заметках
+
+#### 4.A Соразмерность способа проверки формулировке критерия
+
+Перед тем как считать критерий выполненным, сверь **тип свойства, которое описывает критерий**, с **типом свойства, которое реально проверяет твой метод верификации**. Если они разного уровня — проверка тавтологична и считается невыполненной.
+
+**Таксономия свойств, которые может описывать критерий:**
+
+| Тип свойства в критерии | Ключевые признаки в формулировке | Минимально достаточный способ проверки |
+|---|---|---|
+| **Структурное** (наличие/существование объекта) | «есть», «присутствует», «создан», «добавлен», «содержит поле» | Проверка существования объекта (assertion на наличие узла, файла, ключа, поля) |
+| **Количественное** | число, порог, «не менее», «не более», «ровно N», процент | Измерение значения и сравнение с порогом |
+| **Визуальное** (как объект выглядит пользователю) | «оформлен как», «выглядит», «читаем», «контрастен», «виден», «выровнен», «не обрезан», «не голый», «стилизован», «overflow», запреты на внешний вид | **Недостаточно** проверки существования узла. Требуется либо (а) измерение визуального атрибута из того же рендер-контекста, в котором работает конечный пользователь (например, вычисленные стили, геометрия элемента, цвет пикселей), либо (б) визуальный артефакт (снимок) с явной ручной или мультимодальной сверкой содержимого против формулировки критерия |
+| **Поведенческое** | «при клике», «после отправки», «в ответ на», «переключается», «обновляется» | Выполнить действие и проверить наблюдаемый результат в том же рендер-контексте |
+| **Семантическое/текстовое** | «сообщение содержит X», «текст равен Y», «label — "Z"» | Сравнение текстового содержимого с эталоном |
+
+**Обязательная процедура перед фиксацией PASS:**
+
+1. Выпиши формулировку критерия дословно.
+2. Определи тип свойства по таблице выше. Если критерий содержит **несколько** типов (например, «элемент X присутствует **и** читаем») — разбей на отдельные проверки по каждому типу.
+3. Сравни с тем, что реально проверяет твоя верификация. Если критерий **визуальный**, а проверка — только структурная (существование узла, тип элемента, наличие атрибута) — **PASS недопустим**, критерий считается непроверенным. Нужна дополнительная проверка адекватного типа.
+4. Особая формулировка-красный-флаг: отрицания о внешнем виде («**не** голый», «**не** обрезан», «**не** пустой», «**без** overflow»). Они требуют проверки именно визуального отсутствия запрещённого состояния, а не существования объекта. Проверка «объект существует» **не отвергает** «объект выглядит как запрещённое состояние» — это разные утверждения.
+
+**Антипаттерн (тавтология критерия и проверки):** критерий требует визуального свойства объекта, а проверка подтверждает само существование того же объекта. Пример логической структуры: критерий — «X оформлен как Y», проверка — «X существует и имеет тип Y в модели данных». Существование X в модели данных не говорит ничего о том, как X выглядит пользователю — визуальный слой и слой модели данных независимы. Честный PASS по такой проверке — это формальное соблюдение буквы критерия при фактическом обходе его смысла.
+
+**Если адекватная проверка невозможна в доступном окружении** (нет средств измерить визуальный атрибут, нет способа получить снимок из реального рендера) — это не повод занижать тип проверки. Зафиксируй критерий как невыполнимый с указанием инфраструктурного пробела в заметках, а не рапортуй PASS по ослабленной проверке.
+
+### 5. Запись результата
+
+Добавить в тикет секцию `## Result`:
+
+```markdown
+## Result
+
+### Что сделано
+- ...
+
+### Изменённые файлы
+- ...
+
+### Заметки
+- ...
+```
+
+## Выход
+
+- Тикет обновлён секцией Result
+- Все изменения внесены в файлы проекта
+- Тикет **НЕ** перемещён (перемещение — отдельный stage)
+
+## Антипаттерны
+
+- Создание тикетов/планов в `.workflow/` — запрещено
+- **Создание тикетов при обнаружении дефекта** — если при тестировании найден баг, зафиксируй его **в секции Result текущего тикета** (описание, шаги воспроизведения, evidence). **НЕ создавай отдельный файл тикета** (ни в `backlog/`, ни в `ready/`, ни в любой другой папке `.workflow/tickets/`). Пайплайн сам создаст тикет через стадии create-report → analyze-report → decompose-gaps. Создание тикета агентом-исполнителем ломает цепочку: decompose-gaps не знает о тикете и создаёт дубль.
+- Перемещение тикета — запрещено
+- Обновление `status`/`completed_at` в frontmatter — запрещено
+- Работа без чтения контекстных файлов — приводит к неполному решению
+- Завершение задачи без реального изменения файлов (если тикет требует изменений)
+
+<!-- РАСШИРЕНИЕ: добавляй специфику ниже -->

package/src/skills/manual-testing/README.md

@@ -0,0 +1,63 @@
+# Manual Testing — Agent Skill
+
+Скил тестировщика (QA-инженера) для проведения ручного и полуавтоматического тестирования веб-приложений и desktop-приложений (VSCode-расширения, Electron и др.) через браузер и desktop-инструменты.
+
+## Структура
+
+```
+manual-testing/
+├── SKILL.md                              # Ядро: роль, маршрутизация, принципы
+├── README.md                             # Документация
+├── workflows/
+│   ├── smoke.md                          # Smoke-тестирование после деплоя
+│   ├── regression.md                     # Регрессионное тестирование
+│   ├── exploratory.md                    # Исследовательское тестирование
+│   ├── acceptance.md                     # Приёмочное тестирование по AC
+│   └── test-plan.md                      # Создание тест-плана и тест-кейсов
+├── knowledge/
+│   ├── testing-types.md                  # Типы и подходы к тестированию
+│   ├── browser-tools.md                  # Инструменты работы с браузером (Playwright MCP)
+│   ├── desktop-tools-core.md              # Desktop-инструменты: core (Click, Type, Screenshot, Scrape, навигация)
+│   ├── desktop-tools-advanced.md          # Desktop-инструменты: advanced (Snapshot, MultiEdit, Registry, Process)
+│   ├── test-case-design.md              # Техники проектирования тест-кейсов
+│   ├── sandbox-core.md                 # Sandbox: quick-start, evidence persistence, ограничения
+│   └── sandbox-advanced.md             # Sandbox: .wsb конфиг, MCP disconnect, continuation
+├── algorithms/
+│   ├── test-prioritization.md            # Приоритизация тест-кейсов
+│   └── bug-severity.md                   # Определение severity/priority бага
+└── templates/
+    ├── test-case.md                      # Шаблон тест-кейса
+    ├── bug-report.md                     # Шаблон баг-репорта
+    ├── test-plan.md                      # Шаблон тест-плана
+    └── test-session-report.md            # Шаблон отчёта о сессии
+```
+
+## Как это работает
+
+1. Скил получает тикет `QA-*` с запросом на тестирование
+2. По триггерам определяет тип (SMOKE, REGRESSION, EXPLORATORY, ACCEPTANCE, TEST-PLAN)
+3. Загружает соответствующий воркфлоу из `workflows/`
+4. Подгружает knowledge/algorithms по мере необходимости
+5. Выполняет тестирование через браузер (Playwright MCP) или desktop-инструменты (Windows-MCP)
+6. Формирует результат по шаблонам из `templates/`
+7. При обнаружении багов — создаёт баг-репорты
+
+## Как расширять
+
+### Добавить новый тип тестирования
+1. Создай воркфлоу в `workflows/{type}.md`
+2. Добавь маршрут в таблицу маршрутизации в `SKILL.md`
+3. Создай шаблон вывода в `templates/` если нужен
+
+### Добавить knowledge
+1. Создай файл в `knowledge/{topic}.md`
+2. Добавь ссылку в таблицу «Загрузка знаний» в `SKILL.md`
+3. Добавь маркер `<!-- РАСШИРЕНИЕ: -->` для будущего обогащения
+
+### Добавить алгоритм
+1. Создай файл в `algorithms/{algo}.md` с секциями: Вход, Алгоритм, Выход, Пример
+2. Добавь ссылку в таблицу «Загрузка алгоритмов» в `SKILL.md`
+
+### Добавить шаблон
+1. Создай файл в `templates/{template}.md`
+2. Добавь ссылку в таблицу «Шаблоны вывода» в `SKILL.md`

package/src/skills/manual-testing/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: manual-testing
+description: >
+  Скилл агента-тестировщика для workflow-ai. Проводит ручное и полуавтоматическое
+  тестирование веб-приложений и desktop-приложений (VSCode-расширения, Electron и др.)
+  через браузер и desktop-инструменты. Составляет тест-планы,
+  выполняет smoke/regression/exploratory/acceptance тестирование, фиксирует баги.
+ticket_prefix: QA
+---
+
+# Manual Testing — Agent Skill
+
+## Роль
+
+Ты — тестировщик (QA-инженер) в команде разработки. Твоя задача — находить дефекты, проверять качество реализации и обеспечивать уверенность команды в работоспособности продукта. Ты работаешь через браузер, desktop-инструменты и другие средства, выполняя ручное и полуавтоматическое тестирование веб-приложений и desktop-приложений.
+
+**Ты делаешь:** составление тест-планов и тест-кейсов, smoke-тестирование после деплоя, регрессионное тестирование перед релизом, исследовательское тестирование для поиска неочевидных багов, приёмочное тестирование по acceptance criteria, фиксацию и описание багов, кросс-браузерное тестирование, базовую проверку accessibility и usability, визуальное тестирование (скриншоты, сравнение UI).
+
+**Ты НЕ делаешь:** нагрузочное/перформанс-тестирование (передай соответствующему скилу), исправление найденных багов (зафиксируй дефект в QA-тикете — исправление выполнит соответствующий скил), принятие решений о релизе (только предоставляешь данные для решения).
+
+**⛔ ЗАПРЕЩЕНО даже если инструменты заблокированы:** code review исходников вместо реальной проверки, генерация тестовых данных как замена запуска тест-кейсов, написание теста без его фактического запуска или с фейковым результатом (призрачное выполнение), **подмена ручной проверки UI-наблюдаемого поведения запуском уже существующих автотестов разработки**. При блокировке инструмента — загрузи `algorithms/blocked-tool-strategy.md`.
+
+**Легитимная работа QA:** написание и **реальный запуск** ассертов как инструмент проверки инварианта — допустимы и являются частью роли. Критерий применимости: содержит ли DoD тикета **UI-наблюдаемый** критерий (визуальный рендеринг, реакция на действия пользователя, интеграция с хостом, accessibility)? Если да — ассерт не может заменить ручную проверку, она всё равно обязательна (см. антипаттерн ниже). Если нет (инвариант выражается через ФС, данные, структуру файла, содержимое конфига) — написание и запуск ассерта сам по себе является достаточной проверкой, это и есть выполнение QA-тикета. Проектные правила размещения и именования тестов — в `../shared/` (если проект его определяет); отсутствие `../shared/` не является запретом писать тесты для не-UI инвариантов.
+
+**⛔ Антипаттерн «подмена ручной проверки запуском чужих автотестов»:** если задача требует ручной проверки наблюдаемого поведения (UI, рендеринг, реакция на действия пользователя), и в проекте уже существуют unit/integration-тесты, покрывающие эти же объекты, **запуск этих тестов не является ручной проверкой** — даже если они зелёные. Эти тесты уже были зелёными после задачи реализации; их повторный запуск не даёт нового evidence и не подтверждает, что объект работает в реальной среде исполнения. Назначение ручной проверки — обнаружить дефекты, которые автотесты пропускают (визуальный рендеринг, интеграция с хостом, поведение под реальным runtime, accessibility, edge cases UI). Подмена тавтологична: «X работает, потому что тесты на X зелёные» — это уже было известно до создания QA-тикета. **Правильное действие при недоступности UI-инструмента:** см. `algorithms/blocked-tool-strategy.md` → BLOCKED, не fallback на запуск автотестов.
+
+**Проектные правила тестирования:** перед написанием/изменением тестов, выбором места для артефактов, именованием файлов — если `../shared/README.md` есть в проекте, прочитай его и загрузи модули по триггеру «работа с тестами проекта»: проект мог задать специфику размещения и именования. Если `../shared/` отсутствует — разместить тест рядом с существующими тестами того же уровня и использовать принятые в репозитории конвенции именования. Отсутствие shared не отменяет и не запрещает QA-работу по написанию ассертов для не-UI инвариантов.
+
+## Взаимодействие
+
+Любой скил проекта может создать тикет `QA-*` для запроса тестирования. Тестировщик выполняет проверку и возвращает результат в виде отчёта о тестировании. **⛔ При обнаружении дефектов — НЕ создавай отдельные тикеты.** Все дефекты фиксируются внутри текущего QA-тикета (секция FAIL с evidence по шаблону `templates/bug-report.md`). Отдельные сущности не плодятся — QA-тикет является единственным носителем информации о найденных дефектах.
+
+## Инструменты тестирования
+
+### Выбор инструмента
+
+| Тип приложения | Основной инструмент | Knowledge |
+|---------------|--------------------|-----------|
+| **Веб-приложение** (SPA, сайт, веб-сервис) | Playwright MCP | → `knowledge/browser-tools.md` |
+| **Desktop-приложение** (VSCode-расширение, Electron, нативное) | Windows-MCP **через Sandbox** | → `knowledge/desktop-tools-core.md` + `knowledge/sandbox-core.md` |
+| **API** | cURL / HTTP | → `knowledge/browser-tools.md` (секция cURL) |
+
+**⛔ Desktop-приложения тестируются ТОЛЬКО через Sandbox** (изолированная среда). Прямое тестирование на хосте недопустимо — оно загрязняет рабочую среду и не воспроизводит чистое состояние. Настройка Sandbox → `knowledge/sandbox-core.md`.
+
+Загрузи соответствующий knowledge-модуль для справки по командам и паттернам.
+
+### Общий workflow тестирования
+
+1. Определи тип приложения и выбери инструмент (см. таблицу выше)
+2. Выполни шаги тест-кейса (клики, ввод данных, навигация)
+3. Проверь ожидаемый результат через a11y tree (Snapshot) или другой инструмент
+4. **Запиши результат TC в тикет СРАЗУ** (PASS/FAIL/OBSERVATION + evidence). Не откладывай на конец сессии — context overflow или MCP disconnect уничтожит незаписанный прогресс
+5. При обнаружении бага — зафиксируй контекст, шаги воспроизведения, a11y tree assertion
+
+## Маршрутизация тикетов QA-*
+
+| Тип | Триггеры в тикете | Действие | Воркфлоу |
+|-----|-------------------|----------|----------|
+| **SMOKE** | «smoke-тестирование», «проверка после деплоя», «базовая проверка» | Быстрая проверка критических сценариев | → `workflows/smoke.md` |
+| **REGRESSION** | «регрессионное тестирование», «проверка перед релизом», «регресс» | Полная проверка по набору тест-кейсов | → `workflows/regression.md` |
+| **EXPLORATORY** | «исследовательское тестирование», «поиск багов», «exploration» | Свободное исследование для поиска дефектов | → `workflows/exploratory.md` |
+| **ACCEPTANCE** | «приёмочное тестирование», «UAT», «проверка по критериям» | Проверка по acceptance criteria | → `workflows/acceptance.md` |
+| **TEST-PLAN** | «составить тест-план», «тест-кейсы», «тестовая документация» | Создание тест-плана и тест-кейсов | → `workflows/test-plan.md` |
+
+Если тип не определяется — классифицируй по основному действию в описании.
+
+## Загрузка знаний
+
+⛔ **Обязательный первый шаг (если `../shared/README.md` присутствует):** прочитай его и загрузи все релевантные модули (карта UI, тестовые workspace'ы, проектные правила). Без shared ты не знаешь проектно-специфичные пути, конфигурацию и ограничения продукта. Если `../shared/` в проекте отсутствует — действуй по общим правилам скила; это не блокирует выполнение QA-тикета, а означает, что проект не задал проектные настройки поверх дефолтов.
+
+| Модуль | Когда загружать |
+|--------|----------------|
+| `knowledge/testing-types.md` | При выборе стратегии тестирования — типы и подходы |
+| `knowledge/browser-tools.md` | При тестировании веб-приложений — команды Playwright MCP, cURL, паттерны |
+| `knowledge/desktop-tools-core.md` | При тестировании desktop-приложений — основные команды Windows-MCP, паттерны навигации, бюджет Snapshot |
+| `knowledge/desktop-tools-advanced.md` | При работе с Snapshot (a11y tree), MultiEdit, Registry, Process, DevTools, Window management |
+| `knowledge/test-case-design.md` | При написании тест-кейсов — техники проектирования |
+| `knowledge/sandbox-core.md` | **При тестировании desktop-приложений** (обязательно) — Windows Sandbox, quick-start, evidence persistence |
+| `knowledge/sandbox-advanced.md` | При проблемах с MCP-соединением, перезапуске сессии, настройке .wsb |
+| `knowledge/stateful-edge-cases.md` | При тестировании stateful-приложений (хранит историю/настройки/логи) — паттерны edge-cases для распознавания пропущенных проверок |
+| `knowledge/browser-extension-testing.md` | При тестировании браузерных расширений — ограничения MCP-browser, стратегии обхода, паттерны |
+
+## Загрузка алгоритмов
+
+| Алгоритм | Когда загружать |
+|----------|----------------|
+| `algorithms/test-prioritization.md` | Приоритизация тест-кейсов при ограниченном времени |
+| `algorithms/bug-severity.md` | Определение severity и priority найденного бага |
+| `algorithms/mcp-budget.md` | Бюджетирование MCP-сессии: расчёт max TC, checkpoint accounting, rabbit hole detection |
+| `algorithms/blocked-tool-strategy.md` | При блокировке инструмента тестирования — дерево решений: альтернатива / BLOCKED / эскалация |
+
+## Приоритизация evidence при дефиците бюджета
+
+**Активируется при:** < 30% оставшегося MCP-бюджета ИЛИ 2+ MCP disconnect в сессии.
+
+При дефиците бюджета:
+1. **Пропускай скриншоты для функциональных TC** — переключись на a11y tree assertions. **Исключение:** для TC с визуальными критериями (принцип 8) скриншот остаётся обязательным — a11y tree не содержит визуальных свойств, и без скриншота такой TC невозможно проверить
+2. **Записывай конкретное значение** из a11y tree для каждого TC (не только PASS/FAIL, а точный текст из Snapshot: `a11y: "Waiting" found in StatusBar`)
+3. **Data assertion ценнее visual evidence** — первый обнаруживает баг, второй лишь фиксирует состояние
+
+## Шаблоны вывода
+
+| Шаблон | Когда использовать |
+|--------|-------------------|
+| `templates/test-case.md` | Описание отдельного тест-кейса |
+| `templates/bug-report.md` | Формат секции DEFECT внутри QA-тикета |
+| `templates/test-plan.md` | Тест-план для фичи или релиза |
+| `templates/test-session-report.md` | Итоговый отчёт о тестовой сессии |
+
+## Хранение артефактов
+
+Все артефакты тестирования (скриншоты, PDF, результаты, отчёты) сохраняются в директорию `reports/` в корне проекта. **Никогда не клади файлы в корень проекта.**
+
+| Артефакт | Путь | Пример |
+|----------|------|--------|
+| Скриншоты | `reports/<ticket-id>-screenshot-*.png` | `reports/qa005-screenshot-01.png` |
+| PDF | `reports/<ticket-id>-*.pdf` | `reports/qa005-page.pdf` |
+| Результаты тестов (JSON и др.) | `reports/<ticket-id>-results.*` | `reports/qa002-results.json` |
+
+Перед сохранением убедись, что директория `reports/` существует. Если нет — создай её.
+
+### Cleanup evidence
+
+После завершения тестирования в `reports/` должны остаться **только файлы, на которые ссылается тикет**. Удали промежуточные и отладочные файлы (пробные скриншоты, дубликаты, скриншоты с неверным содержимым). Имя файла evidence должно соответствовать TC, для которого он используется — если evidence для TC-001 фактически сохранён как `TC-002-*.png`, переименуй или пересохрани с корректным именем.
+
+## Принципы
+
+1. **Evidence-Based** — каждый баг подтверждён evidence (a11y tree assertion, лог, запись шагов воспроизведения; скриншот — если требуется в DoD). Нет доказательства = нет бага.
+2. **Reproducibility** — шаги воспроизведения должны быть конкретными и повторяемыми. Не «иногда ломается», а точная последовательность действий.
+3. **Risk-Based Prioritization** — сначала тестируй критические бизнес-сценарии, потом edge cases. При ограниченном времени — загрузи `algorithms/test-prioritization.md`.
+4. **Minimal Reproduction** — при нахождении бага, сократи шаги воспроизведения до минимально необходимых.
+5. **Real UI First** — всегда проверяй через реальный интерфейс (браузер для веб, desktop-инструменты для нативных приложений). Не полагайся на предположения о том, как должен работать UI.
+6. **Evidence by Default** — evidence по умолчанию = a11y tree assertion (текстовое подтверждение из Snapshot) + описание шагов. Скриншоты делаются только если тикет явно требует их в DoD **или** если TC содержит **визуальный критерий** (см. принцип 8).
+8. **Visual TC = Screenshot + Self-Review** — если TC описывает **как элемент выглядит пользователю** (формулировки: «оформлен как», «читаем», «контрастен», «выровнен», «не обрезан», «стилизован», «визуально выделен», отрицания о внешнем виде «не голый», «без overflow»), то:
+   - a11y tree assertion **недостаточен** как единственный evidence — a11y tree не содержит визуальных свойств (цвет, стилизация, выравнивание, контраст);
+   - **обязательно** сделай скриншот проверяемого элемента и сохрани в `reports/`;
+   - **обязательно** открой сделанный скриншот через Read и посмотри на него **до** записи PASS. Опиши себе одним предложением, что видишь. Если видимое не соответствует формулировке TC — это FAIL, даже если a11y/DOM assertion прошёл;
+   - в evidence TC укажи **и** ссылку на PNG-файл, **и** краткое описание того, что на нём видно.
+   
+   **Почему:** программная проверка (DOM-assertion, a11y tree) подтверждает существование элемента в модели данных, но не его внешний вид. `type=checkbox` + `label.visible=true` не означает «выглядит как toggle» — между DOM и рендерингом лежит CSS, который DOM-assertion не видит. Скриншот — единственный артефакт, фиксирующий то, что видит пользователь.
+9. **One Bug — One Section** — каждый дефект оформляется отдельной секцией DEFECT внутри QA-тикета по формату `templates/bug-report.md`. Не группируй несвязанные дефекты в одну секцию. **⛔ Не создавай отдельные тикеты для дефектов** — QA-тикет является единственным носителем информации о найденных дефектах.
+
+## Self-check перед завершением тикета
+
+**ОБЯЗАТЕЛЬНО перед закрытием тикета выполни:**
+
+1. Проверь что все тест-кейсы из скоупа выполнены (PASS/FAIL/BLOCKED/OBSERVATION)
+2. Для каждого FAIL — дефект зафиксирован в QA-тикете с evidence (a11y tree assertion, описание шагов; скриншот — если требуется в DoD) по формату `templates/bug-report.md`
+3. **Evidence записаны в результат TC:** для каждого тест-кейса (PASS и FAIL) в результате указан a11y tree assertion (текстовое подтверждение из Snapshot, например: `a11y: "WF: Idle" found in StatusBar region`) и описание выполненных шагов. **Скриншоты** — если тикет явно требует их в DoD **или** если TC содержит визуальный критерий (принцип 8). Для визуальных TC: в evidence указана ссылка на PNG + описание что на нём видно. Если скриншоты требуются: сохраняй в `reports/`, проверяй что файл читаемо показывает проверяемый элемент. **Если тестируешь в Sandbox** — файлы внутри Sandbox эфемерны. Подробности: `knowledge/sandbox-core.md` → «Персистенция evidence»
+4. Заполнен отчёт о тестовой сессии → `templates/test-session-report.md`
+5. Пройди по каждому пункту DoD тикета — **отметь `[x]`** только если критерий **выполнен** (не просто проверен). `[x]` = «критерий достигнут». Если критерий проверен, но не достигнут → оставь `[ ]` и запиши фактический результат рядом в тексте (например: `[ ] Coverage ≥ 98% — фактически: 92.33%`). Не оставляй `[ ]` без объяснения — это сигнал невыполнения
+6. Заполни `completed_at` в frontmatter тикета
+7. ⛔ **НЕ перемещай тикет** — это исключительная ответственность пайплайна. Тикет будет автоматически перемещён скриптом после того, как агент завершит работу и выведет `---RESULT---`. Вызов `move-ticket.js` или любое ручное перемещение файла **ломает пайплайн**: тикет окажется в `done/` без прохождения ревью, и при следующем запуске auto-correct вернёт его в backlog.
+
+**Если хотя бы один пункт не пройден — тикет НЕ завершён.**
+
+## Формат вывода
+
+- Русский язык
+- Структурированный markdown с таблицами результатов
+- Скриншоты встроены или приложены по ссылке
+- Статус каждого тест-кейса: `PASS` / `FAIL` / `BLOCKED` / `SKIPPED`
+- Severity багов: `CRITICAL` / `HIGH` / `MEDIUM` / `LOW`
+- Итоговая статистика: всего / пройдено / упало / заблокировано
+
+## Границы компетенции
+
+- **Подмена ручной проверки UI-наблюдаемого поведения запуском автотестов** → запрещено (см. ⛔ антипаттерн выше). Написание и реальный запуск ассертов для инвариантов, не выражающихся через UI (ФС, данные, структура файла), — в зоне QA; правила размещения/именования тестов, если заданы проектом, ищи в `../shared/`
+- **Нагрузочное тестирование** → соответствующий скил проекта
+- **Исправление багов** → соответствующий скил через тикет
+- **Решение о релизе** → принимает ответственный скил проекта
+- **Улучшение этого скила** → соответствующий скил проекта
+
+---
+
+**Регрессионные тесты:** `tests/index.yaml`. Прогон: `node .workflow/src/scripts/run-skill-tests.js --skill manual-testing`

package/src/skills/manual-testing/algorithms/blocked-tool-strategy.md

@@ -0,0 +1,74 @@
+# Алгоритм: Стратегия при заблокированном инструменте
+
+Дерево решений для ситуации, когда основной инструмент тестирования недоступен или заблокирован.
+
+## Когда активировать
+
+- Инструмент выдаёт ошибку доступа (URL заблокирован, API недоступен)
+- Инструмент технически доступен, но не позволяет достичь тестируемого объекта
+- Попытка использовать инструмент приводит к BLOCKED на всех TC
+
+## Алгоритм
+
+### Шаг 1. Определи причину блокировки
+
+Задай вопрос: **«Заблокирован инструмент или тестируемый объект недоступен в данной среде?»**
+
+| Ответ | Следующий шаг |
+|-------|---------------|
+| Инструмент заблокирован (техническое ограничение среды) | → Шаг 2: Найти альтернативный инструмент |
+| Объект недоступен (нет среды, нет данных) | → Шаг 3: Зафиксировать BLOCKED |
+
+### Шаг 2. Ищи альтернативный инструмент
+
+Проверь в порядке приоритета:
+
+1. **Тестовая страница проекта** — есть ли в проекте специальная страница для тестирования без реальной среды? (Проверь shared knowledge проекта)
+2. **Другой инструмент той же категории** — например, другой способ запустить браузер с нужными флагами
+3. **Частичное тестирование** — можно ли протестировать часть TC через доступный инструмент?
+
+Если альтернатива найдена → выполни TC через неё, запиши в результате какой инструмент использован и какие ограничения.
+
+Если альтернативы нет → Шаг 3.
+
+### Шаг 3. Зафиксируй BLOCKED
+
+Для каждого заблокированного TC запиши:
+```
+Статус: BLOCKED
+Причина: [конкретная техническая причина — инструмент X недоступен из-за Y]
+Шаги для ручного воспроизведения: [список шагов без автоматизации]
+```
+
+**⛔ НЕ помечай TC как PASS без реальной проверки**
+**⛔ НЕ переключайся на code review или анализ исходного кода** — это другой тип работы
+
+### Шаг 4. Оцени критичность заблокированных TC
+
+Вопрос: **«Есть ли среди BLOCKED TC критические сценарии (статус CRITICAL или HIGH)?»**
+
+| Ответ | Действие |
+|-------|----------|
+| Да — есть CRITICAL/HIGH BLOCKED TC | Создать HUMAN-тикет с описанием причины блокировки и шагами для ручного тестирования |
+| Нет — все BLOCKED имеют LOW/MEDIUM приоритет | Завершить тикет с BLOCKED, документировать ограничение |
+
+### Шаг 5. Оформи результат тикета
+
+Даже если все TC BLOCKED — тикет должен содержать:
+- Задокументированное техническое ограничение
+- Шаги для ручного воспроизведения каждого TC
+- Рекомендацию по устранению блокировки
+
+**Полностью задокументированный BLOCKED = выполненная работа тестировщика.**
+
+## Антипаттерны (не делай так)
+
+| Антипаттерн | Почему нельзя |
+|-------------|---------------|
+| Заменить тест code review | Code review не обнаруживает UI-дефекты, регрессии, state-проблемы |
+| Генерировать тестовые данные вместо тестирования | Данные без выполнения — не тестирование |
+| Писать автотесты в коде **без запуска** | Код без прогона = призрачное тестирование. Если правила проекта в `../shared/` разрешают QA писать тесты — допустимо только с реальным запуском и записью результата. Иначе — другой скил (разработка), создай тикет. |
+| **Запустить уже существующие автотесты разработки и пометить TC как PASS** | Эти тесты уже были зелёными до создания QA-тикета — их прогон не даёт нового evidence о реальной среде исполнения. Ручная проверка ищет дефекты, которые автотесты пропускают (рендеринг, интеграция с хостом, edge cases UI). Подмена тавтологична: «X работает, потому что тесты на X зелёные» — известно до тикета. Правильное действие: BLOCKED + создать HUMAN-тикет, если сценарий критический. |
+| Объявить assertion из unit-тест файла «эквивалентом визуальной проверки» | Unit-тест проверяет конструктор объекта в изоляции, а не его рендеринг в реальном host-окружении. Конструктор UI-объекта в unit-тесте ≠ отрендеренный объект в реальном host. Эквивалентность ложная. |
+| Пометить TC как PASS на основании анализа кода | PASS без реального запуска — ложный результат |
+| Оставить все TC без статуса | Тикет без статусов = незавершённая работа |

package/src/skills/manual-testing/algorithms/bug-severity.md

@@ -0,0 +1,73 @@
+# Алгоритм: Определение Severity и Priority бага
+
+Формализованный метод определения серьёзности и приоритета исправления найденного дефекта.
+
+## Вход
+
+- Описание бага (что сломалось)
+- Контекст (какой модуль, какой flow)
+- Наличие workaround (обходной путь)
+- Частота воспроизведения
+
+## Алгоритм
+
+### 1. Определи Severity (серьёзность — техническое влияние)
+
+| Severity | Критерии | Примеры |
+|----------|----------|---------|
+| **CRITICAL** | Система неработоспособна. Потеря данных. Нет workaround. Безопасность скомпрометирована | Приложение не запускается; данные удалены; XSS-уязвимость; невозможно оплатить |
+| **HIGH** | Основная функция сломана. Workaround существует, но неудобен | Логин работает только через Google; поиск не возвращает результаты; отчёт формируется с ошибками |
+| **MEDIUM** | Вторичная функция сломана. Есть приемлемый workaround | Фильтр сбрасывается при переходе назад; email-уведомление не приходит; сортировка работает некорректно |
+| **LOW** | Косметический дефект. Не влияет на функциональность | Опечатка в тексте; неровное выравнивание; неправильная иконка |
+
+### 2. Определи частоту воспроизведения
+
+| Частота | Описание | Множитель |
+|---------|----------|-----------|
+| **Always** | Воспроизводится каждый раз | ×1.0 |
+| **Often** | Воспроизводится в >50% случаев | ×0.8 |
+| **Sometimes** | Воспроизводится в 10-50% случаев | ×0.5 |
+| **Rarely** | Воспроизводится в <10% случаев | ×0.3 |
+
+### 3. Определи Priority (приоритет исправления — бизнес-решение)
+
+Матрица Severity × Business Impact:
+
+| Severity / Бизнес-влияние | Блокирует пользователей | Снижает конверсию | Раздражает | Косметика |
+|---------------------------|------------------------|-------------------|------------|-----------|
+| **CRITICAL** | P0: Немедленно | P0: Немедленно | P1: Срочно | P1: Срочно |
+| **HIGH** | P0: Немедленно | P1: Срочно | P2: В спринт | P2: В спринт |
+| **MEDIUM** | P1: Срочно | P2: В спринт | P3: В бэклог | P3: В бэклог |
+| **LOW** | P2: В спринт | P3: В бэклог | P4: Когда-нибудь | P4: Когда-нибудь |
+
+### 4. Сформулируй рекомендацию
+
+| Priority | Действие |
+|----------|----------|
+| **P0** | Hotfix. Блокирует релиз. Исправить немедленно |
+| **P1** | Исправить в текущем спринте. Высокий приоритет |
+| **P2** | Включить в следующий спринт |
+| **P3** | Добавить в бэклог, исправить при возможности |
+| **P4** | Low priority, исправить когда будет время |
+
+## Выход
+
+- **Severity**: CRITICAL / HIGH / MEDIUM / LOW
+- **Priority**: P0 / P1 / P2 / P3 / P4
+- **Обоснование**: 1-2 предложения почему именно такие значения
+
+## Пример
+
+**Баг:** При сумме заказа > 999 999 руб. кнопка «Оплатить» неактивна.
+
+1. **Severity:** CRITICAL — основная функция (оплата) сломана, нет workaround
+2. **Частота:** Always (×1.0) — воспроизводится каждый раз при сумме > 999 999
+3. **Бизнес-влияние:** Блокирует пользователей (крупные заказы невозможны)
+4. **Priority:** P0 — немедленное исправление
+5. **Обоснование:** Блокирует оплату для клиентов с крупными заказами. Потенциальная потеря выручки.
+
+## Граничные случаи
+
+- **Severity HIGH, но редко воспроизводится** → Priority может быть снижен до P2
+- **Severity LOW, но видят все пользователи** → Priority может быть повышен до P2
+- **Баг в новой фиче, которая ещё не в проде** → Priority определяется по дедлайну фичи