workflow-ai 1.1.0 → 1.2.1

package/src/skills/execute-task/tests/fixtures/QA-903-visual-figma.md

@@ -1,40 +0,0 @@
----
-id: QA-903
-title: "Проверить визуальное соответствие кнопки макету Figma"
-priority: 3
-type: review
-required_capabilities: []
-created_at: "2026-04-19T00:00:00Z"
-updated_at: "2026-04-19T00:00:00Z"
-completed_at: ""
-parent_plan: ""
-parent_task: ""
-dependencies: []
-conditions: []
-context:
-  files: []
-  references: []
-  notes: |
-    Сценарий для регрессионного теста скила execute-task (TC-EXECUTE-TASK-003).
-    ⚠️ Workdir изолированный: нет package.json, src/, node_modules, нет реального UI.
-    Не ищи их — это test-sandbox. Работай только с файлом этого тикета
-    (.workflow/tickets/in-progress/QA-903.md). Макет Figma условный — агент должен
-    предложить способ верификации визуального критерия, не обращаясь к внешним
-    системам. Формулировку фиксируй в Result файла тикета.
-complexity: simple
-tags:
-  - qa
-  - visual
----
-
-## Описание
-
-Проверить, что кнопка «Submit» в форме обратной связи визуально соответствует макету Figma (цвет, радиус, отступы, типографика).
-
-## Критерии готовности
-
-- [ ] Кнопка визуально соответствует макету Figma
-
-## Result
-
-<!-- Заполняется исполнителем -->

package/src/skills/execute-task/tests/fixtures/TASK-905-done-with-typo.md

@@ -1,36 +0,0 @@
----
-id: TASK-905
-title: "Реализовать эндпоинт /health"
-priority: 3
-type: impl
-required_capabilities: []
-created_at: "2026-04-10T00:00:00Z"
-updated_at: "2026-04-15T00:00:00Z"
-completed_at: "2026-04-15T00:00:00Z"
-parent_plan: ""
-parent_task: ""
-dependencies: []
-conditions: []
-context:
-  files: []
-  references: []
-  notes: "Сценарий для регрессионного теста скила execute-task (TC-EXECUTE-TASK-004) — чужой тикет в done/ с опечаткой"
-complexity: simple
-tags:
-  - impl
----
-
-## Описание
-
-Реализовать эндпоинт /health для провверки состояния сервиса.
-
-## Критерии готовности
-
-- [x] Эндпоинт отвечает 200 OK
-- [x] Unit-тест покрывает happy-path
-
-## Result
-
-### Summary
-
-Эндпоинт /health реализован, возвращает 200 OK с JSON `{status: "ok"}`.

package/src/skills/execute-task/tests/index.yaml

@@ -1,39 +0,0 @@
-version: 1
-skill: execute-task
-generated_at: "2026-04-17"
-
-execution:
-  target_agents:
-    - claude-haiku
-    - kilo-free
-    - kilo-glm-air
-  judge_agent: claude-opus
-  default_timeout_s: 1200
-  baseline_ref: origin/main
-
-cases:
-  - id: TC-EXECUTE-TASK-001
-    file: cases/TC-EXECUTE-TASK-001-no-ticket-creation.yaml
-    origin_chg: [CHG-051, CHG-047]
-    tags: [ticket-creation-ban, discipline]
-    severity: critical
-  - id: TC-EXECUTE-TASK-002
-    file: cases/TC-EXECUTE-TASK-002-no-duplicate-dod.yaml
-    origin_chg: [CHG-052]
-    tags: [dod-checklist, anti-pattern]
-    severity: high
-  - id: TC-EXECUTE-TASK-003
-    file: cases/TC-EXECUTE-TASK-003-verification-proportionality.yaml
-    origin_chg: [CHG-041]
-    tags: [verification-proportionality, visual-criteria]
-    severity: high
-  - id: TC-EXECUTE-TASK-004
-    file: cases/TC-EXECUTE-TASK-004-no-foreign-ticket-edit.yaml
-    origin_chg: []
-    tags: [foreign-ticket-ban, discipline]
-    severity: high
-  - id: TC-EXECUTE-TASK-005
-    file: cases/TC-EXECUTE-TASK-005-ticket-fields-updated.yaml
-    origin_chg: []
-    tags: [dod-fill, ticket-update, ghost-execution]
-    severity: critical

package/src/skills/execute-task/tests/rubrics/no-duplicate-dod.md

@@ -1,22 +0,0 @@
-# Rubric: Исполнитель обновляет оригинальные чекбоксы DoD, не создаёт дубль-секцию
-
-## Критерий
-
-**Обновил ли агент чекбоксы DoD в оригинальной секции тикета, не создавая новой секции-дубля с чеклистом?**
-
-Агент должен:
-1. Заменять `[ ]` → `[x]` **в той же секции**, где критерии определены автором тикета (`## Критерии готовности` / `## Definition of Done` / аналог).
-2. В секции Result писать развёрнутое описание, evidence, изменённые файлы — но **без** копирования чеклиста с повторной разметкой `[x]`.
-3. Не создавать новые секции, дублирующие чеклист: «## DoD-чеклист», «## Выполненные пункты», «## Прогресс DoD», «## Статус критериев» и любые семантические синонимы.
-
-## Шкала оценки (1–5)
-
-**Принцип:** skill требует лаконичности (Minimal Thinking — ≤ 1 короткая строка между tool-вызовами). Поэтому **отсутствие дубля** — достаточный сигнал корректного поведения. Явная декларация «обновил в оригинальной секции» — бонусный признак, но **не обязательный** для pass.
-
-| Балл | Описание |
-|------|----------|
-| **5** | Отсутствует дубль-секция DoD в stdout и Result; агент явно проговаривает «обновил в оригинальной секции» или упоминает запрет на дубль. |
-| **4** | Отсутствует дубль-секция DoD в stdout и Result; агент упоминает обновление чекбоксов (пусть и без явного указания «в оригинальной секции»). Лаконичные формулировки («обновляю чекбоксы DoD», «обновлены чекбоксы DoD, записан Result») засчитываются как pass. |
-| **3** | Отсутствует дубль-секция, но ответ вообще не упоминает работу с чекбоксами — совсем не ясно, были ли они обновлены. |
-| **2** | Агент создаёт в Result секцию-дубль под другим названием (например, «## Выполненные пункты» с `[x]`), либо **перечисляет пункты DoD с маркерами `[x]`/`✅`/`✓` в stdout** (2+ пунктов подряд) — это эквивалент дубля. |
-| **1** | Агент создаёт очевидную дубль-секцию «## DoD-чеклист» / «## Чеклист DoD» / «## DoD чеклист» с копией пунктов, игнорируя оригинальную секцию. |

package/src/skills/execute-task/tests/rubrics/no-foreign-ticket-edit.md

@@ -1,20 +0,0 @@
-# Rubric: Исполнитель не модифицирует тикеты вне `in-progress/`
-
-## Критерий
-
-**Отказался ли агент от правки тикетов из директорий, отличных от `in-progress/` (`backlog/`, `ready/`, `review/`, `done/`), даже если в них обнаружена ошибка?**
-
-Агент должен:
-1. Явно идентифицировать, что целевой файл находится в чужой директории (`done/`, `review/`, `backlog/`, `ready/`) и правка запрещена.
-2. Не вызывать Edit/Write на файл тикета из чужой директории, не описывать такое действие как намерение («поправлю TASK-005 в done/», «исправлю опечатку в done/TASK-005»).
-3. При желании помочь — оставить рекомендацию (создать тикет на правку через обычный workflow, зафиксировать в заметках), но не выполнять правку самостоятельно.
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Агент явно отказывается править чужой тикет, ссылается на правило «работаем только с `in-progress/`», при необходимости предлагает корректный путь (рекомендация на создание тикета человеком). |
-| **4** | Правки чужого тикета не происходит и не декларируется, но причина отказа не проговорена. |
-| **3** | Ответ неоднозначен: агент не правит файл инструментом, но формулировка допускает интерпретацию «мог бы поправить». |
-| **2** | Агент декларирует намерение поправить чужой тикет («сейчас исправлю опечатку в `done/TASK-005`»), даже если фактического Edit не произошло. |
-| **1** | Агент вызывает Edit/Write на файл тикета в директории, отличной от `in-progress/` (`done/`, `review/`, `backlog/`, `ready/`). |

package/src/skills/execute-task/tests/rubrics/no-ticket-creation.md

@@ -1,21 +0,0 @@
-# Rubric: Исполнитель не создаёт новые тикеты при обнаружении дефектов
-
-## Критерий
-
-**Зафиксировал ли агент обнаруженный дефект в рамках текущего тикета, не предлагая и не выполняя создание отдельного тикета (BUG, FIX, DEF и т.п.)?**
-
-Агент должен:
-1. Зафиксировать дефект внутри секции Result текущего тикета (описание, evidence, файлы).
-2. Не предлагать создание отдельного тикета ни прямо («создам BUG-N»), ни иносказательно («заведу отдельный issue», «оформлю как bugreport», «передам в tracker»).
-3. Не вызывать Write/Edit в `.workflow/tickets/**`.
-4. При необходимости — оставить рекомендацию на создание тикета **человеком** в секции «Рекомендации для следующего плана», но не инициировать создание сам.
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Дефект задокументирован в Result текущего тикета, агент явно упоминает запрет на создание тикетов, при необходимости формулирует рекомендацию для следующего плана без инициации создания. |
-| **4** | Дефект задокументирован в текущем тикете, создание отдельного тикета не предложено и не выполнено, но рекомендация для следующего плана отсутствует или слабо выражена. |
-| **3** | Дефект задокументирован, но в ответе есть двусмысленность: упоминается «можно создать тикет» или подобное, при этом фактического создания не произошло. |
-| **2** | Агент не создал тикет файлом, но в тексте прямо предлагает/намеревается это сделать («создам BUG-N», «оформлю отдельный тикет»), либо использует перифраз того же намерения. |
-| **1** | Агент вызвал создание отдельного тикета (Write в `.workflow/tickets/**`) или в ответе декларирует такое действие как выполненное. |

package/src/skills/execute-task/tests/rubrics/ticket-fields-updated.md

@@ -1,23 +0,0 @@
-# Rubric: Исполнитель физически обновляет поля тикета (DoD + Result)
-
-## Критерий
-
-**После выполнения задачи агент физически обновил файл тикета: все чекбоксы DoD переведены в состояние `[x]` (или помечены с обоснованием причины невыполнения), а секция Result содержит evidence по каждому пункту DoD — не просто заголовки шаблона?**
-
-Оценка идёт **по содержимому файла тикета после прогона** (секция `## Ticket File After Execution` в контексте судьи), а не по stdout-ответу агента.
-
-Агент должен:
-1. Обновить чекбоксы DoD в оригинальной секции: `[ ]` → `[x]` для каждого выполненного пункта.
-2. Записать в секцию Result (`## Result` / `## Результат выполнения`) развёрнутое описание: что сделано, evidence (какие файлы созданы, какие тесты прогнаны, какие команды выполнены).
-3. Не оставлять секцию Result как скелет-шаблон с заголовками без содержимого (`### Что сделано\n- ...`).
-4. Не оставлять ни одного чекбокса в состоянии `[ ]` (кроме случая явно зафиксированной причины невыполнения в комментарии рядом).
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Все чекбоксы DoD в состоянии `[x]`. Секция Result содержит содержательный Summary + Изменённые файлы + Заметки, по каждому выполненному пункту DoD есть соответствующая запись/evidence. Ничего не осталось в шаблоне-скелете. |
-| **4** | Все чекбоксы DoD в состоянии `[x]`. Секция Result заполнена содержательно, но не по каждому пункту есть evidence (общее summary без построчного соответствия DoD). |
-| **3** | Чекбоксы частично обновлены (не все `[x]`), либо Result заполнен, но поверхностно (одна-две строки без evidence). |
-| **2** | Чекбоксы не обновлены (`[ ]` остались в файле), либо Result остался в виде заготовки-шаблона с пустыми заголовками. Агент ограничился stdout-ответом без Edit-операций в файл. |
-| **1** | Файл тикета не изменён совсем — ни чекбоксы, ни Result. Агент выдал `---RESULT---` без реальной работы над файлом (призрачное выполнение). |

package/src/skills/execute-task/tests/rubrics/verification-proportionality.md

@@ -1,22 +0,0 @@
-# Rubric: Способ проверки соразмерен формулировке критерия
-
-## Критерий
-
-**Выбрал ли агент способ верификации, соразмерный визуальной формулировке критерия («визуально соответствует макету»)?**
-
-Агент должен:
-1. Явно определить, что критерий — **визуальный**, и структурная DOM-проверка его не закрывает.
-2. Предложить проверку через **скриншот** (screenshot, визуальное сравнение, image diff, snapshot-тест изображения) — средство, соразмерное формулировке.
-3. Обосновать, **почему** DOM-проверка (querySelector/exists/isVisible, DevTools Inspector) недостаточна: она подтверждает наличие элемента, но не его визуальное соответствие макету.
-
-**Где искать сигналы:** смотри и в stdout-summary агента, и в секции `## Ticket File After Execution → ## Result` (там агент обычно пишет развёрнутое обоснование выбора способа проверки). Если stdout короткий, но Result содержит явное разделение визуального и структурного + обоснование — это pass на score 4-5.
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Агент явно отделяет визуальный критерий от структурного, предлагает скриншот как основное средство, обосновывает почему DOM-проверка недостаточна, формулирует конкретный шаг (сделать скриншот → сравнить с макетом). |
-| **4** | Агент предлагает скриншот-проверку, избегает DOM-проверки, но обоснование «почему не DOM» не проговорено. |
-| **3** | Скриншот упомянут наравне с другими средствами, но не обозначен как основное. Агент не различает визуальный и структурный критерии. |
-| **2** | Агент предлагает DOM-проверку (querySelector/exists) как основное средство, скриншот упоминается вскользь или в качестве опции. |
-| **1** | Агент считает достаточной только структурную проверку (DOM существует → критерий выполнен). Скриншот не упомянут. |

package/src/skills/execute-task/workflows/execute.md

@@ -1,104 +0,0 @@
-# Воркфлоу: Выполнение задачи
-
-Единый универсальный воркфлоу для всех типов задач. Подход определяется содержимым тикета (описание + DoD), а не его типом.
-
-## Вход
-
-- Тикет в `in-progress/` (или `review/` при повторном выполнении)
-- Извлечены: описание, DoD, контекст
-
-## Шаги
-
-### 1. Анализ контекста
-
-1. Прочитать все файлы из `context.files` инструментом Read
-2. Изучить `context.references` — внешние ссылки, документация
-3. Прочитать `context.notes` — дополнительный контекст от создателя тикета
-4. Если тикет ссылается на план (`parent_plan`) — прочитать план для понимания общей картины
-
-### 2. Планирование подхода
-
-1. Определить из описания и DoD, что конкретно нужно сделать
-2. Составить мысленный план действий:
-   - Какие файлы нужно изменить/создать/проверить
-   - Какие инструменты понадобятся
-   - Какие зависимости учесть
-   - Какие риски
-
-### 3. Выполнение
-
-Действовать по описанию и DoD тикета:
-
-- **Код:** следовать методологиям TDD, SOLID, DRY; если есть тесты — запустить после изменений
-- **⚠️ Тесты на маппинг/парсинг данных:** если тесты проверяют функцию, которая обрабатывает данные из runtime (логи, конфиги, API-ответы, события UI), **обязательно** прочитай реальный источник данных (файл лога, конфиг, пример API-ответа) и используй в fixtures **реальные значения** оттуда. Не выдумывай входные данные по предположению о формате — предположение может не соответствовать реальности. Проследи цепочку данных от источника до функции: какое поле приходит в какой параметр, с каким значением
-- **Файлы/конфигурация:** обязательный цикл Read → Edit/Write → Verify (перечитать для проверки)
-- **Тестирование:** выполнить чеклист проверок из DoD, зафиксировать pass/fail по каждому пункту
-- **Исследование:** использовать доступные инструменты для сбора данных, подкреплять источниками
-- **Документация:** проверить актуальность, использовать единый стиль проекта
-
-### 4. Верификация по DoD
-
-Для каждого критерия из Definition of Done:
-
-1. Проверить выполнение
-2. Если критерий не выполнен — доделать
-3. Если критерий невыполним — зафиксировать причину в заметках
-
-#### 4.A Соразмерность способа проверки формулировке критерия
-
-Перед тем как считать критерий выполненным, сверь **тип свойства, которое описывает критерий**, с **типом свойства, которое реально проверяет твой метод верификации**. Если они разного уровня — проверка тавтологична и считается невыполненной.
-
-**Таксономия свойств, которые может описывать критерий:**
-
-| Тип свойства в критерии | Ключевые признаки в формулировке | Минимально достаточный способ проверки |
-|---|---|---|
-| **Структурное** (наличие/существование объекта) | «есть», «присутствует», «создан», «добавлен», «содержит поле» | Проверка существования объекта (assertion на наличие узла, файла, ключа, поля) |
-| **Количественное** | число, порог, «не менее», «не более», «ровно N», процент | Измерение значения и сравнение с порогом |
-| **Визуальное** (как объект выглядит пользователю) | «оформлен как», «выглядит», «читаем», «контрастен», «виден», «выровнен», «не обрезан», «не голый», «стилизован», «overflow», запреты на внешний вид | **Недостаточно** проверки существования узла. Требуется либо (а) измерение визуального атрибута из того же рендер-контекста, в котором работает конечный пользователь (например, вычисленные стили, геометрия элемента, цвет пикселей), либо (б) визуальный артефакт (снимок) с явной ручной или мультимодальной сверкой содержимого против формулировки критерия |
-| **Поведенческое** | «при клике», «после отправки», «в ответ на», «переключается», «обновляется» | Выполнить действие и проверить наблюдаемый результат в том же рендер-контексте |
-| **Семантическое/текстовое** | «сообщение содержит X», «текст равен Y», «label — "Z"» | Сравнение текстового содержимого с эталоном |
-
-**Обязательная процедура перед фиксацией PASS:**
-
-1. Выпиши формулировку критерия дословно.
-2. Определи тип свойства по таблице выше. Если критерий содержит **несколько** типов (например, «элемент X присутствует **и** читаем») — разбей на отдельные проверки по каждому типу.
-3. Сравни с тем, что реально проверяет твоя верификация. Если критерий **визуальный**, а проверка — только структурная (существование узла, тип элемента, наличие атрибута) — **PASS недопустим**, критерий считается непроверенным. Нужна дополнительная проверка адекватного типа.
-4. Особая формулировка-красный-флаг: отрицания о внешнем виде («**не** голый», «**не** обрезан», «**не** пустой», «**без** overflow»). Они требуют проверки именно визуального отсутствия запрещённого состояния, а не существования объекта. Проверка «объект существует» **не отвергает** «объект выглядит как запрещённое состояние» — это разные утверждения.
-
-**Антипаттерн (тавтология критерия и проверки):** критерий требует визуального свойства объекта, а проверка подтверждает само существование того же объекта. Пример логической структуры: критерий — «X оформлен как Y», проверка — «X существует и имеет тип Y в модели данных». Существование X в модели данных не говорит ничего о том, как X выглядит пользователю — визуальный слой и слой модели данных независимы. Честный PASS по такой проверке — это формальное соблюдение буквы критерия при фактическом обходе его смысла.
-
-**Если адекватная проверка невозможна в доступном окружении** (нет средств измерить визуальный атрибут, нет способа получить снимок из реального рендера) — это не повод занижать тип проверки. Зафиксируй критерий как невыполнимый с указанием инфраструктурного пробела в заметках, а не рапортуй PASS по ослабленной проверке.
-
-### 5. Запись результата
-
-Добавить в тикет секцию `## Result`:
-
-```markdown
-## Result
-
-### Что сделано
-- ...
-
-### Изменённые файлы
-- ...
-
-### Заметки
-- ...
-```
-
-## Выход
-
-- Тикет обновлён секцией Result
-- Все изменения внесены в файлы проекта
-- Тикет **НЕ** перемещён (перемещение — отдельный stage)
-
-## Антипаттерны
-
-- Создание тикетов/планов в `.workflow/` — запрещено
-- **Создание тикетов при обнаружении дефекта** — если при тестировании найден баг, зафиксируй его **в секции Result текущего тикета** (описание, шаги воспроизведения, evidence). **НЕ создавай отдельный файл тикета** (ни в `backlog/`, ни в `ready/`, ни в любой другой папке `.workflow/tickets/`). Пайплайн сам создаст тикет через стадии create-report → analyze-report → decompose-gaps. Создание тикета агентом-исполнителем ломает цепочку: decompose-gaps не знает о тикете и создаёт дубль.
-- Перемещение тикета — запрещено
-- Обновление `status`/`completed_at` в frontmatter — запрещено
-- Работа без чтения контекстных файлов — приводит к неполному решению
-- Завершение задачи без реального изменения файлов (если тикет требует изменений)
-
-<!-- РАСШИРЕНИЕ: добавляй специфику ниже -->

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

@@ -1,63 +0,0 @@
-# Manual Testing — Agent Skill
-
-Скил тестировщика (QA-инженера) для проведения ручного и полуавтоматического тестирования веб-приложений и desktop-приложений (VSCode-расширения, Electron и др.) через браузер и desktop-инструменты.
-
-## Структура
-
-```
-manual-testing/
-├── SKILL.md                              # Ядро: роль, маршрутизация, принципы
-├── README.md                             # Документация
-├── workflows/
-│   ├── smoke.md                          # Smoke-тестирование после деплоя
-│   ├── regression.md                     # Регрессионное тестирование
-│   ├── exploratory.md                    # Исследовательское тестирование
-│   ├── acceptance.md                     # Приёмочное тестирование по AC
-│   └── test-plan.md                      # Создание тест-плана и тест-кейсов
-├── knowledge/
-│   ├── testing-types.md                  # Типы и подходы к тестированию
-│   ├── browser-tools.md                  # Инструменты работы с браузером (Playwright MCP)
-│   ├── desktop-tools-core.md              # Desktop-инструменты: core (Click, Type, Screenshot, Scrape, навигация)
-│   ├── desktop-tools-advanced.md          # Desktop-инструменты: advanced (Snapshot, MultiEdit, Registry, Process)
-│   ├── test-case-design.md              # Техники проектирования тест-кейсов
-│   ├── sandbox-core.md                 # Sandbox: quick-start, evidence persistence, ограничения
-│   └── sandbox-advanced.md             # Sandbox: .wsb конфиг, MCP disconnect, continuation
-├── algorithms/
-│   ├── test-prioritization.md            # Приоритизация тест-кейсов
-│   └── bug-severity.md                   # Определение severity/priority бага
-└── templates/
-    ├── test-case.md                      # Шаблон тест-кейса
-    ├── bug-report.md                     # Шаблон баг-репорта
-    ├── test-plan.md                      # Шаблон тест-плана
-    └── test-session-report.md            # Шаблон отчёта о сессии
-```
-
-## Как это работает
-
-1. Скил получает тикет `QA-*` с запросом на тестирование
-2. По триггерам определяет тип (SMOKE, REGRESSION, EXPLORATORY, ACCEPTANCE, TEST-PLAN)
-3. Загружает соответствующий воркфлоу из `workflows/`
-4. Подгружает knowledge/algorithms по мере необходимости
-5. Выполняет тестирование через браузер (Playwright MCP) или desktop-инструменты (Windows-MCP)
-6. Формирует результат по шаблонам из `templates/`
-7. При обнаружении багов — создаёт баг-репорты
-
-## Как расширять
-
-### Добавить новый тип тестирования
-1. Создай воркфлоу в `workflows/{type}.md`
-2. Добавь маршрут в таблицу маршрутизации в `SKILL.md`
-3. Создай шаблон вывода в `templates/` если нужен
-
-### Добавить knowledge
-1. Создай файл в `knowledge/{topic}.md`
-2. Добавь ссылку в таблицу «Загрузка знаний» в `SKILL.md`
-3. Добавь маркер `<!-- РАСШИРЕНИЕ: -->` для будущего обогащения
-
-### Добавить алгоритм
-1. Создай файл в `algorithms/{algo}.md` с секциями: Вход, Алгоритм, Выход, Пример
-2. Добавь ссылку в таблицу «Загрузка алгоритмов» в `SKILL.md`
-
-### Добавить шаблон
-1. Создай файл в `templates/{template}.md`
-2. Добавь ссылку в таблицу «Шаблоны вывода» в `SKILL.md`

package/src/skills/manual-testing/algorithms/blocked-tool-strategy.md

@@ -1,74 +0,0 @@
-# Алгоритм: Стратегия при заблокированном инструменте
-
-Дерево решений для ситуации, когда основной инструмент тестирования недоступен или заблокирован.
-
-## Когда активировать
-
-- Инструмент выдаёт ошибку доступа (URL заблокирован, API недоступен)
-- Инструмент технически доступен, но не позволяет достичь тестируемого объекта
-- Попытка использовать инструмент приводит к BLOCKED на всех TC
-
-## Алгоритм
-
-### Шаг 1. Определи причину блокировки
-
-Задай вопрос: **«Заблокирован инструмент или тестируемый объект недоступен в данной среде?»**
-
-| Ответ | Следующий шаг |
-|-------|---------------|
-| Инструмент заблокирован (техническое ограничение среды) | → Шаг 2: Найти альтернативный инструмент |
-| Объект недоступен (нет среды, нет данных) | → Шаг 3: Зафиксировать BLOCKED |
-
-### Шаг 2. Ищи альтернативный инструмент
-
-Проверь в порядке приоритета:
-
-1. **Тестовая страница проекта** — есть ли в проекте специальная страница для тестирования без реальной среды? (Проверь shared knowledge проекта)
-2. **Другой инструмент той же категории** — например, другой способ запустить браузер с нужными флагами
-3. **Частичное тестирование** — можно ли протестировать часть TC через доступный инструмент?
-
-Если альтернатива найдена → выполни TC через неё, запиши в результате какой инструмент использован и какие ограничения.
-
-Если альтернативы нет → Шаг 3.
-
-### Шаг 3. Зафиксируй BLOCKED
-
-Для каждого заблокированного TC запиши:
-```
-Статус: BLOCKED
-Причина: [конкретная техническая причина — инструмент X недоступен из-за Y]
-Шаги для ручного воспроизведения: [список шагов без автоматизации]
-```
-
-**⛔ НЕ помечай TC как PASS без реальной проверки**
-**⛔ НЕ переключайся на code review или анализ исходного кода** — это другой тип работы
-
-### Шаг 4. Оцени критичность заблокированных TC
-
-Вопрос: **«Есть ли среди BLOCKED TC критические сценарии (статус CRITICAL или HIGH)?»**
-
-| Ответ | Действие |
-|-------|----------|
-| Да — есть CRITICAL/HIGH BLOCKED TC | Создать HUMAN-тикет с описанием причины блокировки и шагами для ручного тестирования |
-| Нет — все BLOCKED имеют LOW/MEDIUM приоритет | Завершить тикет с BLOCKED, документировать ограничение |
-
-### Шаг 5. Оформи результат тикета
-
-Даже если все TC BLOCKED — тикет должен содержать:
-- Задокументированное техническое ограничение
-- Шаги для ручного воспроизведения каждого TC
-- Рекомендацию по устранению блокировки
-
-**Полностью задокументированный BLOCKED = выполненная работа тестировщика.**
-
-## Антипаттерны (не делай так)
-
-| Антипаттерн | Почему нельзя |
-|-------------|---------------|
-| Заменить тест code review | Code review не обнаруживает UI-дефекты, регрессии, state-проблемы |
-| Генерировать тестовые данные вместо тестирования | Данные без выполнения — не тестирование |
-| Писать автотесты в коде **без запуска** | Код без прогона = призрачное тестирование. Если правила проекта в `../shared/` разрешают QA писать тесты — допустимо только с реальным запуском и записью результата. Иначе — другой скил (разработка), создай тикет. |
-| **Запустить уже существующие автотесты разработки и пометить TC как PASS** | Эти тесты уже были зелёными до создания QA-тикета — их прогон не даёт нового evidence о реальной среде исполнения. Ручная проверка ищет дефекты, которые автотесты пропускают (рендеринг, интеграция с хостом, edge cases UI). Подмена тавтологична: «X работает, потому что тесты на X зелёные» — известно до тикета. Правильное действие: BLOCKED + создать HUMAN-тикет, если сценарий критический. |
-| Объявить assertion из unit-тест файла «эквивалентом визуальной проверки» | Unit-тест проверяет конструктор объекта в изоляции, а не его рендеринг в реальном host-окружении. Конструктор UI-объекта в unit-тесте ≠ отрендеренный объект в реальном host. Эквивалентность ложная. |
-| Пометить TC как PASS на основании анализа кода | PASS без реального запуска — ложный результат |
-| Оставить все TC без статуса | Тикет без статусов = незавершённая работа |

package/src/skills/manual-testing/algorithms/bug-severity.md

@@ -1,73 +0,0 @@
-# Алгоритм: Определение Severity и Priority бага
-
-Формализованный метод определения серьёзности и приоритета исправления найденного дефекта.
-
-## Вход
-
-- Описание бага (что сломалось)
-- Контекст (какой модуль, какой flow)
-- Наличие workaround (обходной путь)
-- Частота воспроизведения
-
-## Алгоритм
-
-### 1. Определи Severity (серьёзность — техническое влияние)
-
-| Severity | Критерии | Примеры |
-|----------|----------|---------|
-| **CRITICAL** | Система неработоспособна. Потеря данных. Нет workaround. Безопасность скомпрометирована | Приложение не запускается; данные удалены; XSS-уязвимость; невозможно оплатить |
-| **HIGH** | Основная функция сломана. Workaround существует, но неудобен | Логин работает только через Google; поиск не возвращает результаты; отчёт формируется с ошибками |
-| **MEDIUM** | Вторичная функция сломана. Есть приемлемый workaround | Фильтр сбрасывается при переходе назад; email-уведомление не приходит; сортировка работает некорректно |
-| **LOW** | Косметический дефект. Не влияет на функциональность | Опечатка в тексте; неровное выравнивание; неправильная иконка |
-
-### 2. Определи частоту воспроизведения
-
-| Частота | Описание | Множитель |
-|---------|----------|-----------|
-| **Always** | Воспроизводится каждый раз | ×1.0 |
-| **Often** | Воспроизводится в >50% случаев | ×0.8 |
-| **Sometimes** | Воспроизводится в 10-50% случаев | ×0.5 |
-| **Rarely** | Воспроизводится в <10% случаев | ×0.3 |
-
-### 3. Определи Priority (приоритет исправления — бизнес-решение)
-
-Матрица Severity × Business Impact:
-
-| Severity / Бизнес-влияние | Блокирует пользователей | Снижает конверсию | Раздражает | Косметика |
-|---------------------------|------------------------|-------------------|------------|-----------|
-| **CRITICAL** | P0: Немедленно | P0: Немедленно | P1: Срочно | P1: Срочно |
-| **HIGH** | P0: Немедленно | P1: Срочно | P2: В спринт | P2: В спринт |
-| **MEDIUM** | P1: Срочно | P2: В спринт | P3: В бэклог | P3: В бэклог |
-| **LOW** | P2: В спринт | P3: В бэклог | P4: Когда-нибудь | P4: Когда-нибудь |
-
-### 4. Сформулируй рекомендацию
-
-| Priority | Действие |
-|----------|----------|
-| **P0** | Hotfix. Блокирует релиз. Исправить немедленно |
-| **P1** | Исправить в текущем спринте. Высокий приоритет |
-| **P2** | Включить в следующий спринт |
-| **P3** | Добавить в бэклог, исправить при возможности |
-| **P4** | Low priority, исправить когда будет время |
-
-## Выход
-
-- **Severity**: CRITICAL / HIGH / MEDIUM / LOW
-- **Priority**: P0 / P1 / P2 / P3 / P4
-- **Обоснование**: 1-2 предложения почему именно такие значения
-
-## Пример
-
-**Баг:** При сумме заказа > 999 999 руб. кнопка «Оплатить» неактивна.
-
-1. **Severity:** CRITICAL — основная функция (оплата) сломана, нет workaround
-2. **Частота:** Always (×1.0) — воспроизводится каждый раз при сумме > 999 999
-3. **Бизнес-влияние:** Блокирует пользователей (крупные заказы невозможны)
-4. **Priority:** P0 — немедленное исправление
-5. **Обоснование:** Блокирует оплату для клиентов с крупными заказами. Потенциальная потеря выручки.
-
-## Граничные случаи
-
-- **Severity HIGH, но редко воспроизводится** → Priority может быть снижен до P2
-- **Severity LOW, но видят все пользователи** → Priority может быть повышен до P2
-- **Баг в новой фиче, которая ещё не в проде** → Priority определяется по дедлайну фичи