workflow-ai 1.1.0 → 1.3.0

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

@@ -1,67 +0,0 @@
-# Тестирование в 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

@@ -1,69 +0,0 @@
----
-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

@@ -1,107 +0,0 @@
-# Техники проектирования тест-кейсов
-
-Справочник по техникам проектирования тест-кейсов для обеспечения полноты покрытия.
-
-## Основные техники
-
-### 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

@@ -1,45 +0,0 @@
-# Типы тестирования
-
-Справочник по типам тестирования, их целям и применимости.
-
-## Основные типы
-
-| Тип | Цель | Когда применять | Охват |
-|-----|------|----------------|-------|
-| **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

@@ -1,52 +0,0 @@
-# Шаблон: Баг-репорт (секция внутри 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

@@ -1,34 +0,0 @@
-# Шаблон: Тест-кейс
-
-```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

@@ -1,97 +0,0 @@
-# Шаблон: Тест-план
-
-```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

@@ -1,56 +0,0 @@
-# Шаблон: Отчёт о тестовой сессии
-
-```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

@@ -1,34 +0,0 @@
-## Стратегия тестирования 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

@@ -1,32 +0,0 @@
-## Стратегия тестирования 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

@@ -1,30 +0,0 @@
-Согласно таблице выбора инструмента в скиле:
-
-| Критерий | Решение |
-|----------|---------|
-| **Тип приложения** | 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).