workflow-ai 1.0.64 → 1.0.65

package/src/skills/decompose-plan/tests/cases/TC-DECOMPOSE-PLAN-006-dod-threshold.yaml

@@ -0,0 +1,72 @@
+id: TC-DECOMPOSE-PLAN-006
+title: "Декомпозитор соблюдает порог DoD ≤ 7 пунктов (Проверка 5) — разбивает тикет с толстым DoD"
+origin:
+  chg: []
+  incidents:
+    - "PulseProxy PLAN-014 (2026-04-20): decompose-plan на первой попытке создал IMPL-043 (8 пунктов DoD) и IMPL-045 (9 пунктов DoD). verify-atomicity.js FAIL → вторая декомпозиция (+8:36 мин). Root cause: Проверка 5 в atomicity-checklist.md упоминала только объём кода и время, но не число пунктов DoD, тогда как скрипт меряет именно этот инвариант (DOD_THRESHOLD_FAIL=7)."
+  principle: "Синхронизация инвариантов между чеклистом атомарности и verify-atomicity.js"
+  backlog_sources:
+    - ".workflow/coach-backlog.yaml"
+tags: [atomicity, dod, threshold, anti-pattern]
+severity: high
+
+scenario:
+  system_prompt_file: "../../SKILL.md"
+  extra_instructions: |
+    Декомпозируй следующую задачу плана на тикеты. Типы тикетов в проекте (из
+    `config.yaml → task_types`): IMPL (реализация), QA (автотесты), DOCS
+    (документация), ADMIN (инфраструктурные операции).
+
+    Перед созданием каждого тикета применяй чеклист атомарности (7 проверок).
+    Особое внимание — Проверке 5 «Оценка размера»: hard-порог verify-atomicity.js
+    по числу пунктов DoD = 7 (FAIL при >7). Если для задачи естественно выходит
+    больше 7 критериев готовности — это сигнал на разбиение, а не на сжатие
+    пунктов.
+  inputs:
+    - kind: inline
+      as: plan_content
+      content: |
+        Задача: Реализовать компонент выбора прокси по умолчанию (select-default-proxy-modal)
+          DoD:
+            - Файл src/popup/select-default-proxy-modal.ts создан по образцу public-proxies-modal.ts через ModalHelper
+            - Функция showSelectDefaultProxyModal(proxies) экспортируется и резолвит id выбранного прокси
+            - Закрытие крестиком или Esc резолвит null
+            - Edge case: при пустом списке прокси модалка не рендерит DOM и резолвит null сразу
+            - Заголовок модалки берётся из I18n.getMessage('selectDefaultProxyTitle')
+            - Модалка НЕ вызывает Storage.setDefaultProxy() внутри — запись в storage снаружи
+            - Модалка НЕ читает прокси из storage — принимает готовый список
+            - Каждый элемент списка отображает имя, host:port и флаг страны (если есть)
+
+assertions:
+  static:
+    - kind: skill_contains
+      file: "knowledge/atomicity-checklist.md"
+      pattern: "Число пунктов DoD"
+      reason: "В Проверке 5 должен быть явный пункт про число пунктов DoD."
+    - kind: skill_contains
+      file: "knowledge/atomicity-checklist.md"
+      pattern: "verify-atomicity.js"
+      reason: "Явная ссылка на скрипт, чтобы связь порогов была видна."
+    - kind: skill_contains
+      file: "knowledge/atomicity-checklist.md"
+      pattern: "7"
+      reason: "Числовое значение порога должно присутствовать в чеклисте."
+
+  deterministic:
+    - kind: output_matches
+      regex: "(5\\. )?Размер[\\s\\S]{0,400}(DoD|пункт)"
+      reason: "Проверка 5 должна явно упомянуть DoD-пункты в inline-таблице чеклиста."
+    - kind: output_does_not_contain
+      values: ["DoD содержит 8 пунктов", "DoD содержит 9 пунктов", "DoD содержит 10 пунктов"]
+      reason: "Ни один из созданных тикетов не должен декларировать DoD > 7 пунктов — это регрессия, verify-atomicity.js даст FAIL."
+
+  rubric:
+    - kind: llm_judge
+      rubric_file: "../rubrics/dod-threshold.md"
+      criterion: "Разбил ли агент задачу с 8+ пунктами DoD на тикеты с ≤ 7 пунктами каждый, и зафиксировал ли цифру числа пунктов DoD в evidence Проверки 5?"
+      pass_threshold: 4
+      trials: 3
+      aggregate: majority
+
+execution:
+  timeout_s: 2400

package/src/skills/decompose-plan/tests/index.yaml

@@ -28,3 +28,18 @@ cases:
     origin_chg: [CHG-040]
     tags: [dod-transfer, verbatim]
     severity: high
+  - id: TC-DECOMPOSE-PLAN-004
+    file: cases/TC-DECOMPOSE-PLAN-004-executor-atomicity.yaml
+    origin_chg: []
+    tags: [atomicity, executor]
+    severity: high
+  - id: TC-DECOMPOSE-PLAN-005
+    file: cases/TC-DECOMPOSE-PLAN-005-capabilities-registry.yaml
+    origin_chg: [CHG-076]
+    tags: [capabilities, pipeline-contract, anti-pattern]
+    severity: critical
+  - id: TC-DECOMPOSE-PLAN-006
+    file: cases/TC-DECOMPOSE-PLAN-006-dod-threshold.yaml
+    origin_chg: []
+    tags: [atomicity, dod, threshold]
+    severity: high

package/src/skills/decompose-plan/tests/rubrics/capabilities-registry.md

@@ -0,0 +1,21 @@
+# Rubric: Декомпозитор сверяет `required_capabilities` с реестром из pipeline-конфига
+
+## Критерий
+
+**Выписал ли агент явный `capabilities_registry` из `agents.*.capabilities` pipeline-конфига проекта до создания тикетов, и назначил ли `required_capabilities` строго из этого реестра — не изобретая ключей, описывающих предметную область задачи (язык, платформу, подсистему)?**
+
+Агент должен:
+1. До создания первого тикета прочитать pipeline-конфиг проекта (путь стандартно — `.workflow/config/pipeline.yaml`, либо как указано в конфиге проекта) и выписать в рассуждении явным списком union всех значений `agents.*.capabilities`. Эта выписка — единственный допустимый словарь для поля `required_capabilities` на всю декомпозицию.
+2. При заполнении `required_capabilities` каждого тикета сверять каждый ключ с этим словарём. Ключ, которого в словаре нет, — изобретённый, не записывается.
+3. Не подменять `required_capabilities` описанием предметной области задачи (имена языков программирования, типов проектов, платформ, подсистем), если эти имена не задекларированы в реестре.
+4. Если ни один ключ реестра не применим — оставить поле пустым, а не изобретать ключ «по смыслу».
+
+## Шкала оценки (1–5)
+
+| Балл | Описание |
+|------|----------|
+| **5** | Агент явно выписал `capabilities_registry` из конфига до создания тикетов, у каждого созданного тикета `required_capabilities` — строго подмножество реестра (либо пусто). Изобретённых ключей нет. |
+| **4** | Реестр выписан неявно (агент перечислил допустимые ключи в рассуждении, но без явного названия «capabilities_registry»); все тикеты содержат только ключи из реестра или пустое поле. |
+| **3** | Реестр не выписан, но де-факто все `required_capabilities` ограничены ключами из реестра — совпадение по результату, не по процедуре. |
+| **2** | В одном или нескольких тикетах встречается хотя бы один изобретённый ключ (описание языка/платформы/подсистемы, отсутствующее в реестре). |
+| **1** | Поле `required_capabilities` массово заполнено именами предметной области (язык, фреймворк, платформа, аспект) без какой-либо сверки с реестром. |

package/src/skills/decompose-plan/tests/rubrics/dod-threshold.md

@@ -0,0 +1,21 @@
+# Rubric: Декомпозитор соблюдает порог числа пунктов DoD (Проверка 5)
+
+## Критерий
+
+**Если задача плана требует больше 7 пунктов DoD в одном тикете, разбил ли агент тикет на 2+ атомарных тикета так, чтобы каждый результирующий тикет содержал ≤ 7 пунктов DoD? И явно ли зафиксирована в inline-таблице чеклиста (Проверка 5) фактическая цифра числа пунктов DoD как evidence?**
+
+Агент должен:
+1. При декомпозиции задачи, естественно порождающей длинный DoD (8+ пунктов), распознать это на Проверке 5 и разбить тикет по группам независимых DoD-пунктов.
+2. Ни один из финально созданных тикетов не должен содержать > 7 пунктов DoD (hard-порог `verify-atomicity.js` → иначе FAIL → повторный прогон декомпозиции → потеря 5-10 минут пайплайна).
+3. Evidence-строка для Проверки 5 в inline-таблице должна содержать явное число пунктов DoD (например, «DoD содержит 5 пунктов, все проверяют создание компонента»), а не только «PASS».
+4. Если исходная задача слита из независимых групп критериев — каждая группа → отдельный тикет со своим префиксом (если тип разный) или своим суффиксом/номером (если тип один).
+
+## Шкала оценки (1–5)
+
+| Балл | Описание |
+|------|----------|
+| **5** | Агент явно обнаружил на Проверке 5 превышение порога 7, разбил тикет на 2+ с DoD ≤ 7 у каждого. Evidence-строка содержит цифру числа пунктов. |
+| **4** | Все созданные тикеты содержат DoD ≤ 7; разбиение выполнено, но явное обнаружение «превышен порог» в рассуждении не зафиксировано. |
+| **3** | Один из тикетов имеет 8+ пунктов DoD (или агент оставил задачу в одном толстом тикете). Evidence-строка отсутствует или не содержит цифру. |
+| **2** | Несколько тикетов имеют 8+ пунктов DoD, разбиения по DoD нет совсем. |
+| **1** | Агент собрал весь DoD задачи в один тикет без прогона Проверки 5 в явном виде. |

package/src/skills/decompose-plan/tests/rubrics/executor-atomicity.md

@@ -0,0 +1,21 @@
+# Rubric: Декомпозитор применяет executor-атомарность (Проверка 7)
+
+## Критерий
+
+**Разбил ли агент задачу на отдельные тикеты, если пункты DoD требуют разных типов исполнителя по `config.yaml → task_types`, и удалил ли из DoD пункты, выполняемые стейкхолдером (git-операции)?**
+
+Агент должен:
+1. Пройти по пунктам DoD задачи плана и для каждого определить тип тикета из `config.yaml → task_types`, который был бы создан, если бы этот пункт был единственной задачей.
+2. Если ответы расходятся между пунктами одного тикета — разбить на парные тикеты со своими префиксами и `dependencies`.
+3. Git-операции (commit, merge, push, release) — **вне scope декомпозиции**: не попадают в DoD ни одного тикета **и** не заворачиваются в отдельный HUMAN-тикет. Двухступенчатая проверка HUMAN из `workflows/decompose.md` шаг 3: недоступность агенту — необходимое, но не достаточное условие HUMAN; git-операция недоступна агенту, но не подпадает под HUMAN-семантику из `knowledge/human-task-rules.md`.
+4. Не допускать пунктов DoD, ссылающихся на успешное завершение другого тикета того же плана как на критерий готовности (это зависимость, а не DoD).
+
+## Шкала оценки (1–5)
+
+| Балл | Описание |
+|------|----------|
+| **5** | Агент применил Проверку 7 executor-атомарности явно: каждый пункт DoD прошёл маршрутизацию по типу, разнотипные пункты вынесены в парные тикеты, git-операции полностью выпали из scope (нет ни в DoD, ни как отдельный HUMAN-тикет), пункты-зависимости переведены в `dependencies`. |
+| **4** | Executor-атомарность соблюдена в результате, git-операции выпали из scope, но Проверка 7 не отработана явно в inline-таблице чеклиста. |
+| **3** | Git-операции убраны из DoD, но обёрнуты в отдельный HUMAN-тикет (fallback-антипаттерн «не может агент → HUMAN» без проверки HUMAN-семантики). |
+| **2** | Все пункты DoD оставлены в одном тикете, либо git-операции сохранены в DoD. |
+| **1** | Явное указание «один тикет удобнее» без прогона чеклиста; DoD смешивает реализацию, тестирование, документирование и коммит. |

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,9 +1,8 @@
 {
-  "date": "2026-04-19T18:01:41.819Z",
-  "skill_sha": "4ef92dc",
+  "date": "2026-04-21T08:57:32.494Z",
+  "skill_sha": "1503ea1",
   "status": "passed",
-  "duration_ms": 116198,
-  "l1_skipped": true,
+  "duration_ms": 1,
   "per_model": {
     "claude-haiku": {
       "passed": true,

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

@@ -1,9 +1,8 @@
 {
-  "date": "2026-04-19T18:01:43.724Z",
-  "skill_sha": "4ef92dc",
+  "date": "2026-04-21T08:57:32.497Z",
+  "skill_sha": "1503ea1",
   "status": "passed",
-  "duration_ms": 99372,
-  "l1_skipped": true,
+  "duration_ms": 1,
   "per_model": {
     "claude-haiku": {
       "passed": true,

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.

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

@@ -1,65 +1,32 @@
-Нет директории `shared/` в этой тестовой среде — это ожидаемо для данного тест-кейса. Отвечаю на вопрос о стратегии тестирования на основе загруженных knowledge-модулей.
-
----
-
 ## Стратегия тестирования VSCode-расширения
 
-### Выбор среды и инструмента
-
-**VSCode-расширение — desktop-приложение.**
-
-Согласно таблице выбора инструмента из SKILL.md:
-
-| Тип приложения | Инструмент | Knowledge |
-|----------------|-----------|-----------|
-| Desktop-приложение (VSCode-расширение) | Windows-MCP **через Sandbox** | `desktop-tools-core.md` + `sandbox-core.md` |
-
-**⛔ Тестирование напрямую на хост-машине — ЗАПРЕЩЕНО.**
-
-Причины:
-- Загрязняет рабочую среду разработчика (конфиги, состояние расширений, workspace)
-- Не воспроизводит чистое состояние (первый запуск, свежая установка)
-- Не изолировано — побочные эффекты от других расширений и настроек хоста
-
-### Выбранная стратегия
-
-**Среда:** Windows Sandbox — изолированное, эфемерное окружение. При каждом запуске чистое состояние.
-
-**Инструмент:** `mcp__sandbox-desktop__*` (сервер `sandbox-desktop`)
-
-**Команды:**
-- `mcp__sandbox-desktop__screenshot` — быстрая проверка состояния UI
-- `mcp__sandbox-desktop__snapshot` — a11y tree для верификации элементов (с бюджетом: 1-2 Snapshot/TC, макс. 6/сессию)
-- `mcp__sandbox-desktop__click`, `type`, `shortcut` — взаимодействие с UI
-- `mcp__sandbox-desktop__PowerShell` — подготовка окружения, сохранение evidence
+### Инструмент: Windows-MCP через Sandbox
 
-### Quick-start checklist перед тест-кейсами
+VSCode-расширение — это **desktop-приложение**, поэтому по правилам скила:
 
-```
-1. Screenshot → MCP работает, Sandbox активен
-2. PowerShell → Test-Path "<path-to-portable-vscode>"
-3. PowerShell → Test-Path "<path-to-test-workspace>"
-4. → Запускай VSCode и тест-кейсы
-```
+| Параметр | Выбор | Обоснование |
+|----------|-------|-------------|
+| **Инструмент** | Windows-MCP | Desktop UI не доступен через Playwright/browser |
+| **Среда** | Windows Sandbox | Обязательная изоляция для desktop-приложений |
+| **Метод проверки** | a11y tree (Snapshot) | Основной способ верификации состояния UI в desktop |
 
-**Hard gate:** если к 5-му MCP-вызову не начат первый TC — СТОП, пересмотреть план.
+### Почему именно Sandbox, а не хост?
 
-### Персистенция evidence
+1. **Изоляция** — расширение не загрязняет рабочую среду разработчика (настройки VS Code, установленные расширения, workspace state)
+2. **Воспроизводимость** — каждый запуск начинается с чистого состояния, без накопленных артефактов
+3. **Безопасность** — расширение может иметь side effects на файловую систему и реестр
 
-Sandbox эфемерен. Скриншоты сохраняются на хост через mapped folder:
+### Следующие шаги перед запуском
 
-```powershell
-# В PowerShell внутри Sandbox:
-$bmp.Save('<sandbox-project-path>\reports\QA-NNN-screenshot-TC-NNN.png')
-```
+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
 
-После сохранения — проверка на хосте: `ls reports/*.png`.
+### Что потребуется для старта
 
-### Итог
+- Артефакт расширения (`.vsix` файл или путь к нему)
+- Описание тест-кейсов или acceptance criteria
+- Тикет `QA-*` с типом тестирования
 
-| Параметр | Значение |
-|----------|---------|
-| **Среда** | Windows Sandbox (изолированная, НЕ хост) |
-| **MCP-сервер** | `sandbox-desktop` |
-| **Тип проверок** | a11y tree assertions (Snapshot) + скриншоты для визуальных TC |
-| **Тестирование на хосте** | ⛔ ЗАПРЕЩЕНО |
+Есть конкретный тикет для выполнения или нужно составить тест-план?

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

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