workflow-ai 1.0.63 → 1.0.65

package/src/skills/manual-testing/knowledge/sandbox-core.md

@@ -0,0 +1,67 @@
+# Тестирование в Windows Sandbox — Core
+
+Справочник по тестированию desktop-приложений в изолированном окружении Windows Sandbox.
+
+## Архитектура
+
+```
+┌─────────────────────┐         ┌──────────────────────────┐
+│  Хост (Claude Code)  │  HTTP   │  Windows Sandbox          │
+│  MCP Client           │◄──────►│  windows-mcp (HTTP :8000) │
+│  (sandbox-desktop)    │        │  ↓ управляет UI            │
+└─────────────────────┘         └──────────────────────────┘
+```
+
+Инструменты: `mcp__sandbox-desktop__*` (screenshot, click, type, snapshot и т.д.). Подключение — `.mcp.json` → `"url": "http://<sandbox-ip>:8000/mcp"`. Пути и конфигурация .wsb — см. `CLAUDE.md` проекта. Расширенная настройка .wsb → `knowledge/sandbox-advanced.md`.
+
+## Quick-start checklist
+
+Минимальный набор проверок перед тест-кейсами (3-4 MCP-вызова):
+
+```
+1. Screenshot → MCP работает, Sandbox активен
+2. PowerShell → Test-Path "<path-to-portable-vscode>"
+3. PowerShell → Test-Path "<path-to-test-workspace>"
+4. → Запускай VSCode и тест-кейсы
+```
+
+**⛔ Hard gate:** если к 5-му MCP-вызову не начал первый TC — СТОП, пересмотри план.
+
+**Антипаттерны:**
+- 10+ MCP-вызовов на разведку (`Get-ChildItem`, `Test-Path`, `echo test`) до первого TC
+- Установка/запуск продукта из CLI вместо UI — тестирует другой code path
+- Перезапись конфигов без проверки существующих
+- **BOM-кодировка:** PowerShell 5.x `Set-Content -Encoding utf8` пишет с BOM. Используй `[System.IO.File]::WriteAllText($path, $content)` или `-Encoding utf8NoBOM` (PS 7+)
+- **Backslash в JSON:** используй `ConvertTo-Json` для hashtable, не собирай JSON строками
+- **Parent directory traversal:** приложения ищут конфиг в parent dirs. Для теста «нет конфига» нужен workspace вне дерева проекта. Если невозможно за 3-5 вызовов — TC = BLOCKED
+
+## Персистенция evidence
+
+**Sandbox эфемерен — всё удаляется при закрытии.** Сохраняй evidence на хост.
+
+### ReadOnly: false (рекомендуемый)
+
+Сохраняй скриншоты напрямую в `reports/` — они пишутся на хост (1 MCP-вызов):
+
+```
+PowerShell → "Add-Type -AssemblyName System.Windows.Forms,System.Drawing; $b = [System.Windows.Forms.Screen]::PrimaryScreen.Bounds; $bmp = New-Object System.Drawing.Bitmap($b.Width,$b.Height); $g = [System.Drawing.Graphics]::FromImage($bmp); $g.CopyFromScreen(0,0,0,0,$b.Size); $bmp.Save('<sandbox-project-path>\reports\TICKET-ID-screenshot-TC-NNN.png'); $g.Dispose(); $bmp.Dispose()"
+```
+
+### ReadOnly: true (fallback — 2 MCP-вызова)
+
+Бинарная запись в ReadOnly mapped folder заблокирована. Сохрани в writable folder внутри Sandbox, затем скопируй на хост через Bash.
+
+### Self-check
+
+После сохранения **проверь на хосте** (не в Sandbox): `ls reports/*.png`. Если 0 файлов — evidence потеряны.
+
+## Ключевые ограничения
+
+| Ограничение | Обходной путь |
+|------------|---------------|
+| Одноразовость | Сохранять через mapped folders (ReadOnly: false) |
+| Один экземпляр | Последовательное тестирование |
+| FileSystem events не пробрасываются | TC с FileWatcher → BLOCKED |
+| Латентность MCP 3-10 сек | `Wait` обычно не нужен |
+
+Расширенные сценарии (MCP disconnect, continuation, .wsb конфигурация) → `knowledge/sandbox-advanced.md`.

package/src/skills/manual-testing/knowledge/stateful-edge-cases.md

@@ -0,0 +1,69 @@
+---
+name: stateful-edge-cases
+description: >
+  Edge-cases stateful-приложений для manual-testing. Помогает тестировщику
+  распознавать пропущенные паттерны в ходе тестирования, не перечисляет ТС явно.
+load_strategy: lazy
+load_when: "task.type == 'qa' AND app.type == 'stateful'"
+---
+
+# Edge-cases stateful-приложений
+
+## Когда загружать
+
+Загружай этот модуль, если тестируемое приложение хранит состояние между сессиями (история, настройки, данные, логи).
+
+## Ключевые паттерны
+
+### 1. Persistence после перезапуска
+
+**Признак:** приложение сохраняет данные между сессиями.
+
+**Что проверять:**
+- После перезапуска приложения — данные из предыдущей сессии присутствуют
+- Частичные данные (незавершённая операция) — корректно восстановлены или отброшены
+- После принудительного завершения (crash, kill) — приложение запускается без ошибок
+
+**Сигнал:** любой TC, создающий/изменяющий данные → проверь: данные есть после перезапуска.
+
+---
+
+### 2. Накопление данных (multi-run)
+
+**Признак:** функция создаёт записи при каждом запуске (история, логи, очередь).
+
+**Что проверять:**
+- После N запусков операции — в хранилище ровно N записей (не 1 перезаписанная)
+- При ожидаемом порядке (FIFO/LIFO) — порядок соответствует
+- При достижении лимита хранилища — поведение определено (обрезка, ошибка, очистка)
+
+**Сигнал:** TC использует слова «история», «журнал», «список» → запусти операцию дважды и проверь количество записей.
+
+---
+
+### 3. Нестандартные конфигурации
+
+**Признак:** поведение приложения зависит от конфигурационного файла или настроек.
+
+**Что проверять:**
+- Отсутствующий конфиг — приложение применяет значения по умолчанию без ошибок
+- Неполный конфиг (часть полей отсутствует) — незаданные поля заполняются дефолтами
+- Граничные значения в конфиге — приложение корректно обрабатывает минимум/максимум
+
+**Сигнал:** TC ссылается на конфиг → дополнительно проверь: что если конфиг отсутствует или одно поле удалено.
+
+---
+
+## Что НЕ входит в этот модуль
+
+- **Data assertions** (конкретные ожидаемые значения) → ответственность create-plan
+- **Перечисление entry points** → ответственность create-plan
+- **Генерация тест-кейсов** → используй `knowledge/test-case-design.md`
+
+## Таблица применимости
+
+| Признак в тикете/задаче | Применимый паттерн |
+|-------------------------|--------------------|
+| «сохраняет состояние», «история», «настройки» | Persistence (п.1) |
+| «каждый запуск», «накапливается», «лог», «список» | Multi-run (п.2) |
+| «конфиг», «настройки», «config» | Config variations (п.3) |

package/src/skills/manual-testing/knowledge/test-case-design.md

@@ -0,0 +1,107 @@
+# Техники проектирования тест-кейсов
+
+Справочник по техникам проектирования тест-кейсов для обеспечения полноты покрытия.
+
+## Основные техники
+
+### Equivalence Partitioning (классы эквивалентности)
+
+Разделение входных данных на группы, где поведение системы одинаково.
+
+| Класс | Описание | Пример (поле «Возраст», допустимо 18-99) |
+|-------|----------|------------------------------------------|
+| Валидный | Данные в допустимом диапазоне | 25, 50, 75 |
+| Невалидный (ниже) | Ниже минимума | -1, 0, 17 |
+| Невалидный (выше) | Выше максимума | 100, 999 |
+| Невалидный (тип) | Неправильный тип данных | "abc", "", null |
+
+**Правило:** достаточно одного значения из каждого класса.
+
+### Boundary Value Analysis (граничные значения)
+
+Проверка значений на границах допустимых диапазонов.
+
+| Граница | Значения для проверки | Пример (18-99) |
+|---------|----------------------|----------------|
+| Min - 1 | Чуть ниже минимума | 17 |
+| Min | Минимальное допустимое | 18 |
+| Min + 1 | Чуть выше минимума | 19 |
+| Max - 1 | Чуть ниже максимума | 98 |
+| Max | Максимальное допустимое | 99 |
+| Max + 1 | Чуть выше максимума | 100 |
+
+### Decision Table (таблица решений)
+
+Для комбинаций условий и ожидаемых действий.
+
+| Условие 1 | Условие 2 | Условие 3 | Ожидаемое действие |
+|-----------|-----------|-----------|-------------------|
+| Да | Да | Да | Действие A |
+| Да | Да | Нет | Действие B |
+| Да | Нет | — | Действие C |
+| Нет | — | — | Действие D |
+
+**Применять когда:** бизнес-логика зависит от комбинации нескольких условий.
+
+### State Transition (переходы состояний)
+
+Для объектов с жизненным циклом.
+
+```
+[Создан] → оплата → [Оплачен] → доставка → [Доставлен]
+    ↓                     ↓
+ отмена               возврат
+    ↓                     ↓
+[Отменён]           [Возвращён]
+```
+
+Проверяй:
+- Все допустимые переходы
+- Попытки недопустимых переходов (отменённый → оплачен)
+- Состояние данных после каждого перехода
+
+### Error Guessing (угадывание ошибок)
+
+Основано на опыте — типичные места возникновения багов:
+
+| Категория | Что проверять |
+|-----------|-------------|
+| **Пустые значения** | Пустые поля, null, undefined, пустые массивы |
+| **Спецсимволы** | `<script>`, `'; DROP TABLE`, `../`, `%00` |
+| **Unicode** | Эмодзи, RTL-текст, иероглифы, диакритика |
+| **Длинные строки** | 1000+ символов, переполнение UI |
+| **Числа** | 0, -1, MAX_INT, дробные, NaN |
+| **Даты** | 29 февраля, 31 ноября, смена часовых поясов |
+| **Файлы** | 0 байт, огромные файлы, неправильный формат |
+| **Параллельность** | Два пользователя редактируют одно, двойной клик |
+| **Сеть** | Медленная сеть, обрыв, повтор запроса |
+
+## Структура тест-кейса
+
+```
+ID:             QA-TC-001
+Название:       Авторизация с валидным email и паролем
+Приоритет:      P0
+Предусловия:    Пользователь зарегистрирован (email: test@example.com, пароль: Test123!)
+Шаги:
+  1. Открыть /login
+  2. Ввести email: test@example.com
+  3. Ввести пароль: Test123!
+  4. Нажать кнопку «Войти»
+Ожидаемый результат:
+  - Редирект на /dashboard
+  - Отображается имя пользователя в хедере
+  - Cookie/токен сессии установлен
+Постусловия:    Пользователь авторизован
+```
+
+## Чеклист полноты тест-кейсов
+
+- [ ] Есть happy path (позитивный сценарий)
+- [ ] Есть негативные сценарии (невалидные данные)
+- [ ] Граничные значения проверены
+- [ ] Тестовые данные конкретные (не «валидный email», а «user@test.com»)
+- [ ] Шаги однозначны и воспроизводимы
+- [ ] Ожидаемый результат конкретен и проверяем
+
+<!-- РАСШИРЕНИЕ: добавляй новые техники проектирования тест-кейсов ниже -->

package/src/skills/manual-testing/knowledge/testing-types.md

@@ -0,0 +1,45 @@
+# Типы тестирования
+
+Справочник по типам тестирования, их целям и применимости.
+
+## Основные типы
+
+| Тип | Цель | Когда применять | Охват |
+|-----|------|----------------|-------|
+| **Smoke** | Базовая работоспособность | После каждого деплоя | 5-15 критических сценариев |
+| **Regression** | Нет регрессии от изменений | Перед релизом, после крупных изменений | Полный набор тест-кейсов |
+| **Exploratory** | Поиск неочевидных багов | После стабилизации фичи | Свободное исследование |
+| **Acceptance (UAT)** | Соответствие бизнес-требованиям | Финальная стадия перед релизом | По acceptance criteria |
+| **Sanity** | Узкая проверка конкретного фикса | После hotfix | 1-3 сценария вокруг фикса |
+
+## Дополнительные типы
+
+| Тип | Цель | Когда применять |
+|-----|------|----------------|
+| **Cross-browser** | Работа в разных браузерах | Для web-приложений с широкой аудиторией |
+| **Accessibility (a11y)** | Доступность для людей с ограничениями | Всегда для публичных интерфейсов, WCAG 2.1 |
+| **Usability** | Удобство использования | При новых фичах, редизайне |
+| **Visual** | Корректность отображения UI | При изменениях в стилях, вёрстке |
+| **Negative** | Поведение при невалидных данных | Для форм, API, полей ввода |
+
+## Подходы к тестированию
+
+| Подход | Описание | Когда использовать |
+|--------|----------|-------------------|
+| **Risk-Based** | Приоритизация по бизнес-риску | Ограниченное время, нужна максимальная отдача |
+| **Context-Driven** | Адаптация под контекст проекта | Всегда — нет универсального подхода |
+| **Shift-Left** | Тестирование на ранних стадиях | Интеграция QA с момента требований |
+| **Session-Based (SBTM)** | Таймбоксированные сессии исследования | Исследовательское тестирование |
+
+## Матрица выбора типа тестирования
+
+| Ситуация | Рекомендуемый тип |
+|----------|------------------|
+| Только что задеплоили | Smoke |
+| Готовимся к релизу | Regression |
+| Новая фича готова | Acceptance + Exploratory |
+| Исправили баг | Sanity + Smoke |
+| Жалобы на UX | Usability + Exploratory |
+| Новый дизайн | Visual + Cross-browser |
+
+<!-- РАСШИРЕНИЕ: добавляй новые типы тестирования и подходы ниже -->

package/src/skills/manual-testing/templates/bug-report.md

@@ -0,0 +1,52 @@
+# Шаблон: Баг-репорт (секция внутри QA-тикета)
+
+> **⛔ Не создавай отдельный тикет для дефекта.** Этот шаблон — формат секции FAIL внутри QA-тикета.
+
+```markdown
+## DEFECT: [{Модуль}] {Краткое описание проблемы}
+
+**Severity:** CRITICAL / HIGH / MEDIUM / LOW
+**Priority:** P0 / P1 / P2 / P3 / P4
+**Найден при:** {ID тест-кейса или описание сессии}
+
+### Окружение
+
+| Параметр | Значение |
+|----------|----------|
+| URL | {URL страницы} |
+| Браузер | {Chrome 120 / Firefox 121 / Safari 17 / ...} |
+| ОС | {Windows 11 / macOS 14 / ...} |
+| Разрешение | {1920×1080 / 375×667 / ...} |
+| Стенд | {production / staging / dev} |
+
+### Шаги воспроизведения
+
+1. {Конкретный шаг 1}
+2. {Конкретный шаг 2}
+3. {Конкретный шаг 3}
+4. ...
+
+### Фактический результат
+
+{Что происходит на самом деле}
+
+### Ожидаемый результат
+
+{Что должно происходить}
+
+### Скриншоты / Видео
+
+- {screenshot_1.png — описание}
+- {screenshot_2.png — описание}
+
+### Дополнительная информация
+
+- **Console errors:** {JS-ошибки из консоли, если есть}
+- **Network:** {Проблемные запросы: статус-код, URL}
+- **Частота воспроизведения:** Always / Often / Sometimes / Rarely
+- **Workaround:** {Обходной путь, если есть}
+
+### Обоснование Severity
+
+{1-2 предложения: почему именно такая серьёзность}
+```

package/src/skills/manual-testing/templates/test-case.md

@@ -0,0 +1,34 @@
+# Шаблон: Тест-кейс
+
+```markdown
+## QA-TC-{NNN}: {Название тест-кейса}
+
+**Приоритет:** P0 / P1 / P2 / P3
+**Тип:** Functional / Negative / Boundary / Cross-browser / Accessibility
+**Связь:** {ID требования или user story}
+
+### Предусловия
+
+- {Состояние системы перед началом теста}
+- {Тестовые данные, аккаунты, окружение}
+
+### Шаги
+
+| # | Действие | Ожидаемый результат |
+|---|----------|-------------------|
+| 1 | {Конкретное действие} | {Конкретный ожидаемый результат} |
+| 2 | {Конкретное действие} | {Конкретный ожидаемый результат} |
+| 3 | ... | ... |
+
+### Тестовые данные
+
+| Параметр | Значение |
+|----------|----------|
+| {Поле 1} | {Конкретное значение} |
+| {Поле 2} | {Конкретное значение} |
+
+### Постусловия
+
+- {Состояние системы после теста}
+- {Что нужно очистить / откатить}
+```

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

@@ -0,0 +1,97 @@
+# Шаблон: Тест-план
+
+```markdown
+# Тест-план: {Название фичи / релиза}
+
+**Дата:** {YYYY-MM-DD}
+**Автор:** QA
+**Версия:** 1.0
+
+## 1. Цели тестирования
+
+{Что проверяем и зачем}
+
+## 2. Scope
+
+### В скоупе
+
+- {Модуль / фича 1}
+- {Модуль / фича 2}
+
+### Вне скоупа
+
+- {Что НЕ тестируем и почему}
+
+## 3. Стратегия тестирования
+
+| Тип тестирования | Применяется | Обоснование |
+|-----------------|-------------|-------------|
+| Smoke | Да / Нет | {Почему} |
+| Functional | Да / Нет | {Почему} |
+| Regression | Да / Нет | {Почему} |
+| Cross-browser | Да / Нет | {Почему} |
+| Accessibility | Да / Нет | {Почему} |
+| Exploratory | Да / Нет | {Почему} |
+
+## 4. Окружение
+
+### Браузеры
+
+| Браузер | Версия | Приоритет |
+|---------|--------|-----------|
+| {Chrome} | {latest} | {P0} |
+| ... | ... | ... |
+
+### Устройства / Разрешения
+
+| Устройство | Разрешение | Приоритет |
+|-----------|-----------|-----------|
+| {Desktop} | {1920×1080} | {P0} |
+| {Mobile} | {375×667} | {P1} |
+
+### Стенды
+
+| Стенд | URL | Назначение |
+|-------|-----|-----------|
+| {staging} | {URL} | {Основное тестирование} |
+
+## 5. Тест-кейсы
+
+### P0 — Critical Path
+
+| ID | Название | Тип | Статус |
+|----|----------|-----|--------|
+| QA-TC-001 | {Название} | {Functional} | {Pending} |
+| ... | ... | ... | ... |
+
+### P1 — Major Flows
+
+| ID | Название | Тип | Статус |
+|----|----------|-----|--------|
+| ... | ... | ... | ... |
+
+### P2 — Edge Cases
+
+| ID | Название | Тип | Статус |
+|----|----------|-----|--------|
+| ... | ... | ... | ... |
+
+## 6. Критерии входа
+
+- [ ] Фича задеплоена на тестовый стенд
+- [ ] Тестовые данные подготовлены
+- [ ] Нет блокирующих багов из предыдущих итераций
+
+## 7. Критерии выхода
+
+- [ ] Все P0 тест-кейсы: PASS
+- [ ] Все P1 тест-кейсы: PASS (или обоснован SKIP)
+- [ ] Нет открытых CRITICAL/HIGH багов
+- [ ] Отчёт о тестировании сформирован
+
+## 8. Риски
+
+| Риск | Вероятность | Влияние | Митигация |
+|------|-------------|---------|-----------|
+| {Описание} | {High/Med/Low} | {High/Med/Low} | {Как снизить} |
+```

package/src/skills/manual-testing/templates/test-session-report.md

@@ -0,0 +1,56 @@
+# Шаблон: Отчёт о тестовой сессии
+
+```markdown
+# Отчёт о тестировании: {Название сессии}
+
+**Дата:** {YYYY-MM-DD}
+**Тип тестирования:** Smoke / Regression / Exploratory / Acceptance
+**Тестировщик:** QA
+**Окружение:** {URL стенда}
+**Браузер:** {Браузер и версия}
+
+## Вердикт
+
+**{PASSED / FAILED / PASSED WITH ISSUES / ACCEPTED / REJECTED}**
+
+{1-2 предложения обоснование вердикта}
+
+## Статистика
+
+| Метрика | Значение |
+|---------|----------|
+| Всего тест-кейсов | {N} |
+| Пройдено (PASS) | {N} ({%}) |
+| Упало (FAIL) | {N} ({%}) |
+| Заблокировано (BLOCKED) | {N} ({%}) |
+| Пропущено (SKIPPED) | {N} ({%}) |
+
+## Результаты по тест-кейсам
+
+| # | ID | Название | Приоритет | Статус | Комментарий |
+|---|-----|----------|-----------|--------|-------------|
+| 1 | QA-TC-001 | {Название} | P0 | PASS / FAIL | {Ссылка на баг если FAIL} |
+| 2 | ... | ... | ... | ... | ... |
+
+## Найденные баги
+
+| # | TC | Название | Severity | Priority |
+|---|----|----------|----------|----------|
+| 1 | TC-{NNN} | {Краткое описание} | {CRITICAL} | {P0} |
+| 2 | ... | ... | ... | ... |
+
+(Подробности — в секциях DEFECT внутри QA-тикета)
+
+## Наблюдения
+
+{Заметки, UX-проблемы, рекомендации, непокрытые области — всё, что не является формальным багом, но заслуживает внимания}
+
+## Скриншоты
+
+{Ключевые скриншоты сессии с подписями}
+
+## Рекомендации
+
+- {Рекомендация 1}
+- {Рекомендация 2}
+```

package/src/skills/manual-testing/tests/cases/TC-MANUAL-TESTING-001/current/claude-sonnet/trial-1.md

@@ -0,0 +1,34 @@
+## Стратегия тестирования VSCode-расширения
+
+### Инструмент
+
+**Windows-MCP через Windows Sandbox** — единственный допустимый вариант для desktop-приложений согласно матрице выбора инструмента:
+
+| Тип приложения | Инструмент | Knowledge |
+|---|---|---|
+| Desktop (VSCode-расширение) | **Windows-MCP через Sandbox** | `desktop-tools-core.md` + `sandbox-core.md` |
+
+### Среда запуска: Windows Sandbox
+
+**Обязательно** — прямое тестирование на хосте запрещено по двум причинам:
+1. **Загрязнение рабочей среды** — расширение может изменить настройки VSCode, установить зависимости, создать файлы
+2. **Нет чистого состояния** — хост уже содержит расширения, настройки, историю; воспроизводимость нарушена
+
+Sandbox даёт изолированную Windows-среду с чистым VSCode при каждом запуске.
+
+### Последовательность подготовки
+
+1. Загрузить `knowledge/sandbox-core.md` — quick-start Sandbox, персистенция evidence
+2. Загрузить `knowledge/desktop-tools-core.md` — команды Windows-MCP, навигация, бюджет Snapshot
+3. Прочитать `../shared/README.md` (если существует) — проектно-специфичные пути и конфигурация
+4. Установить VSCode + расширение в Sandbox
+5. Выполнять тест-кейсы через Windows-MCP (клики, ввод, навигация)
+6. Получать evidence через **a11y tree (Snapshot)** — основной инструмент проверки состояния UI; скриншоты — только для визуальных критериев (принцип 8)
+
+### Важно про evidence в Sandbox
+
+Файлы внутри Sandbox эфемерны — при закрытии Sandbox всё уничтожается. Скриншоты и другие артефакты нужно выносить на хост до завершения сессии. Детали — в `knowledge/sandbox-core.md` → «Персистенция evidence».
+
+---
+
+Если у тебя есть конкретный тикет `QA-*` — передай его, и я загружу нужные модули и начну выполнение по соответствующему workflow.

package/src/skills/manual-testing/tests/cases/TC-MANUAL-TESTING-001/current/claude-sonnet/trial-2.md

@@ -0,0 +1,32 @@
+## Стратегия тестирования VSCode-расширения
+
+### Инструмент: Windows-MCP через Sandbox
+
+VSCode-расширение — это **desktop-приложение**, поэтому по правилам скила:
+
+| Параметр | Выбор | Обоснование |
+|----------|-------|-------------|
+| **Инструмент** | Windows-MCP | Desktop UI не доступен через Playwright/browser |
+| **Среда** | Windows Sandbox | Обязательная изоляция для desktop-приложений |
+| **Метод проверки** | a11y tree (Snapshot) | Основной способ верификации состояния UI в desktop |
+
+### Почему именно Sandbox, а не хост?
+
+1. **Изоляция** — расширение не загрязняет рабочую среду разработчика (настройки VS Code, установленные расширения, workspace state)
+2. **Воспроизводимость** — каждый запуск начинается с чистого состояния, без накопленных артефактов
+3. **Безопасность** — расширение может иметь side effects на файловую систему и реестр
+
+### Следующие шаги перед запуском
+
+1. Загрузить `knowledge/sandbox-core.md` — quick-start и персистенция evidence
+2. Загрузить `knowledge/desktop-tools-core.md` — команды Windows-MCP, паттерны навигации
+3. Проверить наличие `../shared/README.md` — проектно-специфичные пути и конфигурация
+4. Определить тип тестирования (smoke / regression / acceptance / exploratory) → загрузить соответствующий workflow
+
+### Что потребуется для старта
+
+- Артефакт расширения (`.vsix` файл или путь к нему)
+- Описание тест-кейсов или acceptance criteria
+- Тикет `QA-*` с типом тестирования
+
+Есть конкретный тикет для выполнения или нужно составить тест-план?

package/src/skills/manual-testing/tests/cases/TC-MANUAL-TESTING-001/current/claude-sonnet/trial-3.md

@@ -0,0 +1,30 @@
+Согласно таблице выбора инструмента в скиле:
+
+| Критерий | Решение |
+|----------|---------|
+| **Тип приложения** | Desktop (VSCode-расширение) |
+| **Основной инструмент** | Windows-MCP |
+| **Среда запуска** | **Windows Sandbox** (обязательно) |
+| **Knowledge-модули** | `knowledge/desktop-tools-core.md` + `knowledge/sandbox-core.md` |
+
+**Почему Sandbox, а не хост:**
+
+Скил явно запрещает прямое тестирование на хосте — это загрязняет рабочую среду разработчика и не воспроизводит чистое состояние (расширение может вести себя иначе из-за существующих настроек, других расширений, кэша).
+
+**Первые шаги перед тестированием:**
+
+1. Проверить наличие `../shared/README.md` — прочитать и загрузить проектные модули
+2. Загрузить `knowledge/sandbox-core.md` — настройка Sandbox, quick-start, персистенция evidence
+3. Загрузить `knowledge/desktop-tools-core.md` — команды Windows-MCP, паттерны навигации, бюджет Snapshot
+4. Определить тип тикета (SMOKE / ACCEPTANCE / REGRESSION / EXPLORATORY) → загрузить соответствующий workflow
+
+**Общая схема:**
+
+```
+Windows Sandbox
+  └── VSCode (установить расширение)
+        └── Windows-MCP (управление UI)
+              └── Snapshot (a11y tree assertions как evidence)
+```
+
+Скриншоты — только если тикет требует их в DoD или TC содержит визуальный критерий (принцип 8).