workflow-ai 1.1.0 → 1.3.0

package/src/skills/manual-testing/algorithms/mcp-budget.md

@@ -1,97 +0,0 @@
-# Алгоритм: Бюджетирование MCP-сессии
-
-Формализованный расчёт и контроль расхода MCP-вызовов на тестовую сессию.
-
-## Вход
-
-- Бюджет MCP-вызовов из `context.notes` тикета (или значение по умолчанию: 80)
-- Количество тест-кейсов (TC) в скоупе
-- Тип тестирования (smoke, regression, exploratory)
-
-## Формула распределения
-
-```
-avg_cost_per_TC = 10        # среднее по 11 QA-сессиям (диапазон 8-12)
-setup_reserve   = 5         # Quick-start checklist (3-4 вызова + запуск приложения)
-safety_margin   = 0.1       # 10% резерв на непредвиденные ситуации
-
-effective_budget = budget - setup_reserve
-max_TC_per_session = floor(effective_budget * (1 - safety_margin) / avg_cost_per_TC)
-```
-
-**Пример:** бюджет = 80 → effective = 75 → max_TC = floor(75 × 0.9 / 10) = **6 TC за сессию**.
-
-## Таблица быстрого расчёта
-
-| Бюджет | Setup | Effective | Max TC | Примечание |
-|--------|-------|-----------|--------|------------|
-| 50     | 5     | 45        | 4      | Минимальная сессия |
-| 80     | 5     | 75        | 6      | Стандартный бюджет |
-| 100    | 5     | 95        | 8      | Расширенная сессия |
-| 140    | 5     | 135       | 12     | Максимальная сессия |
-
-## Правила
-
-### Планирование continuation
-
-Если тикет содержит больше TC, чем `max_TC_per_session`:
-
-1. **Перед началом** запиши в тикет: «Запланирована continuation: TC-001..TC-006 в сессии 1, TC-007..TC-010 в сессии 2»
-2. Выполняй TC по приоритету (быстрые → средние → длительные)
-3. После завершения `max_TC` — зафиксируй прогресс и заверши сессию
-
-### Checkpoint accounting
-
-В начале каждого TC записывай номер текущего MCP-вызова:
-
-```
-TC-001 starts at call #6 → done at call #14 (8 calls)
-TC-002 starts at call #14 → done at call #22 (8 calls)
-TC-003 starts at call #22 → done at call #35 (13 calls) ← ПРЕВЫШЕНИЕ
-```
-
-Это даёт данные для калибровки `avg_cost_per_TC` в будущих сессиях.
-
-### Жёсткий порог BLOCKED
-
-- **TC > 12 MCP-вызовов = BLOCKED**, без исключений
-- Зафиксируй: что наблюдалось, на чём застрял, сколько вызовов потрачено
-- Переходи к следующему TC
-
-### Явное намерение перед вызовом (Explicit Intent)
-
-**Источник:** Advanced Tool Calling in LLM Agents (sparkco.ai, 2025)
-
-Перед каждым **не очевидным** инструментальным вызовом задай себе вопрос:
-> «Зачем именно этот вызов и что он подтвердит в рамках текущего TC?»
-
-Если ответ не формулируется за 1 строку — это сигнал rabbit hole.
-
-| Ситуация | Действие |
-|----------|----------|
-| Вызов прямо следует из шага TC | Выполняй |
-| Цель вызова — «разобраться как работает X» | СТОП — это rabbit hole |
-| Вызов — третий подряд без видимого прогресса | BLOCKED → зафиксируй, переходи к следующему TC |
-
-### Rabbit hole detection (decision tree)
-
-```
-Текущее действие входит в шаги TC?
-├── ДА → продолжай
-└── НЕТ → это rabbit hole
-    ├── Расследование инфраструктуры (Get-ChildItem, Test-Path, Get-Acl) → СТОП
-    ├── Создание собственных инструментов (HTTP-клиент, скрипт обхода) → СТОП
-    ├── Установка/запуск продукта из CLI при UI-тестировании → СТОП
-    └── Другое: задай вопрос «это в скоупе TC?» — если нет → BLOCKED
-```
-
-### 50% checkpoint (из smoke.md)
-
-- Потрачено >50% бюджета И выполнено <50% TC → **экономный режим**
-- Экономный режим: минимум Snapshot, пропуск длительных TC, OBSERVATION вместо полного расследования
-
-## Выход
-
-- Распределение бюджета по TC (таблица: TC → allocated → actual)
-- Решение о необходимости continuation
-- Фактический расход для калибровки будущих сессий

package/src/skills/manual-testing/algorithms/test-prioritization.md

@@ -1,69 +0,0 @@
-# Алгоритм: Приоритизация тест-кейсов
-
-Определение порядка выполнения тест-кейсов при ограниченном времени на тестирование.
-
-## Вход
-
-- Список тест-кейсов с описанием
-- Информация об изменениях (что задеплоено/изменено)
-- Доступное время на тестирование
-- Контекст (тип релиза, критичность)
-
-## Алгоритм
-
-### 1. Оцени бизнес-критичность каждого тест-кейса
-
-| Уровень | Описание | Вес |
-|---------|----------|-----|
-| **CRITICAL** | Невозможность использования продукта. Оплата, авторизация, основной бизнес-flow | 10 |
-| **HIGH** | Серьёзное нарушение работы. Основные фичи, данные пользователя | 7 |
-| **MEDIUM** | Снижение качества. Вторичные фичи, UX-проблемы | 4 |
-| **LOW** | Косметические. Тексты, вёрстка, edge cases | 1 |
-
-### 2. Оцени вероятность регрессии
-
-| Фактор | Вес |
-|--------|-----|
-| Код модуля менялся в этом релизе | +5 |
-| Код смежного модуля менялся | +3 |
-| Модуль часто ломается (история багов) | +3 |
-| Модуль стабилен, давно не менялся | +0 |
-| Сложная бизнес-логика | +2 |
-| Простая статика | +0 |
-
-### 3. Рассчитай приоритет
-
-```
-Приоритет = Бизнес-критичность × Вероятность_регрессии
-```
-
-### 4. Распредели по группам
-
-| Группа | Приоритет | Действие |
-|--------|-----------|----------|
-| **P0** | > 50 | Выполнить ОБЯЗАТЕЛЬНО, даже при минимальном времени |
-| **P1** | 25-50 | Выполнить при наличии времени |
-| **P2** | 10-24 | Выполнить при полной регрессии |
-| **P3** | < 10 | Опционально |
-
-### 5. При нехватке времени
-
-1. Выполни все P0
-2. Из P1 выбери те, чей модуль менялся в этом релизе
-3. Для непроверенных P1/P2 — укажи `SKIPPED` с обоснованием в отчёте
-
-## Выход
-
-Упорядоченный список тест-кейсов с приоритетами P0-P3.
-
-## Пример
-
-Релиз включает изменения в модуле checkout. Время — 2 часа.
-
-| Тест-кейс | Критичность | Вероятность | Приоритет | Группа |
-|-----------|-------------|-------------|-----------|--------|
-| Оплата картой | 10 (CRITICAL) | 8 (модуль менялся) | 80 | P0 |
-| Логин | 10 (CRITICAL) | 0 (не менялся) | 0 | P3 |
-| Корзина | 7 (HIGH) | 3 (смежный) | 21 | P2 |
-| Фильтры товаров | 4 (MEDIUM) | 0 | 0 | P3 |
-| Промокод при оплате | 7 (HIGH) | 8 (модуль менялся) | 56 | P0 |

package/src/skills/manual-testing/knowledge/browser-extension-testing.md

@@ -1,102 +0,0 @@
-# Тестирование браузерных расширений
-
-Специфика, ограничения и стратегии тестирования браузерных расширений.
-
-## Ограничения MCP-browser
-
-MCP-browser запускает браузер без флага `--load-extension`, поэтому:
-
-- `chrome://extensions` — заблокирован (политика безопасности браузера)
-- Extension popup — недоступен через UI-клик на иконке расширения
-- Extension API (хранилище, прокси и т.п.) — недоступны из внешнего контекста
-- Service Worker расширения — недоступен через инструменты разработчика
-
-**Это архитектурное ограничение MCP-browser, не баг.**
-
-## Стратегии тестирования при ограничениях
-
-### Стратегия 1: Тестовая HTML-страница (если есть в проекте)
-
-Если проект предоставляет тестовую страницу расширения для локального запуска через HTTP-сервер — использовать её.
-
-**Возможности:** UI-взаимодействия, формы, навигация.
-
-**Ограничения:** Extension API (хранилище, прокси) могут быть недоступны или замоканы. Проверь shared knowledge проекта на наличие инструкций по тестовой среде.
-
-### Стратегия 2: Прямой запуск с --load-extension (Playwright без MCP)
-
-Используется в Playwright-тестах (не через MCP). Загрузка расширения при старте браузера:
-
-```typescript
-// Запуск браузера с расширением
-const context = await chromium.launchPersistentContext('', {
-  headless: false,  // headless:true не поддерживается для расширений
-  args: [
-    `--disable-extensions-except=${pathToExtension}`,
-    `--load-extension=${pathToExtension}`,
-  ],
-});
-// Extension ID получается из URL service worker
-const [background] = context.serviceWorkers();
-const extensionId = background.url().split('/')[2];
-// Popup открывается как обычная страница
-const popup = await context.newPage();
-await popup.goto(`chrome-extension://${extensionId}/popup.html`);
-```
-
-**Возможности:** Весь функционал расширения включая API хранилища и service worker.
-
-**Источник:** [Playwright docs: Chrome extensions](https://playwright.dev/docs/chrome-extensions)
-
-### Стратегия 3: Документирование BLOCKED + эскалация
-
-Если ни одна из стратегий недоступна:
-1. Записать TC как `BLOCKED` с указанием причины
-2. Задокументировать шаги для ручного воспроизведения
-3. Создать HUMAN-тикет если сценарий критический
-
-**⛔ НЕ переключайся на code review или генерацию тестовых данных как замену реального тестирования** — это не входит в скоуп manual-testing.
-
-## Выбор стратегии
-
-Применяй стратегии строго по приоритету (сначала Стратегия 2, затем 1, затем 3):
-
-| Ситуация | Стратегия |
-|----------|-----------|
-| Доступен инструмент выполнения произвольного кода (например, `browser_run_code` / `execute_script`) | **Стратегия 2** — запусти Playwright programmatically, получи `chrome-extension://` URL |
-| Инструмент выполнения кода недоступен, но проект имеет тестовую HTML-страницу | Стратегия 1 → проверь shared knowledge проекта |
-| Оба варианта выше недоступны | Стратегия 3 |
-
-**⚠️ Наличие helper-модуля в проекте (`e2e/helpers/extension.ts` или аналог) = сигнал использовать Стратегию 2.** Проверь shared knowledge проекта на наличие готового helper перед выбором стратегии.
-
-**⛔ Стратегия 1 (HTTP-сервер) не заменяет Стратегию 2** — chrome.storage и другие Extension API недоступны в HTTP-контексте. Используй Стратегию 1 только если Стратегия 2 технически невозможна.
-
-## Тестирование API хранилища (при Стратегии 2)
-
-При наличии доступа к extension-контексту:
-
-```typescript
-// Читать состояние хранилища
-const data = await popup.evaluate(() =>
-  chrome.storage.local.get(null)  // null = все ключи
-);
-
-// Подготовить тест-данные в хранилище
-await popup.evaluate((testData) =>
-  chrome.storage.local.set(testData), testData
-);
-
-// Сбросить состояние между тестами
-await popup.evaluate(() => chrome.storage.local.clear());
-```
-
-## Типичные артефакты тестирования расширений
-
-| Тип артефакта | Что проверять |
-|---------------|---------------|
-| UI popup | Отображение элементов, навигация, формы |
-| Storage state | Структура данных, корректность сохранения |
-| Service Worker logs | Ошибки, предупреждения при операциях |
-| Extension API responses | Корректность применения настроек |
-
-<!-- РАСШИРЕНИЕ: добавляй специфические паттерны тестирования расширений ниже -->

package/src/skills/manual-testing/knowledge/browser-tools.md

@@ -1,114 +0,0 @@
-# Инструменты работы с браузером
-
-Справочник по инструментам и командам для тестирования через браузер.
-
-## Playwright MCP — основной инструмент
-
-### Навигация
-
-| Команда | Описание | Пример |
-|---------|----------|--------|
-| `browser_navigate` | Перейти по URL | `url: "https://example.com/login"` |
-| `browser_go_back` | Назад | — |
-| `browser_go_forward` | Вперёд | — |
-| `browser_wait` | Ожидание (мс) | `time: 2000` |
-
-### Взаимодействие с элементами
-
-| Команда | Описание | Параметры |
-|---------|----------|-----------|
-| `browser_click` | Клик по элементу | `element: "описание элемента"`, `ref: "ref_id"` |
-| `browser_type` | Ввод текста | `element: "описание поля"`, `ref: "ref_id"`, `text: "значение"` |
-| `browser_select_option` | Выбор из списка | `element: "описание"`, `ref: "ref_id"`, `values: ["value"]` |
-| `browser_hover` | Наведение курсора | `element: "описание"`, `ref: "ref_id"` |
-| `browser_drag` | Перетаскивание | `startElement`, `endElement` |
-
-### Фиксация состояния
-
-| Команда | Описание | Когда использовать |
-|---------|----------|-------------------|
-| `browser_screenshot` | Скриншот страницы | На каждом значимом шаге, при обнаружении бага |
-| `browser_snapshot` | Снимок accessibility tree | Для анализа структуры страницы |
-| `browser_console_messages` | Логи консоли | Проверка JS-ошибок |
-| `browser_network_requests` | Сетевые запросы | Проверка API-вызовов |
-
-### Управление вкладками
-
-| Команда | Описание |
-|---------|----------|
-| `browser_tab_list` | Список открытых вкладок |
-| `browser_tab_new` | Открыть новую вкладку |
-| `browser_tab_select` | Переключиться на вкладку |
-| `browser_tab_close` | Закрыть вкладку |
-
-### Работа с файлами
-
-| Команда | Описание |
-|---------|----------|
-| `browser_file_upload` | Загрузка файла в input[type=file] |
-| `browser_pdf_save` | Сохранить страницу как PDF |
-
-## Паттерны тестирования через браузер
-
-### Проверка формы
-
-```
-1. browser_navigate → страница с формой
-2. browser_screenshot → начальное состояние
-3. browser_type → заполнить каждое поле
-4. browser_click → отправить форму
-5. browser_screenshot → результат
-6. Проверить: URL изменился? Сообщение об успехе? Ошибки?
-```
-
-### Проверка авторизации
-
-```
-1. browser_navigate → /login
-2. browser_type → email
-3. browser_type → password
-4. browser_click → кнопка входа
-5. browser_wait → ожидание редиректа
-6. browser_screenshot → проверка dashboard
-7. Проверить: URL = /dashboard? Имя пользователя отображается?
-```
-
-### Проверка ошибок
-
-```
-1. browser_navigate → целевая страница
-2. Выполнить действие, вызывающее ошибку
-3. browser_console_messages → проверить JS-ошибки
-4. browser_network_requests → проверить 4xx/5xx ответы
-5. browser_screenshot → зафиксировать состояние
-```
-
-## cURL — проверка API
-
-```bash
-# GET запрос
-curl -v https://api.example.com/endpoint
-
-# POST с данными
-curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' URL
-
-# С авторизацией
-curl -H "Authorization: Bearer TOKEN" URL
-```
-
-Проверяй:
-- Статус-код (200, 201, 400, 401, 403, 404, 500)
-- Тело ответа (структура JSON, данные)
-- Заголовки ответа (Content-Type, Cache-Control)
-- Время ответа
-
-## Советы
-
-- **Артефакты — в `reports/`** — все скриншоты и файлы сохраняй в `reports/` в корне проекта, не в корень
-- **Всегда делай скриншот перед действием** — чтобы зафиксировать начальное состояние
-- **Используй `browser_snapshot`** для получения ref-идентификаторов элементов
-- **Проверяй консоль** после каждого значимого действия — JS-ошибки часто скрыты
-- **Ожидание** — если страница загружается медленно, используй `browser_wait`
-- **Несколько вкладок** — для тестирования одновременных сессий используй `browser_tab_new`
-
-<!-- РАСШИРЕНИЕ: добавляй новые инструменты и паттерны тестирования ниже -->

package/src/skills/manual-testing/knowledge/desktop-tools-advanced.md

@@ -1,92 +0,0 @@
-# Desktop-инструменты: Advanced
-
-Редко используемые команды и паттерны Windows-MCP. Загружай при работе со Snapshot, MultiEdit, Registry, Process, или при необходимости установки/настройки.
-
-## Установка Windows-MCP
-
-**Требования:** Python 3.13+, UV package manager (`pip install uv`).
-
-```json
-// Claude Code (.mcp.json) — на Windows нужен враппер cmd /c
-{ "mcpServers": { "windows-mcp": { "command": "cmd", "args": ["/c", "uvx", "windows-mcp"] } } }
-```
-
-## Управление приложениями
-
-| Команда | Описание | Параметры |
-|---------|----------|-----------|
-| `app` | Запуск/resize/move/switch окон | `action`, `app_name`, размеры |
-| `shell` | PowerShell-команды | `command: string` |
-
-## Работа с данными
-
-| Команда | Описание | Параметры |
-|---------|----------|-----------|
-| `clipboard` | Буфер обмена | `action: "read"/"set"`, `content` |
-| `multi_select` | Множественный выбор | `coordinates: [[x,y], ...]`, `use_ctrl` |
-| `multi_edit` | Ввод в несколько полей | `fields: [{x, y, text}, ...]` |
-
-## Системные инструменты
-
-| Команда | Описание | Параметры |
-|---------|----------|-----------|
-| `process` | Список/завершение процессов | `action: "list"/"terminate"`, `pid`/`name` |
-| `notification` | Toast-уведомление | `title`, `message` |
-| `registry` | Реестр Windows | `action: "read"/"write"/"delete"/"list"`, `path` |
-
-## Accessibility Tree
-
-Snapshot возвращает дерево UI Automation с:
-- **ID элементов** — для точных кликов через `label: int`
-- **Имена и роли** — Button, TreeItem, MenuItem
-- **Координаты** — для click/type когда label недоступен
-- **Состояния** — enabled/disabled, expanded/collapsed, checked/unchecked
-
-## Batch-действия
-
-Группируй 2-3 MCP-вызова перед проверочным Snapshot. Каждый цикл «действие → Wait → Snapshot» стоит ~30-40 сек.
-
-```
-# ❌ Click(tab) → Wait → Snapshot → Click(button) → Wait → Snapshot
-# ✅ Click(tab) → Click(button) → Snapshot (проверка результата)
-```
-
-Промежуточный Snapshot — только если следующее действие зависит от координат, которых ещё нет.
-
-## Проверка Developer Console (DevTools)
-
-1. `Shortcut("Ctrl+Shift+I")` — открыть DevTools
-2. Snapshot → прочитать **счётчик ошибок** в заголовке Console (`🔴 N errors`)
-3. Если счётчик > 0 — прокрутить лог вверх, проверить каждую ошибку
-4. Отличить ошибки расширения от системных (Chromium, телеметрия)
-5. PASS только если ошибок расширения = 0
-
-**Антипаттерн:** игнорировать счётчик «19 errors» в заголовке, увидев одну строку внизу.
-
-## Window management
-
-Если `Shortcut` не закрыл/переключил окно:
-1. `App(action: "switch", app_name: "...")` — перефокусировка
-2. Click по title bar — альтернативная перефокусировка
-3. Click по X — для закрытия через Snapshot + координаты
-
-**Не повторяй тот же Shortcut** — если не сработал первый раз, повтор не поможет.
-
-## Ctrl+Click альтернативы
-
-| Задача | Альтернатива |
-|--------|-------------|
-| Go to Definition | F12 |
-| Open Link | Command Palette → `Open Link` |
-| Открыть файл по пути | `Ctrl+P` → ввести путь → Enter |
-
-**Если TC требует Ctrl+Click — отметь BLOCKED** с причиной «MCP не поддерживает модификаторы + Click».
-
-## Советы
-
-- **Артефакты — в `reports/`**, не в корень проекта
-- **Верификация перед действием** — убедись через Snapshot что элемент существует, не полагайся на визуальную интерпретацию
-- **`shortcut` для навигации** — Command Palette быстрее поиска кнопок мышью
-- **`shell` для подготовки** — создание тестовых файлов, запуск приложений с параметрами
-
-<!-- РАСШИРЕНИЕ: добавляй advanced-паттерны ниже -->

package/src/skills/manual-testing/knowledge/desktop-tools-core.md

@@ -1,76 +0,0 @@
-# Desktop-инструменты: Core
-
-Справочник по основным командам Windows-MCP для тестирования desktop-приложений через Accessibility Tree.
-
-## Основные команды
-
-| Команда | Описание | Ключевые параметры |
-|---------|----------|--------------------|
-| `screenshot` | Быстрый скриншот рабочего стола | `display: [0]` (опционально) |
-| `snapshot` | A11y tree + скриншот (дорогой) | `use_vision: bool`, `use_dom: bool` |
-| `click` | Клик по элементу | `loc: [x,y]` или `label: int`, `button`, `double` |
-| `type` | Ввод текста | `loc`/`label` (обязательно), `text`, `press_enter`, `clear` |
-| `scroll` | Прокрутка | `direction`, `wheel_times: int`, `loc: [x,y]` (предпочтительно) |
-| `shortcut` | Клавиатурная комбинация | `shortcut: "ctrl+shift+p"` |
-| `scrape` | Извлечение текста окна | — |
-| `wait` | Пауза | `duration: float` |
-
-> **Типы параметров:** `loc` — массив `[x, y]`, не строка. `label` — int. `wheel_times` — int. Нативные типы, без кавычек.
-
-> **click/type/scroll требуют `loc` или `label`.** Для scroll предпочитай `loc` — label-ID устаревают между Snapshot-ами.
-
-## Label-based навигация (ПРИОРИТЕТ)
-
-**Всегда предпочитай `Click(label=N)` вместо `Click(loc=[x,y])`** — координаты нестабильны при resize/collapse.
-
-- `label` — **числовой ID** из столбца `# id` в Snapshot. Текстовые имена (`Click(label="Save")`) вызовут ошибку `int_parsing`
-- **Label-ID ОДНОРАЗОВЫЕ** — валидны только сразу после Snapshot. Любое действие между Snapshot и Click может сдвинуть ID
-- При ошибке «Label N out of range» — **не повторяй**, сделай новый Snapshot и найди элемент по текстовому имени
-
-**Паттерн:** запомни текстовое имя элемента → при каждом Snapshot ищи его числовой ID → передавай в Click(label=N).
-
-## Snapshot budget
-
-Snapshot — ~5-10k tokens. Чрезмерное использование вызывает context overflow.
-
-| Когда делать | Когда НЕ делать |
-|-------------|-----------------|
-| Первый раз — ориентация в UI | После Escape/закрытия меню |
-| После действия, меняющего набор элементов | Если label уже известен |
-| Верификация появления/исчезновения элемента | «Проверка что ничего не сломалось» |
-
-**Лимиты:** 1-2 Snapshot/TC, максимум 6/сессию. После нового Snapshot все предыдущие label-ID невалидны.
-
-**`use_vision: false`** по умолчанию (экономия токенов). `true` — только когда нужна визуальная интерпретация.
-
-## Minimal Thinking
-
-Между MCP-вызовами — максимум 1 короткая строка. Анализ и выводы — в тикет.
-
-## Прокрутка списков
-
-Перед выводом «элемент отсутствует» — прокрути в обоих направлениях:
-1. Snapshot → найти scrollable element, проверить `vertical_scroll_percent`
-2. Scroll up до `scroll_percent = 0` → Snapshot → проверить
-3. Scroll down до конца → Snapshot → проверить
-4. Только после полной прокрутки можно утверждать «элемента нет»
-
-**Антипаттерн:** dropdown может быть открыт в середине списка — элемент может быть выше видимой области.
-
-## Выбор MCP-сервера
-
-**⛔ Desktop-приложения тестируются ТОЛЬКО через Sandbox.** Используй `sandbox-desktop`.
-
-| Среда | MCP-сервер | Префикс вызова |
-|-------|-----------|----------------|
-| Windows Sandbox (обязательно) | `sandbox-desktop` | `mcp__sandbox-desktop__*` |
-
-Проверь `.mcp.json` проекта. В Sandbox **не используй `Wait`** — латентность MCP (3-10 сек) достаточна для обновления UI.
-
-## Ключевые ограничения
-
-- **Ctrl+Click невозможен** через MCP (нет модификаторов). Альтернативы: F12, Command Palette, Ctrl+P
-- A11y tree не всегда гранулярен до символа
-- В Sandbox начинай с `snapshot` — a11y tree надёжнее для верификации
-
-<!-- РАСШИРЕНИЕ: добавляй новые core-паттерны ниже -->

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

@@ -1,83 +0,0 @@
-# Тестирование в Windows Sandbox — Advanced
-
-Расширенные сценарии: настройка .wsb, паттерны тестирования, MCP disconnect, управление контекстом. Базовые знания → `knowledge/sandbox-core.md`.
-
-## Конфигурация .wsb файла
-
-```xml
-<Configuration>
-  <MappedFolders>
-    <MappedFolder>
-      <HostFolder><!-- путь к проекту --></HostFolder>
-      <SandboxFolder><!-- путь в Sandbox --></SandboxFolder>
-      <ReadOnly>false</ReadOnly>
-    </MappedFolder>
-  </MappedFolders>
-  <Networking>Enable</Networking>
-  <vGPU>Enable</vGPU>
-  <ClipboardRedirection>Enable</ClipboardRedirection>
-  <LogonCommand><Command><!-- путь к setup.cmd --></Command></LogonCommand>
-</Configuration>
-```
-
-Конкретные пути — см. `CLAUDE.md` и `.wsb`-файл в sandbox-директории. Офлайн-пакет содержит портативные Python, Node.js и wheels для `windows-mcp`. Копируй Python на `C:\sandbox\` (mapped folders могут быть read-only для pip).
-
-## Паттерны тестирования
-
-**Полный цикл:** Sandbox → LogonCommand → MCP подключение → запуск приложения → тест-кейсы → evidence в mapped folder → закрытие.
-
-**Сравнение окружений:** один и тот же TC на хосте и в Sandbox — расхождения указывают на зависимость от окружения.
-
-**Регрессия двух версий:** Sandbox 1 (текущая) → скриншоты → закрыть → Sandbox 2 (новая) → те же TC → сравнить.
-
-## Приоритизация TC по длительности
-
-| Фаза | Тип TC | MCP-вызовов |
-|------|--------|-------------|
-| Сначала | Быстрые (Snapshot + визуальная верификация) | 2-3 |
-| Затем | Действие + проверка | 4-6 |
-| В конце | Длительные с ожиданием | 6-10 |
-
-Чем дольше TC — тем выше риск MCP disconnect. Быстрые TC первыми.
-
-## MCP disconnect
-
-### Sandbox закрылся
-
-1. Немедленно зафиксируй результаты в тикет
-2. Не пытайся переподключиться — Sandbox закрыт
-3. Evidence на хосте сохранены (mapped folder пишет на диск хоста)
-
-### MCP-прокси умер, Sandbox жив
-
-MCP-инструменты возвращают «server not connected», но окно Sandbox видно. **Не реализуй HTTP-клиент** — это rabbit hole.
-
-1. Зафиксируй выполненные TC
-2. Пометь оставшиеся TC как BLOCKED: «MCP proxy disconnected»
-3. Завершай тикет — следующая сессия продолжит
-
-## Управление контекстом и continuation
-
-### Планирование continuation
-
-Рассчитай `max_TC_per_session` по формуле из `algorithms/mcp-budget.md`. Если TC больше — запланируй разбивку по сессиям до начала тестирования.
-
-### Признаки context overflow
-
-- Контекст >70% заполнен — завершай текущий TC
-- 6+ Snapshot за сессию — переключись на Screenshot
-- Модель «забывает» ранние TC — немедленно фиксируй прогресс
-
-### Действия при overflow
-
-1. Завершай текущий TC (PASS/FAIL/BLOCKED)
-2. Запиши результаты, evidence paths, оставшиеся TC
-3. Заверши сессию — не пытайся «успеть ещё один TC»
-
-### Антипаттерн: ожидание смены UI-состояния
-
-Не трать MCP-вызовы на цикл `Wait → Screenshot → «не сменилось»`. Запускай действие сразу:
-```
-# ❌ Wait(5) → Screenshot → "ещё Completed" → Wait(8) → Screenshot
-# ✅ Shortcut(ctrl+shift+p) → Type("<команда>") → Snapshot
-```