workflow-ai 1.0.68 → 1.2.1

package/src/skills/review-result/tests/index.yaml

@@ -1,30 +0,0 @@
-version: 1
-skill: review-result
-generated_at: "2026-04-17"
-
-execution:
-  target_agents:
-    - claude-sonnet
-    - kilo-glm
-    - kilo-minimax
-    - kilo-deepseek
-  judge_agent: claude-opus
-  default_timeout_s: 1200
-  baseline_ref: origin/main
-
-cases:
-  - id: TC-REVIEW-RESULT-001
-    file: cases/TC-REVIEW-RESULT-001-visual-tc-trigger.yaml
-    origin_chg: [CHG-043, CHG-044]
-    tags: [visual-testing, review-trigger]
-    severity: high
-  - id: TC-REVIEW-RESULT-002
-    file: cases/TC-REVIEW-RESULT-002-path-line-suffix.yaml
-    origin_chg: [CHG-055]
-    tags: [path-parsing, verify-artifacts]
-    severity: medium
-  - id: TC-REVIEW-RESULT-003
-    file: cases/TC-REVIEW-RESULT-003-test-isolation.yaml
-    origin_chg: [CHG-test-hygiene-2026-04-21]
-    tags: [test-hygiene, isolation, knowledge-test-hygiene]
-    severity: high

package/src/skills/review-result/tests/rubrics/path-line-suffix.md

@@ -1,19 +0,0 @@
-## Критерий
-
-**Корректно ли ревьюер обработал путь к файлу, указанный в отраслевой нотации `path:line` или `path:line-range` (например, `src/x.ts:204-211`), не пометив такой артефакт как отсутствующий?**
-
-Ревьюер должен:
-1. Распознать суффикс `:N` или `:N-M` как указание на строки файла, а не как часть имени файла.
-2. При верификации артефакта обращаться к реальному пути без суффикса (или явно учитывать суффикс при проверке).
-3. Не выдавать ошибку вида «файл не найден» / `missing_files` исключительно из-за наличия `:line`-суффикса.
-4. В `---RESULT---` отразить корректную обработку: `passed` (если остальные пункты в порядке) или `failed` по содержательной причине, не связанной с парсингом пути.
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Ревьюер явно распознал `:line`-нотацию, корректно обработал артефакт, вердикт сформулирован без упоминания «файл не найден» из-за суффикса. |
-| **4** | Ревьюер обработал путь корректно, не выдал ложного `missing_files`, но не комментировал явно поддержку нотации. |
-| **3** | Ревьюер обработал путь, но в выводе есть двусмысленность относительно интерпретации суффикса (например, упомянул его как «возможно нестандартный»). |
-| **2** | Ревьюер выдал warning о пути, частично заблокировал вердикт из-за нотации, но не пометил файл как полностью отсутствующий. |
-| **1** | Ревьюер пометил `src/background/index.ts:204-211` как `missing_files` / «файл не найден» исключительно из-за `:line`-суффикса. |

package/src/skills/review-result/tests/rubrics/test-isolation.md

@@ -1,20 +0,0 @@
-## Критерий
-
-**Поймал ли ревьюер нарушение изоляции теста, когда DoD явно требует изоляции, а код теста в секции «Изменённые файлы» физически пишет в рабочий репозиторий проекта, а не в стандартный системный tmp-корень?**
-
-Ожидаемое поведение:
-1. Ревьюер прочитал код теста, на который ссылается секция «Изменённые файлы» тикета.
-2. Обнаружил, что корень артефактов (testProjectRoot или аналог) строится от директории исходника или CWD через подъём к корню репозитория, а не от стандартного системного tmp-корня.
-3. Обнаружил, что cleanup удаляет конкретный файл, а не весь корень; cleanup вызывается в теле test-функции, а не в teardown/after-hook.
-4. Вернул `---RESULT--- status: failed` с issue, в котором дословно процитирован проблемный фрагмент теста (путь к корню, функция cleanup) и указано конкретное нарушение, а не обобщённое «нарушена изоляция».
-5. Не смягчил finding на основании того, что тест формально «проходит» (проверка изоляции ортогональна результату прогона).
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Ревьюер вернул `failed`; в issue дословно цитируются проблемные строки теста (путь до корня проекта, cleanup конкретного файла или cleanup вне teardown); явно отмечено, что проверка изоляции ортогональна прогону; finding не смягчён. |
-| **4** | Ревьюер вернул `failed` с issue об изоляции, проблемные строки названы, но без дословной цитаты — либо пересказом, либо обобщённой формулировкой. |
-| **3** | Ревьюер вернул `failed`, но issue формулирован слишком обобщённо («тест не изолирован»), без указания конкретного места в коде. |
-| **2** | Ревьюер отметил проблему изоляции как замечание, но вернул `passed` — смягчил finding на основании формального прохождения теста. |
-| **1** | Ревьюер вернул `passed` без упоминания изоляции, либо не прочитал код теста вообще, либо пометил тест как корректный. |

package/src/skills/review-result/tests/rubrics/visual-tc-trigger.md

@@ -1,19 +0,0 @@
-## Критерий
-
-**Запустил ли ревьюер визуальную проверку (потребовал скриншот / визуальное подтверждение / отметил отсутствие визуального evidence) для DoD-пункта с визуальным критерием, скриншоты к которому не приложены исполнителем?**
-
-Ревьюер должен:
-1. Распознать визуальный характер критерия DoD (формулировки уровня «визуально соответствует», «соответствует макету», «совпадает с дизайном»).
-2. Зафиксировать отсутствие визуального evidence (скриншот, ссылка на сравнение, артефакт визуального теста) у исполнителя.
-3. Вынести вердикт `failed` с указанием недостающего evidence **или** явно потребовать визуальное подтверждение перед `passed`.
-4. Не принимать утверждение исполнителя «проверено локально» как достаточное evidence для визуального DoD.
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Ревьюер распознал визуальный критерий, явно зафиксировал отсутствие скриншотов/визуального evidence, вынес `failed` со ссылкой на конкретный пункт DoD. |
-| **4** | Ревьюер распознал визуальный критерий и потребовал визуальное подтверждение, но вердикт сформулирован менее чётко (например, упомянуто общим списком без указания пункта). |
-| **3** | Ревьюер упомянул необходимость скриншота, но вердикт `passed` или статус неоднозначен — поведение частично корректное. |
-| **2** | Ревьюер не распознал визуальный характер критерия, но в выводе есть косвенный сигнал о неполноте evidence. |
-| **1** | Ревьюер вынес `passed` для визуального DoD без скриншотов и без требования визуального evidence — пропустил визуальный gate. |

package/src/skills/review-result/workflows/review.md

@@ -1,209 +0,0 @@
-# Воркфлоу: Review — Проверка результата выполнения задачи
-
-Основной воркфлоу скила. Применяется для всех типов тикетов.
-
-## Алгоритм выполнения
-
-### 0. Быстрый выход (short-circuit)
-
-1. Прочитай тикет из `review/{TICKET-ID}.md`
-2. Найди секцию `## Ревью`
-3. Если секция существует — посмотри **последнюю запись** таблицы:
-   - `passed` или `⏭ skipped` → немедленно верни `status: passed`, **остановись**
-   - `failed` → перейди к шагу 1 (механическая предпроверка)
-4. Если секции нет → перейди к шагу 1
-
-### 1. Механическая предпроверка (verify-artifacts)
-
-**Автоматическая проверка (основной путь):**
-
-Запусти скрипт верификации артефактов:
-
-```bash
-node .workflow/src/skills/review-result/scripts/verify-artifacts.js <ticket-id|ticket-path>
-```
-
-Где аргумент — либо ticket_id (`IMPL-006`), либо путь к файлу тикета (`.workflow/tickets/review/IMPL-006.md`).
-
-Прочитай key-value пары из блока `---RESULT---`. Скрипт возвращает:
-- `status` — `passed` (все проверки ok) или `failed` (есть критические проблемы)
-- `dod_completion_pct` — процент выполнения DoD (0–100)
-- `dod_total` / `dod_completed` — абсолютные счётчики DoD-чекбоксов
-- `result_filled` — заполнена ли секция Summary в Result (`true` / `false`)
-- `missing_files` — comma-separated список файлов из «Изменённые файлы», которых физически нет
-- `fail_reasons` — (только при failed) перечисление критериев, которые привели к отказу
-
-**Быстрый отказ по результатам скрипта:**
-
-| Условие | Действие |
-|---------|----------|
-| `status: failed` | → итоговый вердикт `failed`, не запускать содержательное AI-ревью |
-| `result_filled == false` | → `failed`: секция Result пуста |
-| `dod_completion_pct == 0` | → `failed`: ни один пункт DoD не отмечен. **Это жёсткое правило:** запрещено интерпретировать таблицу `PASS`/`FAIL` в тексте Result как замену `- [x]` в DoD. Source of truth — только чекбоксы `- [x]`. Если исполнитель не проставил их — это его ошибка, повод для `failed`, а не для AI-рационализации. |
-| `missing_files` не пуст | Зафиксировать как issue, продолжить AI-ревью |
-
-Если скрипт показал критические проблемы — переходи сразу к шагу 5 (формирование вердикта `failed`) и запиши в issues поле `fail_reasons` из вывода скрипта.
-
-**Ручная проверка (fallback):**
-
-Если скрипт недоступен или вернул ошибку — переходи к шагу 2 без предпроверки. Шаг 4.6 (верификация реальных изменений) покроет эти проверки вручную.
-
-### 2. Парсинг тикета
-
-Извлеки из тикета:
-
-| Поле | Где искать | Обязательно |
-|------|-----------|-------------|
-| **DoD** | Секция «Критерии готовности (Definition of Done)» — чеклист `- [ ]` / `- [x]` | Да |
-| **Детали задачи** | Секция «Детали задачи» — требования к реализации | Да |
-| **Результат** | Секция «Результат выполнения» — что сделано, изменённые файлы | Да |
-| **Тип задачи** | Frontmatter `type` | Да |
-| **executor_type** | Frontmatter `executor_type` (если есть) | Нет |
-
-### 3. Проверка каждого пункта DoD
-
-Для каждого критерия из DoD определи тип проверки и выполни:
-
-| Тип проверки | Описание | Как проверить |
-|--------------|----------|---------------|
-| `file_exists` | Файл существует по указанному пути | Read/Glob по пути. **Если не найден → fallback:** `Bash("ls -la {путь}")` (Glob не видит untracked dirs) |
-| `compilation` | Код компилируется / линтер проходит | Запуск lint/build |
-| `tests` | Тесты проходят | Запуск тестов |
-| `text` | Текстовый критерий выполнен | Поиск контента в файле |
-| `structure` | Структура соответствует шаблону | Сравнение с эталоном |
-
-> **Загрузи** `knowledge/dod-patterns.md` для определения типичных паттернов DoD по типу тикета.
-
-### 4. Сверка Result с требованиями
-
-Сравни секцию «Результат выполнения» с «Деталями задачи»:
-- Все ли требования учтены
-- Соответствует ли реализация описанию
-- Нет ли расхождений между заявленным и реальным
-
-### 4.5. Проверка с позиции целевой аудитории
-
-> **Применяется** когда результат — документ/ТЗ/спецификация для конкретного исполнителя.
-
-Если в DoD есть критерий типа *«файл самодостаточен»* или *«исполнитель не должен смотреть другие документы»*:
-
-| Проверка | Как проверить | Провал → |
-|----------|---------------|----------|
-| Credentials указаны или описано где взять | Искать плейсхолдеры `XXX`, `TODO`, `заменить на реальный` | failed |
-| Все системные зависимости перечислены | Для каждого API/библиотеки — проверить наличие в dependencies | failed |
-| Параметры вычислимы | Для условных параметров — описан способ получения значения | failed |
-| Environment-переключение описано | Если есть debug/dev/prod — описан механизм переключения | failed |
-
-**Правило:** прочитай документ глазами целевого исполнителя. Если он не может начать работу без дополнительных вопросов — `failed`.
-
-### 4.6. Верификация реальных изменений
-
-> **Применяется только** для тикетов с `executor_type != human`.
-
-> **Загрузи** `algorithms/verification.md` для формализованного алгоритма верификации.
-
-| Проверка | Как проверить | Провал → |
-|----------|---------------|----------|
-| Файлы-артефакты существуют | Проверить все файлы из «Изменённые файлы» через Read/Glob. **Если не найден → fallback:** `Bash("ls -la {путь}")` (Glob не видит файлы в новых untracked директориях). Только если оба способа не нашли → failed | failed |
-| Файлы содержат реальный контент | Открыть файл, убедиться что не шаблон/placeholder | failed |
-| Секция Result не пуста | Summary заполнен содержательно (не заглушка) | failed |
-| DoD соответствует реальности | Для каждого `[x]` — открыть артефакт и подтвердить | failed |
-
-### 4.7. Визуальная верификация скриншотов
-
-> **Применяется** при выполнении **любого** из двух условий:
-> - **(A)** В тикете (DoD, результаты TC, секция evidence, «Изменённые файлы») есть ссылки на `.png` файлы.
-> - **(B)** Тикет содержит TC или DoD с **визуальными критериями** — формулировки, описывающие как элемент выглядит пользователю: «оформлен как», «выглядит», «читаем», «контрастен», «виден», «выровнен», «не обрезан», «стилизован», «нет overflow», «визуально выделен», а также любые отрицания о внешнем виде («не голый», «не пустой», «без X»). Если хотя бы один TC содержит такую формулировку — шаг 4.7 обязателен.
-
-**Шаг 4.7.0 (при триггере B, без явных PNG-ссылок в тикете):**
-
-Прежде чем проверять скриншоты, определи, **существуют ли они вообще**. Исполнитель мог сохранить скрины, но не сослаться на них в тикете; либо мог не сделать скрины вовсе.
-
-1. Найди скриншоты: `Glob` по типичным местам хранения артефактов проекта (директория отчётов, директории снимков тестов) на `.png` файлы, фильтруя по ID тикета или имени теста.
-2. Если скриншоты найдены — перейди к основной проверке (шаги 1-3 ниже) для каждого найденного файла, сопоставимого с визуальным TC.
-3. Если скриншоты **не найдены**, а визуальные TC есть — это **finding**: evidence визуальных TC является только текстовым (DOM-assertions), без визуального артефакта. Зафиксируй как issue: «TC N.N содержит визуальный критерий "{формулировка}", но evidence — только DOM-assertion без скриншота. Визуальное свойство не может быть подтверждено программной проверкой существования DOM-узла».
-
-**Основная проверка (для каждого скриншота):**
-
-| Шаг | Действие | Провал → |
-|-----|----------|----------|
-| 1 | Открой файл через Read (Claude мультимодален — изображения читаются визуально) | failed (файл не существует) |
-| 2 | Прочитай заявление TC, к которому привязан скриншот (что именно должно быть видно) | — |
-| 3 | Визуально проверь: подтверждает ли скриншот заявленное? **Опиши своими словами**, что видишь на скриншоте, прежде чем выносить вердикт. Запрещено выносить вердикт без описания содержимого. | failed (скриншот не подтверждает заявленное) |
-
-**Вердикты по скриншоту:**
-- **MATCH** — скриншот однозначно подтверждает заявление TC. В записи ревью указать: «VV: {что видно} → MATCH»
-- **PARTIAL** — скриншот релевантен, но элемент обрезан, нечитаем или не доказывает утверждение однозначно
-- **MISMATCH** — скриншот не соответствует заявленному (другое содержимое, пустой, не тот экран)
-
-**Правила:**
-- MISMATCH любого скриншота → `failed` с указанием: какой файл, что заявлено, что видно на самом деле
-- PARTIAL — не блокирует, но фиксируется в issues как замечание
-- Issue из шага 4.7.0 (визуальный TC без скриншота) → не является автоматическим `failed`, но **фиксируется как issue уровня HIGH** и включается в самари ревью. Ревьюер не может подтвердить визуальный критерий без визуального evidence
-
-### 5. Формирование вердикта
-
-> **ВАЖНО:** Допустимы ТОЛЬКО два статуса: `passed` или `failed`.
-
-#### 5.1. Специальное правило для QA-тикетов
-
-> **Перед вынесением вердикта** проверь тип тикета (`type` в frontmatter). Если тип — `qa` (тестирование), применяй следующую логику:
->
-> Обнаружение дефекта продукта (отсутствующий функционал, баг, BLOCKER) — это **правильно выполненная работа тестировщика**, а не провал тикета. Тестировщик не может починить продукт — его задача найти и задокументировать проблему.
->
-> **PASS ревью QA-тикета** если тестировщик:
-> - Протестировал все сценарии (или обосновал почему сценарий невозможен)
-> - Задокументировал результат каждого сценария (PASS/FAIL/BLOCKER)
-> - Для найденных дефектов указал: описание, шаги воспроизведения, ожидаемый/фактический результат
-> - Приложил evidence (a11y tree assertion + описание шагов). **Скриншоты ОБЯЗАТЕЛЬНЫ, если указаны в DoD OR в разделе Result (раздел «Файлы-артефакты»/«Скриншоты»)**
-> - Если скриншоты приложены — они существуют физически и соответствуют заявленному (проверено шагом 4.7)
-> - **⛔ HIGH issues об отсутствующих файлах-артефактах БЛОКИРУЕТ passed**: если в ревью найдено, что заявленный скриншот/файл отсутствует физически — это `failed`, независимо от наличия a11y assertions
->
-> **FAIL ревью QA-тикета** если:
-> - Не протестировал сценарий без объяснения
-> - Не задокументировал результат
-> - Не приложил evidence (ни a11y assertion, ни описания шагов)
-> - Заявил скриншоты в Result/DoD, но они физически не существуют (HIGH issue из шага 4.7.0)
-> - Приложил скриншоты, которые не соответствуют заявленному (MISMATCH по шагу 4.7)
-> - Пропустил дефект (не заметил явную проблему)
-
-#### 5.2. Стандартное правило
-
-Если **все** пункты DoD выполнены:
-
-```
----RESULT---
-status: passed
-issues: []
----RESULT---
-```
-
-Если **хотя бы один** пункт не выполнен:
-
-```
----RESULT---
-status: failed
-issues:
-  - "Пункт DoD X не выполнен: ожидалось Y, получено Z"
----RESULT---
-```
-
-### 6. Детализация замечаний (при failed)
-
-Для каждого невыполненного пункта:
-- Что ожидалось
-- Что получено
-- Файл/строка (если применимо)
-
-### 7. Пометка тикета
-
-1. Найди секцию `## Ревью` в тикете (если нет — создай с заголовком таблицы)
-2. Добавь новую запись **В КОНЕЦ таблицы**:
-
-```markdown
-| {дата} | {✅ passed / ❌ failed} | {краткое самари} |
-```
-
-3. Сохрани тикет в той же директории (`review/`)
-
-> **Порядок записей:** хронологический сверху вниз. Последняя строка = последнее ревью.