workflow-ai 1.0.64 → 1.0.66

package/src/skills/decompose-plan/workflows/decompose.md

@@ -32,11 +32,11 @@
 
 **⛔ Задача плана ≠ тикет.** Задача плана — это кандидат на разбиение, а не готовый тикет. Одна задача плана может (и часто должна) превратиться в 2+ тикетов. Количество тикетов ≥ количества задач плана. Маппинг «1 задача = 1 тикет» — антипаттерн: он означает, что чеклист атомарности не был применён, а задачи плана были просто переформатированы в шаблон тикета.
 
-**ОБЯЗАТЕЛЬНО** для каждого тикета-кандидата — чеклист атомарности (6 проверок). Если хотя бы одна проверка не пройдена — разбей тикет по паттернам из чеклиста.
+**ОБЯЗАТЕЛЬНО** для каждого тикета-кандидата — чеклист атомарности (7 проверок). Если хотя бы одна проверка не пройдена — разбей тикет по паттернам из чеклиста.
 
 **⛔ Единственная допустимая реакция на FAIL — разбиение на 2+ тикетов.** Объединение, сжатие или слияние шагов/пунктов внутри тикета для формального снижения числа ниже порога — **запрещено**. Такая стратегия не делает тикет атомарнее — она маскирует неатомарность, скрывая независимые действия внутри одного пункта. Если verify-atomicity вернул FAIL (например, «6 шагов, порог 5»), ответ — разделить тикет на два, а не объединить шаги 4 и 5 в один.
 
-**⛔ Обязательная фиксация результата чеклиста.** Перед записью каждого тикета в файл выпиши inline-таблицу результатов 6 проверок атомарности:
+**⛔ Обязательная фиксация результата чеклиста.** Перед записью каждого тикета в файл выпиши inline-таблицу результатов 7 проверок атомарности:
 
 ```
 Тикет-кандидат: «{title}»
@@ -48,6 +48,7 @@
 | 4. Нет скрытых подзадач | PASS/FAIL | ... |
 | 5. Размер | PASS/FAIL | ... |
 | 6. Независимая верификация | PASS/FAIL | ... |
+| 7. Один исполнитель | PASS/FAIL | ... |
 → Решение: СОЗДАТЬ / РАЗБИТЬ на N тикетов
 ```
 
@@ -107,11 +108,23 @@
 
 → Загрузи `knowledge/human-task-rules.md`
 
+Маршрутизация — **двухступенчатая проверка**, оба условия обязательны для HUMAN:
+
+1. **Условие недоступности:** агент физически не может выполнить задачу (нет инструмента, нет доступа, нет прав).
+2. **Условие HUMAN-семантики:** задача подпадает под один из критериев таблицы «Когда задача = HUMAN» из `knowledge/human-task-rules.md` (внешние системы с аутентификацией, физические действия, бизнес-решения, приватные данные, финансовые транзакции).
+
 | Категория | Критерий | Действие |
 |-----------|----------|----------|
-| **Полностью автономная** | Агент может выполнить все шаги | `executor_type: agent` |
-| **Полностью ручная** | Требует действий, недоступных агенту | Префикс `HUMAN`, `executor_type: human` |
-| **Гибридная** | Часть — агент, часть — человек | Разбить на 2 тикета с зависимостью |
+| **Полностью автономная** | Агент может выполнить все шаги | `executor_type: agent`, тип по маршрутизации шага 4 |
+| **Полностью ручная** | Оба условия (недоступность **и** HUMAN-семантика) выполнены | Префикс `HUMAN`, `executor_type: human` |
+| **Гибридная** | Часть — агент, часть подпадает под оба условия HUMAN | Разбить на 2 тикета с зависимостью |
+| **Вне scope декомпозиции** | Недоступность агенту **есть**, но HUMAN-семантика **не подтверждена** | Тикет не создаётся; действие выполняется стейкхолдером вне пайплайна; при необходимости — строка в «Рекомендации для следующего плана» |
+
+**⛔ Антипаттерн «fallback в HUMAN»:** получить FAIL на условии 1 (агент не может) и сразу назначить префикс `HUMAN`, не проверив условие 2. Недоступность агенту — необходимое, но не достаточное условие HUMAN. Типичные ошибки маршрутизации: git-операции проекта (commit, push, merge, release, tag), CI/CD-триггеры, ручной деплой через стандартные инструменты стейкхолдера — это **не HUMAN**, потому что не соответствуют HUMAN-семантике из `knowledge/human-task-rules.md`. Они выпадают из scope декомпозиции целиком.
+
+**Как отличить HUMAN от «вне scope»:** задай два вопроса подряд.
+- Вопрос 1: может ли агент технически выполнить это действие сейчас? Если да — категория «автономная», HUMAN не рассматривается.
+- Вопрос 2 (только при «нет» на вопрос 1): задача относится к одному из критериев таблицы «Когда задача = HUMAN»? Если да — HUMAN. Если нет — «вне scope декомпозиции».
 
 ### 4. Определить тип каждого тикета
 
@@ -227,6 +240,24 @@
 
 **Антипаттерн:** «возьму номера из головы, раз скрипт теперь не вызывается напрямую». `id_ranges` — **единственный** допустимый источник. Любое отклонение (включая «начну с 001, потом исправлю») ломает ссылочную целостность: после записи файла ID уже попадает в перекрёстные ссылки (`depends_on`, `parent_plan`, упоминания в плане и отчётах) — переименование становится масштабной правкой с риском рассинхрона.
 
+#### 9.C ⛔ СТОП-ГЕЙТ: выписка реестра `required_capabilities` из конфига (выполняется до любых Write/Edit тикетов)
+
+До создания **любого** файла тикета обязательно выполни процедуру из `knowledge/capabilities.md` → «Обязательная процедура перед заполнением `required_capabilities`»:
+
+1. **Прочитай** pipeline-конфиг проекта (стандартный путь — `.workflow/config/pipeline.yaml`; если в проекте другой — ориентируйся на фактический). Агенты и их capabilities — в секции `agents.*.capabilities`.
+2. **Выпиши в рассуждении явным списком** union всех значений `agents.*.capabilities` из конфига. Например (иллюстрация формата, не значения):
+   ```
+   capabilities_registry: [<ключ_1>, <ключ_2>, ...]
+   ```
+   Конкретные значения берутся **только** из фактического конфига текущего проекта — не из памяти, не из других проектов.
+3. Эта выписка — **единственный допустимый словарь** для поля `required_capabilities` на всю декомпозицию. При заполнении поля на шаге 9.1 каждый ключ должен присутствовать в `capabilities_registry`. Ключ, которого в выписке нет, — изобретённый, его нельзя записывать в тикет.
+
+**Без явной фиксации `capabilities_registry` в рассуждении стоп-гейт считается пропущенным.** Отсутствие выписки = нарушение контракта стадии.
+
+**Почему это стоп-гейт:** тикет с изобретённым capability физически не может быть исполнен — ни один агент не покрывает несуществующий ключ, пайплайн блокирует execute-task по `no_capable_agent`. Цикл retry → blocked расходует слоты попыток и блокирует весь план. Исправление задним числом требует ручной правки тикетов + перезапуска — проще один раз свериться с реестром перед записью.
+
+**Антипаттерн (описание задачи вместо способности агента):** записать в `required_capabilities` ключ, описывающий **предметную область задачи** (язык, платформу, подсистему), а не способность агента-исполнителя. Подробнее см. `knowledge/capabilities.md` → «Антипаттерн: изобретение ключей по предметной области». Критерий отсечения: если ключа нет в `capabilities_registry` — не записывай, как бы хорошо он ни «описывал задачу».
+
 #### 9.1 Создание каждого тикета
 
 Для **каждого** тикета:
@@ -240,6 +271,8 @@
 
    > **⛔ Структура заголовков тикета должна точно соответствовать шаблону.** Секция DoD обязана быть на уровне `##` (`## Критерии готовности (Definition of Done)` или `## Definition of Done`) и находиться как самостоятельный блок верхнего уровня — **не вкладывай её внутрь другой секции** (`## Детали задачи` и т.п.). Нарушение уровня заголовка (например, `###` вместо `##`) делает тикет невидимым для автоматических проверок пайплайна (verify-artifacts) и приведёт к бесконечному циклу ретраев.
 
+   > **⛔ Валидация `required_capabilities` по реестру (СТОП-гейт на каждый тикет).** Перед записью тикета пройди по каждому ключу, который собираешься положить в `required_capabilities`, и убедись, что он присутствует в `capabilities_registry`, выписанном в 9.C. Если ключа нет в реестре — **не записывай его**: это изобретённый ключ, тикет будет немедленно заблокирован пайплайном по `no_capable_agent`. Допустимые реакции: (а) убрать ключ, если это описание задачи (язык, платформа, подсистема), а не способность агента; (б) заменить на ключ из реестра, если смысл сохраняется; (в) оставить поле `required_capabilities` пустым, если ни один ключ реестра не подходит. Подробности — `knowledge/capabilities.md`.
+
 4. Сохрани в `.workflow/tickets/backlog/{TYPE}-{NNN}.md`
 5. **Пост-валидация уникальности** (обязательно после каждого сохранения):
    - Выполни `Glob` по `.workflow/tickets/**/{TYPE}-{NNN}.md`

package/src/skills/execute-task/tests/cases/TC-EXECUTE-TASK-001/current/meta.json

@@ -1,89 +1,88 @@
-{
-  "date": "2026-04-19T18:01:41.819Z",
-  "skill_sha": "4ef92dc",
-  "status": "passed",
-  "duration_ms": 116198,
-  "l1_skipped": true,
-  "per_model": {
-    "claude-haiku": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-free": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-glm-air": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    }
-  },
-  "rubric_scores": [
-    {
-      "agentId": "claude-haiku",
-      "trial": 1,
-      "score": 4,
-      "errored": false
-    },
-    {
-      "agentId": "claude-haiku",
-      "trial": 2,
-      "score": 4,
-      "errored": false
-    },
-    {
-      "agentId": "claude-haiku",
-      "trial": 3,
-      "score": 4,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-free",
-      "trial": 1,
-      "score": 4,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-free",
-      "trial": 2,
-      "score": 4,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-free",
-      "trial": 3,
-      "score": 4,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm-air",
-      "trial": 1,
-      "score": 4,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm-air",
-      "trial": 2,
-      "score": 4,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm-air",
-      "trial": 3,
-      "score": 4,
-      "errored": false
-    }
-  ]
+{
+  "date": "2026-04-21T16:43:17.768Z",
+  "skill_sha": "1503ea1",
+  "status": "passed",
+  "duration_ms": 2,
+  "per_model": {
+    "claude-haiku": {
+      "passed": true,
+      "errored": false,
+      "pass_count": 3,
+      "error_count": 0,
+      "total": 3,
+      "threshold": 2
+    },
+    "kilo-free": {
+      "passed": true,
+      "errored": false,
+      "pass_count": 3,
+      "error_count": 0,
+      "total": 3,
+      "threshold": 2
+    },
+    "kilo-glm-air": {
+      "passed": true,
+      "errored": false,
+      "pass_count": 3,
+      "error_count": 0,
+      "total": 3,
+      "threshold": 2
+    }
+  },
+  "rubric_scores": [
+    {
+      "agentId": "claude-haiku",
+      "trial": 1,
+      "score": 4,
+      "errored": false
+    },
+    {
+      "agentId": "claude-haiku",
+      "trial": 2,
+      "score": 4,
+      "errored": false
+    },
+    {
+      "agentId": "claude-haiku",
+      "trial": 3,
+      "score": 4,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-free",
+      "trial": 1,
+      "score": 4,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-free",
+      "trial": 2,
+      "score": 4,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-free",
+      "trial": 3,
+      "score": 4,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-glm-air",
+      "trial": 1,
+      "score": 4,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-glm-air",
+      "trial": 2,
+      "score": 4,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-glm-air",
+      "trial": 3,
+      "score": 4,
+      "errored": false
+    }
+  ]
 }

package/src/skills/execute-task/tests/cases/TC-EXECUTE-TASK-005/current/meta.json

@@ -1,89 +1,88 @@
-{
-  "date": "2026-04-19T18:01:43.724Z",
-  "skill_sha": "4ef92dc",
-  "status": "passed",
-  "duration_ms": 99372,
-  "l1_skipped": true,
-  "per_model": {
-    "claude-haiku": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-free": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-glm-air": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    }
-  },
-  "rubric_scores": [
-    {
-      "agentId": "claude-haiku",
-      "trial": 1,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "claude-haiku",
-      "trial": 2,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "claude-haiku",
-      "trial": 3,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-free",
-      "trial": 1,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-free",
-      "trial": 2,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-free",
-      "trial": 3,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm-air",
-      "trial": 1,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm-air",
-      "trial": 2,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm-air",
-      "trial": 3,
-      "score": 5,
-      "errored": false
-    }
-  ]
+{
+  "date": "2026-04-21T16:43:17.772Z",
+  "skill_sha": "1503ea1",
+  "status": "passed",
+  "duration_ms": 2,
+  "per_model": {
+    "claude-haiku": {
+      "passed": true,
+      "errored": false,
+      "pass_count": 3,
+      "error_count": 0,
+      "total": 3,
+      "threshold": 2
+    },
+    "kilo-free": {
+      "passed": true,
+      "errored": false,
+      "pass_count": 3,
+      "error_count": 0,
+      "total": 3,
+      "threshold": 2
+    },
+    "kilo-glm-air": {
+      "passed": true,
+      "errored": false,
+      "pass_count": 3,
+      "error_count": 0,
+      "total": 3,
+      "threshold": 2
+    }
+  },
+  "rubric_scores": [
+    {
+      "agentId": "claude-haiku",
+      "trial": 1,
+      "score": 5,
+      "errored": false
+    },
+    {
+      "agentId": "claude-haiku",
+      "trial": 2,
+      "score": 5,
+      "errored": false
+    },
+    {
+      "agentId": "claude-haiku",
+      "trial": 3,
+      "score": 5,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-free",
+      "trial": 1,
+      "score": 5,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-free",
+      "trial": 2,
+      "score": 5,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-free",
+      "trial": 3,
+      "score": 5,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-glm-air",
+      "trial": 1,
+      "score": 5,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-glm-air",
+      "trial": 2,
+      "score": 5,
+      "errored": false
+    },
+    {
+      "agentId": "kilo-glm-air",
+      "trial": 3,
+      "score": 5,
+      "errored": false
+    }
+  ]
 }

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

@@ -18,11 +18,13 @@ ticket_prefix: QA
 
 **Ты НЕ делаешь:** нагрузочное/перформанс-тестирование (передай соответствующему скилу), исправление найденных багов (зафиксируй дефект в QA-тикете — исправление выполнит соответствующий скил), принятие решений о релизе (только предоставляешь данные для решения).
 
-**⛔ ЗАПРЕЩЕНО даже если инструменты заблокированы:** подменять реальное тестирование написанием кода без его прогона, code review исходников вместо реального тестирования, генерация тестовых данных как замена запуска тест-кейсов, **запуск уже существующих автотестов разработки и выдача их за ручную проверку**. Граница: написать тест и **реально его запустить** с записью результата — легитимное тестирование (если это разрешено правилами проекта в `../shared/`); написать тест без запуска или с фейковым результатом — призрачное выполнение, антипаттерн. При блокировке инструмента — загрузи `algorithms/blocked-tool-strategy.md`.
+**⛔ ЗАПРЕЩЕНО даже если инструменты заблокированы:** 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/README.md` есть в проекте, прочитай его и загрузи модули по триггеру «работа с тестами проекта»: проект мог задать специфику размещения и именования. Если `../shared/` отсутствует — разместить тест рядом с существующими тестами того же уровня и использовать принятые в репозитории конвенции именования. Отсутствие shared не отменяет и не запрещает QA-работу по написанию ассертов для не-UI инвариантов.
 
 ## Взаимодействие
 
@@ -64,7 +66,7 @@ ticket_prefix: QA
 
 ## Загрузка знаний
 
-⛔ **Обязательный первый шаг:** прочитай `../shared/README.md` и загрузи все релевантные модули (карта UI, тестовые workspace'ы, проектные правила). Без shared ты не знаешь пути, конфигурацию и ограничения конкретного продукта — начинать тестирование без этого запрещено.
+⛔ **Обязательный первый шаг (если `../shared/README.md` присутствует):** прочитай его и загрузи все релевантные модули (карта UI, тестовые workspace'ы, проектные правила). Без shared ты не знаешь проектно-специфичные пути, конфигурацию и ограничения продукта. Если `../shared/` в проекте отсутствует — действуй по общим правилам скила; это не блокирует выполнение QA-тикета, а означает, что проект не задал проектные настройки поверх дефолтов.
 
 | Модуль | Когда загружать |
 |--------|----------------|
@@ -163,7 +165,7 @@ ticket_prefix: QA
 
 ## Границы компетенции
 
-- **Написание автотестов в коде как зона ответственности** → соответствующий скил разработки. Исключение: если правила проекта в `../shared/` явно разрешают QA писать/дополнять тесты как инструмент проверки — действуй по правилам shared (с обязательным реальным запуском, см. ⛔ выше)
+- **Подмена ручной проверки UI-наблюдаемого поведения запуском автотестов** → запрещено (см. ⛔ антипаттерн выше). Написание и реальный запуск ассертов для инвариантов, не выражающихся через UI (ФС, данные, структура файла), — в зоне QA; правила размещения/именования тестов, если заданы проектом, ищи в `../shared/`
 - **Нагрузочное тестирование** → соответствующий скил проекта
 - **Исправление багов** → соответствующий скил через тикет
 - **Решение о релизе** → принимает ответственный скил проекта

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

@@ -1,21 +1,34 @@
-Согласно таблице инструментов в скиле:
+## Стратегия тестирования VSCode-расширения
 
-| Критерий | Выбор |
-|----------|-------|
-| **Тип приложения** | Desktop (VSCode-расширение) |
-| **Основной инструмент** | Windows-MCP **через Sandbox** |
-| **Knowledge-модули** | `knowledge/desktop-tools-core.md` + `knowledge/sandbox-core.md` |
+### Инструмент
 
-**Среда запуска: Windows Sandbox — обязательно.**
+**Windows-MCP через Windows Sandbox** — единственный допустимый вариант для desktop-приложений согласно матрице выбора инструмента:
 
-Прямое тестирование на хосте запрещено по двум причинам:
-1. Загрязняет рабочую среду разработчика (глобальные настройки VSCode, установленные расширения).
-2. Не воспроизводит чистое состояние — нельзя гарантировать изоляцию между тест-запусками.
+| Тип приложения | Инструмент | Knowledge |
+|---|---|---|
+| Desktop (VSCode-расширение) | **Windows-MCP через Sandbox** | `desktop-tools-core.md` + `sandbox-core.md` |
 
-**Порядок подготовки:**
+### Среда запуска: Windows Sandbox
 
-1. Прочитать `../shared/README.md` — узнать пути, конфигурацию, проектные ограничения.
-2. Загрузить `knowledge/sandbox-core.md` — настройка Sandbox, quick-start, персистенция evidence.
-3. Загрузить `knowledge/desktop-tools-core.md` — команды Windows-MCP, паттерны навигации, бюджет Snapshot.
-4. Поднять Sandbox → установить расширение → выполнить тест-кейсы через Windows-MCP.
-5. Сохранить evidence (скриншоты/a11y assertions) из Sandbox до завершения сессии — файлы внутри 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.