workflow-ai 1.0.63 → 1.0.64

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

@@ -0,0 +1,138 @@
+---
+name: review-result
+description: >
+  Скил ревью результата выполнения задачи. Проверяет соответствие результата
+  критериям готовности (Definition of Done) из тикета. Используется после
+  выполнения задачи для валидации качества перед перемещением в done/.
+---
+
+# Review-result — Agent Skill
+
+> **ОБЯЗАТЕЛЬНО:** Последние строки твоего ответа ВСЕГДА должны быть блоком `---RESULT---`.
+> Без этого блока пайплайн не распознает статус и тикет попадёт в `blocked`.
+> **Независимо от объёма анализа:** даже если ты написал развёрнутый code review, список замечаний или исследование — это не результат для пайплайна. Результат — только блок `---RESULT---` в самом конце.
+
+## Роль
+
+Ты — ревьюер результатов. Твоя задача — проверить что результат выполнения тикета соответствует критериям готовности (DoD) и что все артефакты реальны.
+
+**Ты делаешь:** чтение тикета, парсинг DoD, проверка каждого критерия, верификация файлов-артефактов, формирование вердикта (passed/failed), пометка тикета секцией ревью.
+
+**Ты НЕ делаешь:** исправление ошибок, перемещение тикетов, создание планов/тикетов, выставление статуса `skipped` (это прерогатива скила проверки актуальности).
+
+## Маршрутизация
+
+| Тип | Триггеры | Воркфлоу |
+|-----|----------|----------|
+| **Стандартное ревью** | Любой тикет в `review/` | → `workflows/review.md` |
+
+> Все типы тикетов проходят один воркфлоу. Различия в проверках определяются типом DoD — см. `knowledge/dod-patterns.md`.
+
+## Загрузка знаний
+
+Подгружай модули из `knowledge/` по необходимости:
+
+| Модуль | Когда загружать |
+|--------|----------------|
+| `knowledge/dod-patterns.md` | При определении типа проверки для конкретного пункта DoD |
+| `../shared/*` | **ВСЕГДА** перед началом работы — общие знания проекта |
+
+## Загрузка шаблонов
+
+Используй шаблоны из `templates/` для структурированного формирования вердикта:
+
+| Шаблон | Когда использовать |
+|--------|-------------------|
+| `templates/verdict.md` | При формировании вердикта после проверки выполнения тикета |
+
+## Загрузка алгоритмов
+
+Подгружай из `algorithms/` когда нужен формализованный метод:
+
+| Алгоритм | Когда загружать |
+|----------|----------------|
+| `algorithms/verification.md` | При верификации реальных изменений (шаг 3.6) для тикетов с `executor_type != human` |
+
+## Шаги проверки
+
+### 0. Быстрый выход
+
+Прочитай тикет. Если секция `## Ревью` существует и последняя запись — `passed` или `⏭ skipped` → немедленно верни `status: passed`.
+
+Если последняя запись — `failed` → перейди к полной проверке.
+
+### 1-6. Полная проверка
+
+Загрузи `workflows/review.md` и следуй шагам 1-6.
+
+## Допустимые статусы
+
+> **КРИТИЧНО**: `status` принимает ТОЛЬКО два значения: `passed` или `failed`.
+> Любой другой вывод (`default`, `ok`, `done`, `skipped`, и т.д.) — **ОШИБКА**.
+
+### passed
+
+```
+---RESULT---
+status: passed
+issues: []
+---RESULT---
+```
+
+### failed
+
+```
+---RESULT---
+status: failed
+issues:
+  - "Пункт DoD X не выполнен: ожидалось Y, получено Z"
+---RESULT---
+```
+
+## Принципы
+
+1. **DoD Driven** — вердикт определяется исключительно по критериям из DoD тикета
+2. **Evidence-Based** — каждый `[x]` должен быть подтверждён реальным артефактом, а не принят на веру
+3. **Audience Check** — для документов/ТЗ: читай глазами целевого исполнителя
+4. **No Fix** — ревьюер не исправляет ошибки, только фиксирует замечания
+5. **Single Pass** — один проход ревью, один вердикт, одна запись в таблицу
+6. **Minimal Thinking** — между tool-вызовами максимум 1 короткая строка. Скил выполняется в фоне, пользователь не читает промежуточный вывод. Развёрнутый анализ записывай в Result
+
+## Формат вывода
+
+- Русский язык
+- Структурированный вердикт: passed/failed + issues
+- Для каждого issue: ожидалось / получено / файл:строка
+- Блок `---RESULT---` — ровно один раз, в самом конце ответа
+
+## Интеграция с пайплайном
+
+1. Скил выполнения обрабатывает задачу
+2. **Этот скил** проверяет результат
+3. По `status` определяется goto-переход:
+   - `passed` → следующий stage
+   - `failed` → retry или blocked
+
+## Формат секции ревью в тикете
+
+```markdown
+## Ревью
+
+| Дата | Статус | Самари |
+|------|--------|--------|
+| 2026-03-25 14:30 | ❌ failed | Не пройдены тесты, отсутствует файл X |
+| 2026-03-25 15:45 | ✅ passed | Все критерии DoD выполнены |
+```
+
+> **Порядок записей:** хронологический сверху вниз. Последняя строка = последнее ревью.
+
+## Границы компетенции
+
+- **Исправление ошибок** → скил выполнения (через retry)
+- **Проверка актуальности** → соответствующий скил проекта
+- **Создание планов/тикетов** → pipeline
+- **Улучшение скилов** → соответствующий скил проекта
+
+---
+
+**Регрессионные тесты:** `tests/index.yaml`. Прогон: `node .workflow/src/scripts/run-skill-tests.js --skill review-result`

package/src/skills/review-result/algorithms/verification.md

@@ -0,0 +1,112 @@
+# Алгоритм верификации результата
+
+Формализованный метод проверки что результат выполнения тикета реален, а не является галлюцинацией агента.
+
+## Вход
+
+- Тикет с заполненной секцией «Результат выполнения»
+- Список файлов из секции «Изменённые файлы»
+- Чеклист DoD с отметками `[x]`
+
+## Выход
+
+- `verified` — все артефакты реальны и соответствуют заявленному
+- `not_verified` — обнаружены расхождения + список проблем
+
+## Алгоритм
+
+### Шаг 1: Проверка существования файлов
+
+```
+ДЛЯ КАЖДОГО файла из «Изменённые файлы»:
+  1. Выполни Read(файл) или Glob(паттерн)
+  2. ЕСЛИ файл не найден через Read/Glob →
+     FALLBACK: выполни Bash("ls -la {путь}") для подтверждения
+     (Glob может не видеть файлы в новых untracked директориях)
+  3. ЕСЛИ файл не найден И через fallback → добавь в issues: "Файл {путь} не существует"
+  4. ЕСЛИ файл найден любым способом → перейди к шагу 2
+```
+
+> **⚠️ Почему fallback:** Glob/Read могут не находить файлы в новых директориях,
+> которые ещё не добавлены в git index. Bash(`ls`) работает напрямую с файловой
+> системой и всегда видит реальные файлы. Без fallback ревьюер ложно репортит
+> отсутствие файлов, которые были корректно созданы исполнителем.
+
+### Шаг 2: Проверка содержимого
+
+```
+ДЛЯ КАЖДОГО найденного файла:
+  1. Открой файл через Read
+  2. Проверь:
+     a. Файл НЕ пустой (> 0 строк содержательного контента)
+     b. Файл НЕ содержит только шаблонные плейсхолдеры
+     c. Контент соответствует типу файла (код = код, документ = текст)
+  3. ЕСЛИ файл пуст или placeholder → добавь в issues: "Файл {путь} — пустой/placeholder"
+```
+
+### Шаг 3: Проверка Summary
+
+```
+1. Найди секцию «Результат выполнения» → «Summary»
+2. ЕСЛИ Summary пуст или содержит заглушку ("TODO", "...", "Заполнить") → issues
+3. ЕСЛИ Summary < 10 слов → предупреждение (может быть слишком кратким)
+4. ЕСЛИ Summary содержательный → OK
+```
+
+### Шаг 4: Кросс-валидация DoD ↔ Артефакты
+
+```
+ДЛЯ КАЖДОГО пункта DoD отмеченного [x]:
+  1. Определи артефакт, к которому относится пункт
+  2. Открой артефакт
+  3. Проверь что критерий ДЕЙСТВИТЕЛЬНО выполнен:
+     - "Файл создан" → файл существует и не пуст
+     - "Секция X добавлена" → секция присутствует в файле
+     - "Нет ссылок на Y" → поиск Y по файлу = 0 результатов
+     - "Тесты проходят" → запустить тесты (если возможно)
+  4. ЕСЛИ критерий НЕ выполнен → issues: "DoD '{критерий}' отмечен [x], но не подтверждён"
+```
+
+### Шаг 5: Формирование результата
+
+```
+ЕСЛИ issues пуст:
+  → verified
+ИНАЧЕ:
+  → not_verified + список issues
+```
+
+## Пороги и правила
+
+| Правило | Значение |
+|---------|----------|
+| Минимум строк для «не пустой» файл | > 3 строки содержательного контента |
+| Маркеры placeholder | `TODO`, `TBD`, `XXX`, `FIXME`, `заполнить`, `...` |
+| Минимум слов в Summary | 10 слов |
+| Любой issue = failed | Да, без исключений |
+
+## Граничные случаи
+
+| Случай | Решение |
+|--------|---------|
+| Тикет с `executor_type: human` | Пропустить верификацию файлов — человек мог внести изменения вне системы |
+| Файл удалён как часть задачи | Проверить что файл действительно НЕ существует (обратная проверка) |
+| DoD содержит субъективный критерий | Оценить по best effort, отметить в комментарии |
+| Файл изменён, но не создан | Проверить что изменения присутствуют (diff или содержимое) |
+
+## Пример применения
+
+**Вход:**
+- Тикет XXX-005 с DoD: `[x] Создан workflows/process.md`, `[x] README создан`
+- Изменённые файлы: `workflows/process.md`, `README.md`
+
+**Проверка:**
+1. `Read("src/skills/example-skill/workflows/process.md")` → файл существует, 45 строк → OK
+2. `Read("src/skills/example-skill/README.md")` → файл существует, 30 строк → OK
+3. Summary: "Модульная реструктуризация..." — 15 слов → OK
+4. DoD `[x] workflows/` → файл есть, содержит шаги → verified
+5. DoD `[x] README` → файл есть, структура верна → verified
+
+**Результат:** `verified`
+
+<!-- РАСШИРЕНИЕ: добавляй новые проверки и граничные случаи ниже -->

package/src/skills/review-result/knowledge/dod-patterns.md

@@ -0,0 +1,115 @@
+# Паттерны DoD по типам тикетов
+
+Справочник типичных критериев готовности (Definition of Done) для разных типов задач. Помогает ревьюеру определить тип проверки и ожидания.
+
+## Паттерны по типу тикета
+
+### impl (реализация)
+
+| Типичный DoD | Тип проверки | На что обратить внимание |
+|--------------|-------------|-------------------------|
+| Файл `X` создан / изменён | `file_exists` | Проверить что файл не пустой, содержит реальный код |
+| Тесты проходят | `tests` | Запустить тесты, проверить покрытие |
+| Код проходит линтер | `compilation` | Запустить lint |
+| Реализована функция X | `text` | Проверить наличие функции, её сигнатуру и логику |
+| Тесты на маппинг/парсинг данных | `tests` + `text` | Проверить, что тестовые fixtures содержат **реальные** значения из runtime-источника (лог, конфиг, API), а не синтетические. Прочитать источник данных и сверить с fixtures. Если fixtures не соответствуют реальным данным — тесты тавтологичны |
+| Документация обновлена | `text` | Проверить JSDoc / README / комментарии |
+
+### fix (исправление бага)
+
+| Типичный DoD | Тип проверки | На что обратить внимание |
+|--------------|-------------|-------------------------|
+| Баг исправлен | `tests` | Регрессионный тест покрывает сценарий бага |
+| Тесты не сломаны | `tests` | Все существующие тесты проходят |
+| Нет побочных эффектов | `text` | Минимальность изменений, не затронуты несвязанные файлы |
+
+### docs (документация)
+
+| Типичный DoD | Тип проверки | На что обратить внимание |
+|--------------|-------------|-------------------------|
+| Документ создан | `file_exists` | Файл существует и не пустой |
+| Структура соответствует шаблону | `structure` | Все обязательные секции присутствуют |
+| Файл самодостаточен | `text` | → Применить шаг 3.5 (проверка с позиции аудитории) |
+| Нет плейсхолдеров | `text` | Поиск `TODO`, `XXX`, `TBD`, `заменить` |
+
+### coach (улучшение скилов)
+
+| Типичный DoD | Тип проверки | На что обратить внимание |
+|--------------|-------------|-------------------------|
+| Файлы скила созданы | `file_exists` | workflows/, knowledge/, algorithms/ существуют |
+| SKILL.md обновлён | `text` | Таблицы загрузки, маршрутизация |
+| Нет ссылок на имена скилов | `text` | Поиск хардкода ролей — проверка изоляции |
+| README создан | `file_exists` + `structure` | Все обязательные секции |
+
+### rsh (исследование)
+
+| Типичный DoD | Тип проверки | На что обратить внимание |
+|--------------|-------------|-------------------------|
+| Отчёт создан | `file_exists` | Файл существует |
+| Источники указаны | `text` | Ссылки на источники, не голословные утверждения |
+| Выводы структурированы | `structure` | Секции, таблицы, приоритизация |
+
+### admin (административная)
+
+| Типичный DoD | Тип проверки | На что обратить внимание |
+|--------------|-------------|-------------------------|
+| Конфигурация обновлена | `file_exists` + `text` | Файл изменён, значения корректны |
+| Система работает | `compilation` | Проверить что конфиг валиден |
+
+## Универсальные проверки
+
+Применяются ко **всем** типам тикетов:
+
+| Проверка | Описание |
+|----------|----------|
+| Summary не пустой | Секция «Результат выполнения» содержит содержательное описание |
+| Изменённые файлы перечислены | Список файлов не пуст (для тикетов с артефактами) |
+| Файлы реально существуют | Все перечисленные файлы доступны через Read/Glob |
+| DoD ↔ Result согласованы | Каждый пункт DoD отражён в результате |
+
+### qa (тестирование / manual testing)
+
+| Типичный DoD | Тип проверки | На что обратить внимание |
+|--------------|-------------|-------------------------|
+| Сценарий X протестирован | `text` | Результат (PASS/FAIL/BLOCKER) задокументирован с evidence (a11y assertion + шаги) |
+| Найденные дефекты зафиксированы | `text` | Дефекты содержат шаги воспроизведения, ожидаемый/фактический результат |
+| Скриншоты приложены (если требуются в DoD) | `file_exists` + `visual` | Файлы существуют, **содержимое визуально проверено** — скриншот подтверждает заявление TC (шаг 3.7 review.md) |
+
+> **⚠️ КРИТИЧЕСКИ ВАЖНО — Правило оценки QA-тикетов:**
+>
+> Для QA-тикетов обнаружение дефекта продукта — это **правильно выполненная работа тестировщика**, а НЕ ошибка выполнения тикета.
+>
+> - Если тестировщик обнаружил, что функционал отсутствует или сломан, и **задокументировал это** (описал дефект, шаги воспроизведения, a11y assertion) → пункт DoD **выполнен**. Тестировщик не может починить продукт — его задача найти и зафиксировать проблему. Скриншоты от исполнителя не обязательны по умолчанию — только если явно требуются в DoD. Однако если TC содержит визуальный критерий (как объект выглядит пользователю) — ревьюер обязан применить шаг 4.7 review.md: найти скриншоты, открыть и визуально проверить, либо зафиксировать отсутствие визуального evidence как issue.
+> - FAIL на ревью QA-тикета допустим только если тестировщик **не выполнил свою работу**: не протестировал сценарий, не задокументировал результат, не приложил доказательства, пропустил сценарии без объяснения.
+> - Статус сценария BLOCKER/FAIL в матрице результатов ≠ FAIL ревью тикета. Это выявленный дефект = ценный результат работы.
+
+> **⚠️ КРИТИЧЕСКИ ВАЖНО — Подмена ручной проверки запуском автотестов:**
+>
+> Если QA-тикет содержит DoD «проверены визуально», «UI протестирован», «рендеринг проверен» (или аналог, требующий реального host-окружения), а evidence в результате — assertion из unit/integration-тест файлов разработки (`.test.ts`, `.test.js`), запуск `mocha`/`jest`/`vitest`/любого test runner'а — это **fail ревью** независимо от того, сколько тестов прошло.
+>
+> **Признаки подмены:**
+> - В Evidence для каждого TC указан assertion вида `assert.strictEqual(icon.id, ...)` со ссылкой на файл `*.test.*`
+> - В «Протоколе выполнения» — команда запуска test runner вместо MCP-вызовов desktop/browser-инструмента
+> - В заметках формулировка типа «эквивалентно визуальной проверке, так как объект X создаётся теми же конструкторами»
+> - Отсутствуют MCP snapshot/screenshot из реального host-окружения, в котором продукт исполняется конечным пользователем
+>
+> **Почему это fail:** unit-тесты, на которые ссылается evidence, **уже были зелёными** до создания QA-тикета (они прошли в задаче реализации). Их повторный запуск не подтверждает работоспособность в реальной среде — он подтверждает только то, что уже было известно. Эквивалентность «конструктор объекта в unit-тесте = отрендеренный объект в реальном UI» ложная: unit-тест не воспроизводит host runtime, интеграцию с системой, accessibility tree, реальный пользовательский ввод.
+>
+> **Правильное поведение тестировщика при недоступности host-окружения:** BLOCKED с обоснованной причиной + создание HUMAN-тикета, если сценарий критический. См. `manual-testing/algorithms/blocked-tool-strategy.md`. Ревьюер обязан принимать BLOCKED как валидный результат и отклонять подмену.
+>
+> **Регресс между итерациями ревью:** если предыдущая итерация ревью корректно отклонила evidence как «code review без реальных assertions из запущенного расширения», а следующая итерация принимает **то же самое** evidence с переформулированным обоснованием — это сигнал, что ревьюер поддался на риторику «обоснования недоступности» вместо проверки фактов. Перечитай предыдущее ревью: если оно отклонило по той же причине — текущее evidence должно содержать **новый тип данных** (MCP snapshot, скриншот из host, лог реального запуска), а не переформулировку старого.
+
+## Специальные паттерны
+
+### Self-Modified DoD (`[x]` + дискламер «НЕ ПРОЙДЕН»)
+
+**Признак:** пункт DoD помечен `[x]`, но рядом написано «НЕ ПРОЙДЕН», «FAIL», «фактически: X».
+
+**Правило:** `[x]` + «НЕ ПРОЙДЕН» = структурный дефект артефакта. Тестировщик перепутал «проверен» с «выполнен».
+
+**Действие ревьюера:**
+- Зафиксировать как issue: «DoD п.N: помечен `[x]`, но фактически не выполнен — ожидалось Y, получено Z»
+- Общий вердикт определяется по фактическому результату (Z), а не по `[x]`
+- Если фактический результат соответствует ожиданиям задачи (например, задача — зафиксировать состояние, а не достичь цели) → passed, но issue фиксируется как LOW
+
+<!-- РАСШИРЕНИЕ: добавляй новые паттерны DoD по типам тикетов ниже -->