workflow-ai 1.0.40 → 1.0.41

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

@@ -1,285 +1,329 @@
----
-name: review-result
-description: Проверить результат выполнения задачи на соответствие Definition of Done. Используется после execute-task для валидации качества работы.
----
-
-# Проверка результата (Review Result)
-
-> **ОБЯЗАТЕЛЬНО:** Последние строки твоего ответа ВСЕГДА должны быть блоком `---RESULT---`.
-> Без этого блока пайплайн не распознает статус и тикет попадёт в `blocked`.
-> Даже если ревью очевидно — всё равно заверши ответ блоком результата.
-
-Этот skill проверяет результат выполнения задачи на соответствие критериям готовности (Definition of Done) из тикета.
-
-## Когда использовать
-
-- Задача выполнена и тикет перемещён в `review/`
-- Требуется валидация качества перед перемещением в `done/`
-- Retry-логика пайплайна: определить status для goto-перехода
-
-## Шаги проверки
-
-### 0. Проверить последний статус ревью
-
-**До любых проверок** найди в тикете секцию `## Ревью`.
-
-Если секция существует и содержит записи — посмотри на **последнюю запись** (последняя строка таблицы или последний элемент списка):
-
-- Если последняя запись имеет статус `passed` — ревью уже пройдено. Немедленно верни результат:
-
-```
----RESULT---
-status: passed
-issues: []
----RESULT---
-```
-
-- Если последняя запись имеет статус `⏭ skipped` — тикет пропущен check-relevance. Ревью проводить **НЕ НАДО**. Немедленно верни результат:
-
-```
----RESULT---
-status: passed
-issues: []
----RESULT---
-```
-
-- Если последняя запись имеет статус `failed` — **необходима повторная проверка**. Переходи к шагу 1.
-
-> **ВАЖНО:** Проверяй именно ПОСЛЕДНЮЮ запись, а не любую. Если после `passed`/`skipped` появилась `failed` — задача требует повторной проверки. Только если последний статус `passed` или `skipped` — можно пропустить.
-
-### 1. Прочитать тикет
-
-ID тикета передаётся в промпте как `ticket_id` в секции Context.
-
-```
-Путь: .workflow/tickets/review/{TICKET-ID}.md
-```
-
-**Важно:** НЕ перемещай тикет — перемещение выполняется отдельным stage пайплайна по результату этого skill.
-
-Извлечь:
-- Definition of Done (DoD) — чеклист критериев готовности
-- Детали задачи — требования к реализации
-- Результат выполнения (секция Result) — что сделано
-
-### 2. Проверить каждый пункт DoD
-
-Для каждого критерия из Definition of Done:
-
-| Тип проверки | Описание |
-|--------------|----------|
-| `file_exists` | Файл существует по указанному пути |
-| `compilation` | Код компилируется / линтер проходит |
-| `tests` | Тесты проходят |
-| `text` | Текстовый критерий выполнен (содержимое, структура) |
-| `structure` | Структура соответствует шаблону |
-
-### 3. Сверить результат с требованиями
-
-Сравнить секцию «Результат выполнения» с «Деталями задачи»:
-- Все ли требования учтены
-- Соответствует ли реализация описанию
-- Нет ли расхождений
-
-### 4. Сформировать вердикт
-
-> **ВАЖНО:** Review-result НИКОГДА не пишет статус `skipped`. Допустимы только `passed` или `failed`. Статус `skipped` — прерогатива check-relevance.
-
-Возвращать структурированный результат строго в одном из двух форматов:
-
-> **КРИТИЧНО**: `status` принимает ТОЛЬКО два значения: `passed` или `failed`.
-> Любой другой вывод (`default`, `ok`, `done`, `complete`, `yes`, и т.д.) — **ОШИБКА**.
-> Пайплайн не продолжится корректно, если статус не распознан.
-
-Если **все** пункты DoD выполнены:
-
-```
----RESULT---
-status: passed
-issues: []
----RESULT---
-```
-
-Если **хотя бы один** пункт DoD не выполнен:
-
-```
----RESULT---
-status: failed
-issues:
-  - "Пункт DoD X не выполнен: ожидалось Y, получено Z"
-  - "Файл X не создан"
-  - "Тест Y не прошёл"
----RESULT---
-```
-
-> Блок `---RESULT---` должен быть в выводе **ровно один раз**, в самом конце ответа.
-
-### 5. При `failed`: детализировать замечания
-
-Для каждого невыполненного пункта:
-- Описать что ожидалось
-- Описать что получено
-- Указать файл/строку если применимо
-
-## Алгоритм проверки
-
-```
-0. Быстрый выход:
-   - Прочитать тикет
-   - Найти секцию "## Ревью"
-   - Если последняя запись "passed" или "skipped" → вернуть status: passed, остановиться
-   - Если последняя запись "failed" → перейти к шагу 1 (повторная проверка)
-
-1. Парсинг тикета:
-   - Извлечь DoD (список критериев)
-   - Извлечь Result (что сделано)
-   - Извлечь Детали задачи (требования)
-
-2. Для каждого пункта DoD:
-   - Определить тип проверки (file/compilation/tests/text)
-   - Выполнить проверку
-   - Записать результат (pass/fail + комментарий)
-
-3. Сверка Result ↔ Детали задачи:
-   - Все ли файлы созданы
-   - Соответствует ли структура
-   - Нет ли расхождений
-
-4. Формирование вердикта:
-   - Если все пункты pass → status: passed
-   - Если есть fail → status: failed + список issues
-
-5. Вывод результата в формате ---RESULT---
-
-6. Пометка тикета о результате ревью:
-   - Добавить секцию `## Ревью` в тикете (если её нет — создать с заголовком таблицы)
-   - **ВАЖНО: новую запись добавлять В КОНЕЦ таблицы** (последней строкой). Не вставлять перед существующими записями!
-   - Указать:
-     - Дата ревью
-     - Статус: passed/failed
-     - Краткий самари (если failed — что не так)
-   - Сохранить тикет в той же директории
-```
-
-## Типы проверок
-
-### file_exists
-
-Проверка существования файла:
-
-```
-Критерий: "[ ] Файл `src/logger.py` создан"
-Проверка: os.path.exists("src/logger.py")
-Результат: pass/fail
-```
-
-### compilation
-
-Проверка компиляции / линта:
-
-```
-Критерий: "[ ] Код проходит линтер"
-Проверка: npm run lint / ruff check / etc.
-Результат: pass/fail + вывод
-```
-
-### tests
-
-Проверка тестов:
-
-```
-Критерий: "[ ] Тесты проходят"
-Проверка: npm test / pytest / etc.
-Результат: pass/fail + вывод
-```
-
-### text
-
-Текстовая проверка:
-
-```
-Критерий: "[ ] Описан алгоритм проверки DoD"
-Проверка: Поиск раздела "Алгоритм" в файле
-Результат: pass/fail
-```
-
-### structure
-
-Проверка структуры:
-
-```
-Критерий: "[ ] Структура аналогична существующим skills"
-Проверка: Сравнение с шаблоном
-Результат: pass/fail + замечания
-```
-
-## Пример использования
-
-```
-Проверь результат IMPL-006 на соответствие DoD.
-```
-
-```
-review-result .workflow/tickets/in-progress/IMPL-006.md
-```
-
-## Пример вывода
-
-### Успешная проверка
-
-```markdown
----RESULT---
-status: passed
-issues: []
----RESULT---
-```
-
-### Неуспешная проверка
-
-```markdown
----RESULT---
-status: failed
-issues:
-  - "Пункт DoD 'Файл .workflow/src/skills/review-result/SKILL.md создан' не выполнен: файл не найден"
-  - "Пункт DoD 'Описан алгоритм проверки DoD' не выполнен: раздел 'Алгоритм' отсутствует"
-  - "Тесты не прошли: 2 failed, 5 passed"
----RESULT---
-```
-
-## Формат секции ревью в тикете
-
-После проверки skill добавляет в тикет секцию. **Новые записи всегда добавляются В КОНЕЦ таблицы** (хронологический порядок: старые сверху, новые снизу):
-
-```markdown
-## Ревью
-
-| Дата | Статус | Самари |
-|------|--------|--------|
-| 2026-03-03 14:30 | ❌ failed | Не пройдены тесты, отсутствует файл logger.py |
-| 2026-03-03 15:45 | ✅ passed | Все критерии DoD выполнены после исправления |
-```
-
-> **Порядок записей:** хронологический сверху вниз. Последняя строка = последнее ревью. Код `getLastReviewStatus()` определяет статус по последней строке.
-
-## Интеграция с пайплайном
-
-В retry-логике пайплайна:
-
-1. `execute-task` выполняет задачу
-2. `review-result` проверяет результат
-3. По `status` определяется goto-переход:
-   - `passed` → следующий stage
-   - `failed` → retry или blocked
-
-## Результат
-
-- Структурированный вердикт (passed/failed)
-- Список замечаний (если есть)
-- **Тикет помечен секцией `## Ревью`** с датой, статусом и кратким самари
-- Готово для использования в goto-логике
-
-## Связанные skills
-
-- `execute-task` — выполнение задачи перед проверкой
-- `move-ticket` — перемещение по результатам проверки
-- `check-conditions` — проверка условий для зависимых задач
+---
+name: review-result
+description: Проверить результат выполнения задачи на соответствие Definition of Done. Используется после execute-task для валидации качества работы.
+---
+
+# Проверка результата (Review Result)
+
+> **ОБЯЗАТЕЛЬНО:** Последние строки твоего ответа ВСЕГДА должны быть блоком `---RESULT---`.
+> Без этого блока пайплайн не распознает статус и тикет попадёт в `blocked`.
+> Даже если ревью очевидно — всё равно заверши ответ блоком результата.
+
+Этот skill проверяет результат выполнения задачи на соответствие критериям готовности (Definition of Done) из тикета.
+
+## Когда использовать
+
+- Задача выполнена и тикет перемещён в `review/`
+- Требуется валидация качества перед перемещением в `done/`
+- Retry-логика пайплайна: определить status для goto-перехода
+
+## Шаги проверки
+
+### 0. Проверить последний статус ревью
+
+**До любых проверок** найди в тикете секцию `## Ревью`.
+
+Если секция существует и содержит записи — посмотри на **последнюю запись** (последняя строка таблицы или последний элемент списка):
+
+- Если последняя запись имеет статус `passed` — ревью уже пройдено. Немедленно верни результат:
+
+```
+---RESULT---
+status: passed
+issues: []
+---RESULT---
+```
+
+- Если последняя запись имеет статус `⏭ skipped` — тикет пропущен check-relevance. Ревью проводить **НЕ НАДО**. Немедленно верни результат:
+
+```
+---RESULT---
+status: passed
+issues: []
+---RESULT---
+```
+
+- Если последняя запись имеет статус `failed` — **необходима повторная проверка**. Переходи к шагу 1.
+
+> **ВАЖНО:** Проверяй именно ПОСЛЕДНЮЮ запись, а не любую. Если после `passed`/`skipped` появилась `failed` — задача требует повторной проверки. Только если последний статус `passed` или `skipped` — можно пропустить.
+
+### 1. Прочитать тикет
+
+ID тикета передаётся в промпте как `ticket_id` в секции Context.
+
+```
+Путь: .workflow/tickets/review/{TICKET-ID}.md
+```
+
+**Важно:** НЕ перемещай тикет — перемещение выполняется отдельным stage пайплайна по результату этого skill.
+
+Извлечь:
+- Definition of Done (DoD) — чеклист критериев готовности
+- Детали задачи — требования к реализации
+- Результат выполнения (секция Result) — что сделано
+
+### 2. Проверить каждый пункт DoD
+
+Для каждого критерия из Definition of Done:
+
+| Тип проверки | Описание |
+|--------------|----------|
+| `file_exists` | Файл существует по указанному пути |
+| `compilation` | Код компилируется / линтер проходит |
+| `tests` | Тесты проходят |
+| `text` | Текстовый критерий выполнен (содержимое, структура) |
+| `structure` | Структура соответствует шаблону |
+
+### 3. Сверить результат с требованиями
+
+Сравнить секцию «Результат выполнения» с «Деталями задачи»:
+- Все ли требования учтены
+- Соответствует ли реализация описанию
+- Нет ли расхождений
+
+### 3.5. Проверка с позиции целевой аудитории
+
+> **Применяется** когда результат тикета — документ/ТЗ/спецификация, предназначенные для конкретного исполнителя (разработчик, дизайнер, внешний подрядчик и т.д.).
+
+Если в DoD есть критерий типа *"файл самодостаточен"* или *"исполнитель не должен смотреть другие документы"*:
+
+| Проверка | Как проверить | Провал → |
+|----------|---------------|----------|
+| Credentials указаны или описано где взять | Искать плейсхолдеры `XXX`, `TODO`, `заменить на реальный` — для каждого должна быть инструкция | failed |
+| Все системные зависимости перечислены | Для каждого API/библиотеки в сниппетах — проверить наличие в секции permissions/dependencies | failed |
+| Параметры вычислимы | Для условных параметров (`isFirst`, `count`) — описан способ получения значения | failed |
+| Environment-переключение описано | Если есть debug/dev/prod режимы — описан механизм переключения | failed |
+
+**Правило:** Прочитай документ глазами целевого исполнителя. Если он не может начать работу без дополнительных вопросов — это `failed`, даже если формальные DoD выполнены.
+
+### 3.6. Верификация реальных изменений
+
+> **Применяется только** для тикетов с `executor_type != human`.
+
+Даже если все DoD отмечены как `[x]`, необходимо убедиться что изменения реально существуют, а не являются галлюцинацией агента.
+
+| Проверка | Как проверить | Провал → |
+|----------|---------------|----------|
+| Файлы-артефакты существуют | Проверить все файлы из секции «Изменённые файлы» через Read/Glob | failed |
+| Файлы содержат реальный контент | Открыть файл, убедиться что содержимое — не шаблон/placeholder | failed |
+| Секция Result не пуста | Проверить что Summary заполнен содержательно (не заглушка) | failed |
+| DoD соответствует реальности | Для каждого `[x]` — открыть артефакт и убедиться что критерий действительно выполнен | failed |
+
+**Правило:** Если хотя бы одна проверка провалена → статус `failed`, даже если все DoD отмечены `[x]`.
+
+### 4. Сформировать вердикт
+
+> **ВАЖНО:** Review-result НИКОГДА не пишет статус `skipped`. Допустимы только `passed` или `failed`. Статус `skipped` — прерогатива check-relevance.
+
+Возвращать структурированный результат строго в одном из двух форматов:
+
+> **КРИТИЧНО**: `status` принимает ТОЛЬКО два значения: `passed` или `failed`.
+> Любой другой вывод (`default`, `ok`, `done`, `complete`, `yes`, и т.д.) — **ОШИБКА**.
+> Пайплайн не продолжится корректно, если статус не распознан.
+
+Если **все** пункты DoD выполнены:
+
+```
+---RESULT---
+status: passed
+issues: []
+---RESULT---
+```
+
+Если **хотя бы один** пункт DoD не выполнен:
+
+```
+---RESULT---
+status: failed
+issues:
+  - "Пункт DoD X не выполнен: ожидалось Y, получено Z"
+  - "Файл X не создан"
+  - "Тест Y не прошёл"
+---RESULT---
+```
+
+> Блок `---RESULT---` должен быть в выводе **ровно один раз**, в самом конце ответа.
+
+### 5. При `failed`: детализировать замечания
+
+Для каждого невыполненного пункта:
+- Описать что ожидалось
+- Описать что получено
+- Указать файл/строку если применимо
+
+## Алгоритм проверки
+
+```
+0. Быстрый выход:
+   - Прочитать тикет
+   - Найти секцию "## Ревью"
+   - Если последняя запись "passed" или "skipped" → вернуть status: passed, остановиться
+   - Если последняя запись "failed" → перейти к шагу 1 (повторная проверка)
+
+1. Парсинг тикета:
+   - Извлечь DoD (список критериев)
+   - Извлечь Result (что сделано)
+   - Извлечь Детали задачи (требования)
+
+2. Для каждого пункта DoD:
+   - Определить тип проверки (file/compilation/tests/text)
+   - Выполнить проверку
+   - Записать результат (pass/fail + комментарий)
+
+3. Сверка Result ↔ Детали задачи:
+   - Все ли файлы созданы
+   - Соответствует ли структура
+   - Нет ли расхождений
+
+3.5. Проверка с позиции целевой аудитории (для документов/ТЗ/спецификаций):
+   - Credentials указаны или описано где взять (нет голых плейсхолдеров)
+   - Все системные зависимости перечислены
+   - Условные параметры вычислимы
+   - Environment-переключение описано
+   - Любой провал → status: failed
+
+3.6. Верификация реальных изменений (только executor_type != human):
+   - Файлы из «Изменённые файлы» существуют
+   - Файлы содержат реальный контент (не placeholder)
+   - Summary заполнен содержательно
+   - Каждый [x] в DoD подтверждён реальным артефактом
+   - Любой провал → status: failed
+
+4. Формирование вердикта:
+   - Если все пункты pass → status: passed
+   - Если есть fail → status: failed + список issues
+
+5. Вывод результата в формате ---RESULT---
+
+6. Пометка тикета о результате ревью:
+   - Добавить секцию `## Ревью` в тикете (если её нет — создать с заголовком таблицы)
+   - **ВАЖНО: новую запись добавлять В КОНЕЦ таблицы** (последней строкой). Не вставлять перед существующими записями!
+   - Указать:
+     - Дата ревью
+     - Статус: passed/failed
+     - Краткий самари (если failed — что не так)
+   - Сохранить тикет в той же директории
+```
+
+## Типы проверок
+
+### file_exists
+
+Проверка существования файла:
+
+```
+Критерий: "[ ] Файл `src/logger.py` создан"
+Проверка: os.path.exists("src/logger.py")
+Результат: pass/fail
+```
+
+### compilation
+
+Проверка компиляции / линта:
+
+```
+Критерий: "[ ] Код проходит линтер"
+Проверка: npm run lint / ruff check / etc.
+Результат: pass/fail + вывод
+```
+
+### tests
+
+Проверка тестов:
+
+```
+Критерий: "[ ] Тесты проходят"
+Проверка: npm test / pytest / etc.
+Результат: pass/fail + вывод
+```
+
+### text
+
+Текстовая проверка:
+
+```
+Критерий: "[ ] Описан алгоритм проверки DoD"
+Проверка: Поиск раздела "Алгоритм" в файле
+Результат: pass/fail
+```
+
+### structure
+
+Проверка структуры:
+
+```
+Критерий: "[ ] Структура аналогична существующим skills"
+Проверка: Сравнение с шаблоном
+Результат: pass/fail + замечания
+```
+
+## Пример использования
+
+```
+Проверь результат IMPL-006 на соответствие DoD.
+```
+
+```
+review-result .workflow/tickets/in-progress/IMPL-006.md
+```
+
+## Пример вывода
+
+### Успешная проверка
+
+```markdown
+---RESULT---
+status: passed
+issues: []
+---RESULT---
+```
+
+### Неуспешная проверка
+
+```markdown
+---RESULT---
+status: failed
+issues:
+  - "Пункт DoD 'Файл .workflow/src/skills/review-result/SKILL.md создан' не выполнен: файл не найден"
+  - "Пункт DoD 'Описан алгоритм проверки DoD' не выполнен: раздел 'Алгоритм' отсутствует"
+  - "Тесты не прошли: 2 failed, 5 passed"
+---RESULT---
+```
+
+## Формат секции ревью в тикете
+
+После проверки skill добавляет в тикет секцию. **Новые записи всегда добавляются В КОНЕЦ таблицы** (хронологический порядок: старые сверху, новые снизу):
+
+```markdown
+## Ревью
+
+| Дата | Статус | Самари |
+|------|--------|--------|
+| 2026-03-03 14:30 | ❌ failed | Не пройдены тесты, отсутствует файл logger.py |
+| 2026-03-03 15:45 | ✅ passed | Все критерии DoD выполнены после исправления |
+```
+
+> **Порядок записей:** хронологический сверху вниз. Последняя строка = последнее ревью. Код `getLastReviewStatus()` определяет статус по последней строке.
+
+## Интеграция с пайплайном
+
+В retry-логике пайплайна:
+
+1. `execute-task` выполняет задачу
+2. `review-result` проверяет результат
+3. По `status` определяется goto-переход:
+   - `passed` → следующий stage
+   - `failed` → retry или blocked
+
+## Результат
+
+- Структурированный вердикт (passed/failed)
+- Список замечаний (если есть)
+- **Тикет помечен секцией `## Ревью`** с датой, статусом и кратким самари
+- Готово для использования в goto-логике
+
+## Связанные skills
+
+- `execute-task` — выполнение задачи перед проверкой
+- `move-ticket` — перемещение по результатам проверки
+- `check-conditions` — проверка условий для зависимых задач