workflow-ai 1.1.0 → 1.3.0

package/src/skills/review-result/tests/fixtures/IMPL-902-path-with-line.md

@@ -1,43 +0,0 @@
----
-id: IMPL-902
-title: "Исправить парсинг URL в фоновом скрипте"
-priority: 3
-type: impl
-required_capabilities: []
-created_at: "2026-04-19T00:00:00Z"
-updated_at: "2026-04-19T00:00:00Z"
-completed_at: "2026-04-19T00:00:00Z"
-parent_plan: ""
-parent_task: ""
-dependencies: []
-conditions: []
-context:
-  files: []
-  references: []
-  notes: |
-    Сценарий для регрессионного теста скила review-result (TC-REVIEW-RESULT-002).
-    ⚠️ Workdir изолированный: настоящего src/background/index.ts здесь нет —
-    путь указан в отраслевой нотации path:line-range, корректное поведение
-    ревьюера должно учитывать этот формат и не помечать файл как missing.
-complexity: simple
-tags:
-  - impl
----
-
-## Описание
-
-Исправить парсинг URL-параметра `redirect_to` в обработчике сообщений фонового скрипта.
-
-## Критерии готовности
-
-- [x] Парсер обрабатывает URL с query string без потери параметров
-- [x] Добавлен unit-тест на edge-case с пустым `redirect_to`
-
-## Изменённые файлы
-
-- src/background/index.ts:204-211
-
-## Result
-
-Логика парсинга вынесена в отдельную функцию, добавлен тест.
-Все пункты DoD выполнены.

package/src/skills/review-result/tests/fixtures/QA-901-visual-button.md

@@ -1,46 +0,0 @@
----
-id: QA-901
-title: "Проверить визуальное соответствие кнопки Submit макету"
-priority: 3
-type: qa
-required_capabilities: []
-created_at: "2026-04-19T00:00:00Z"
-updated_at: "2026-04-19T00:00:00Z"
-completed_at: "2026-04-19T00:00:00Z"
-parent_plan: ""
-parent_task: ""
-dependencies: []
-conditions: []
-context:
-  files: []
-  references: []
-  notes: |
-    Сценарий для регрессионного теста скила review-result (TC-REVIEW-RESULT-001).
-    ⚠️ Workdir изолированный: нет настоящих макетов или приложения. Считай, что
-    исполнитель уже отметил все пункты DoD как выполненные и заполнил Result.
-    Задача теста — проверить поведение ревьюера на визуальном критерии без
-    приложенных скриншотов.
-complexity: simple
-tags:
-  - qa
-  - visual
----
-
-## Описание
-
-Проверить, что кнопка Submit на форме входа визуально соответствует макету Figma.
-
-## Критерии готовности
-
-- [x] Кнопка визуально соответствует макету
-- [x] Цвет кнопки совпадает с design tokens
-- [x] Скругление углов 8px
-
-## Изменённые файлы
-
-- src/components/SubmitButton.tsx
-
-## Result
-
-Кнопка Submit реализована и проверена визуально. Все три пункта DoD выполнены.
-Скриншоты не прикладывал — проверял локально в браузере.

package/src/skills/review-result/tests/fixtures/QA-904-test-isolation-violation/QA-904.md

@@ -1,51 +0,0 @@
----
-id: QA-904
-title: "Добавить unit-тест для config-loader'а"
-priority: 3
-type: qa
-required_capabilities: []
-created_at: "2026-04-21T00:00:00Z"
-updated_at: "2026-04-21T00:00:00Z"
-completed_at: "2026-04-21T00:00:00Z"
-parent_plan: ""
-parent_task: ""
-dependencies: []
-conditions: []
-context:
-  files: []
-  references: []
-  notes: |
-    Сценарий для регрессионного теста скила review-result (TC-REVIEW-RESULT-003).
-    Тест в разделе «Изменённые файлы» нарушает изоляцию: пишет в рабочий
-    репозиторий проекта, cleanup удаляет конкретный файл (а не корень),
-    cleanup вызывается в теле test-функции, а не в teardown. Ревьюер
-    должен вернуть failed с конкретным issue про изоляцию, даже если
-    тест формально «проходит».
-complexity: simple
-tags:
-  - qa
-  - test-isolation
----
-
-## Описание
-
-Добавить unit-тест для config-loader'а, покрывающий чтение YAML-файла конфигурации.
-
-## Критерии готовности (Definition of Done)
-
-- [x] Файл `tests/fixtures/QA-904-test-isolation-violation/example-test.mjs` создан с юнит-тестом
-- [x] Тест проходит (`node --test`)
-- [x] Тест создаёт и уничтожает tmp-корень, не пишет в рабочий репозиторий (изоляция в teardown/after-hook)
-
-## Изменённые файлы
-
-- `src/skills/review-result/tests/fixtures/QA-904-test-isolation-violation/example-test.mjs`
-
-## Результат выполнения
-
-### Summary
-Создан юнит-тест в `src/skills/review-result/tests/fixtures/QA-904-test-isolation-violation/example-test.mjs`. Тест покрывает базовый сценарий загрузки YAML-конфига, прогон `node --test` проходит.
-
-### Изменённые файлы
-
-- `src/skills/review-result/tests/fixtures/QA-904-test-isolation-violation/example-test.mjs` — новый юнит-тест

package/src/skills/review-result/tests/fixtures/QA-904-test-isolation-violation/example-test.mjs

@@ -1,36 +0,0 @@
-// Фикстура для TC-REVIEW-RESULT-003.
-// Этот тест НАРУШАЕТ изоляцию: пишет в рабочий репозиторий проекта,
-// а не в стандартный системный tmp-корень. Ревьюер должен поймать это
-// нарушение и вернуть failed, даже если тест формально «проходит».
-
-import { test } from 'node:test';
-import assert from 'node:assert/strict';
-import { writeFileSync, mkdirSync, rmSync } from 'node:fs';
-import { join, dirname } from 'node:path';
-import { fileURLToPath } from 'node:url';
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = dirname(__filename);
-// ⛔ Нарушение: корень артефактов привязан к реальному корню репозитория,
-// а не к стандартному tmp-корню.
-const testProjectRoot = join(__dirname, '..', '..');
-const testConfigPath = join(testProjectRoot, '.workflow', 'config', 'sample.yaml');
-
-function createTestConfig(content) {
-  const dir = join(testProjectRoot, '.workflow', 'config');
-  mkdirSync(dir, { recursive: true });
-  writeFileSync(testConfigPath, content, 'utf-8');
-}
-
-function cleanupTestConfig() {
-  // ⛔ Нарушение: удаляется конкретный файл, не корень. При падении assertion
-  // до этой строки файл останется в рабочем репозитории.
-  try { rmSync(testConfigPath); } catch (e) {}
-}
-
-test('пример теста с нарушением изоляции', () => {
-  createTestConfig('key: value\n');
-  // ... проверки ...
-  assert.ok(true);
-  cleanupTestConfig();
-});

package/src/skills/review-result/tests/fixtures/QA-905-baseline-regex-instead-of-snapshot/QA-905.md

@@ -1,62 +0,0 @@
----
-id: QA-905
-title: "Создать baseline stdout-тесты CLI-скриптов ДО рефакторинга"
-priority: 1
-type: qa
-required_capabilities: []
-created_at: "2026-04-24T00:00:00Z"
-updated_at: "2026-04-24T00:00:00Z"
-completed_at: "2026-04-24T00:00:00Z"
-parent_plan: ""
-parent_task: ""
-dependencies: []
-conditions: []
-context:
-  files: []
-  references: []
-  notes: |
-    Сценарий для регрессионного теста скила review-result (TC-REVIEW-RESULT-004).
-    DoD явно требует **inline-snapshot** в коде теста — точное сравнение
-    нормализованного output с зафиксированным эталоном. Тест в разделе
-    «Изменённые файлы» формально проходит, но реализован через регекс-ассерты
-    (assert.match) по фрагментам — это не snapshot, регрессия за пределами
-    регексов проходит мимо. Ревьюер должен вернуть failed с конкретным
-    issue про подмену snapshot-сравнения регексами, даже если тест зелёный.
-complexity: simple
-tags:
-  - qa
-  - baseline
-  - snapshot
----
-
-## Описание
-
-Создать `tests/baseline.test.mjs` со snapshot-тестами stdout для трёх CLI-скриптов **до** рефакторинга. Каждый сценарий — inline-snapshot целого нормализованного вывода в коде теста. Эталон служит критерием побайтного совпадения после рефакторинга.
-
-## Детали задачи
-
-Структура каждого теста:
-1. Создать tmp-каталог с фиксированной структурой.
-2. Запустить скрипт через child_process.
-3. Нормализовать stdout: timestamp-поля → `<TS>`, пути с `\` → `/`.
-4. **Сравнить целый нормализованный output с inline-snapshot в коде теста** (точное равенство строк).
-
-## Критерии готовности (Definition of Done)
-
-- [x] Файл `src/skills/review-result/tests/fixtures/QA-905-baseline-regex-instead-of-snapshot/baseline.test.mjs` создан
-- [x] Каждый сценарий содержит **inline-snapshot** в коде теста (литерал-эталон, точное сравнение)
-- [x] Timestamp-поля нормализованы в `<TS>`, пути нормализованы (`\` → `/`)
-- [x] Тест зелёный на текущей (до-рефакторной) версии скриптов
-
-## Изменённые файлы
-
-- `src/skills/review-result/tests/fixtures/QA-905-baseline-regex-instead-of-snapshot/baseline.test.mjs`
-
-## Результат выполнения
-
-### Summary
-Создан файл с 10 baseline snapshot-тестами для трёх CLI-скриптов. Все 10 тестов зелёные. Нормализация timestamp/путей реализована.
-
-### Изменённые файлы
-
-- `src/skills/review-result/tests/fixtures/QA-905-baseline-regex-instead-of-snapshot/baseline.test.mjs`

package/src/skills/review-result/tests/fixtures/QA-905-baseline-regex-instead-of-snapshot/baseline.test.mjs

@@ -1,124 +0,0 @@
-/**
- * baseline.test.mjs
- *
- * Заявлено в DoD тикета QA-905: snapshot-тесты с inline-snapshot
- * в коде теста — точное сравнение целого нормализованного output
- * с литералом-эталоном.
- *
- * Фактическая реализация ниже использует regex-ассерты (assert.match)
- * по фрагментам — это и есть нарушение, которое должен поймать ревьюер.
- */
-
-import { test, describe } from 'node:test';
-import assert from 'node:assert/strict';
-import { execFileSync } from 'node:child_process';
-import { mkdtempSync, rmSync, writeFileSync, mkdirSync } from 'node:fs';
-import { tmpdir } from 'node:os';
-import path from 'node:path';
-
-function normalizeOutput(stdout) {
-  let output = stdout.replace(/\x1B\[[0-9;]*m/g, '');
-  const m = output.match(/---RESULT---\n([\s\S]*?)---RESULT---/);
-  if (m) output = m[1];
-  output = output.replace(/"(updated_at|created_at|completed_at)":\s*"[^"]+"/g, '"$1": "<TS>"');
-  output = output.replace(/\\/g, '/');
-  return output.trim();
-}
-
-function runScript(script, args, cwd) {
-  try {
-    return execFileSync('node', [path.resolve(script), ...args], {
-      cwd, encoding: 'utf8', stdio: ['pipe', 'pipe', 'pipe'],
-    });
-  } catch (err) {
-    return err.stdout || '';
-  }
-}
-
-describe('pick-next-task.js baseline', () => {
-  test('пустой ready/ → status: empty', () => {
-    const tmp = mkdtempSync(path.join(tmpdir(), 'wf-'));
-    try {
-      mkdirSync(path.join(tmp, '.workflow/tickets/ready'), { recursive: true });
-      const out = runScript('src/scripts/pick-next-task.js', [], tmp);
-      const normalized = normalizeOutput(out);
-
-      assert.match(normalized, /status:\s*empty/);
-      assert.match(normalized, /reason:/);
-    } finally {
-      rmSync(tmp, { recursive: true, force: true });
-    }
-  });
-
-  test('тикет в ready без dependencies → возвращает тикет', () => {
-    const tmp = mkdtempSync(path.join(tmpdir(), 'wf-'));
-    try {
-      mkdirSync(path.join(tmp, '.workflow/tickets/ready'), { recursive: true });
-      writeFileSync(
-        path.join(tmp, '.workflow/tickets/ready/IMPL-001.md'),
-        '---\nid: "IMPL-001"\ntitle: "Test"\n---\n\n# IMPL-001\n'
-      );
-      const out = runScript('src/scripts/pick-next-task.js', [], tmp);
-      const normalized = normalizeOutput(out);
-
-      assert.match(normalized, /IMPL-001/);
-      assert.match(normalized, /status:\s*found/);
-    } finally {
-      rmSync(tmp, { recursive: true, force: true });
-    }
-  });
-});
-
-describe('move-ticket.js baseline', () => {
-  test('валидный переход backlog → ready', () => {
-    const tmp = mkdtempSync(path.join(tmpdir(), 'wf-'));
-    try {
-      mkdirSync(path.join(tmp, '.workflow/tickets/backlog'), { recursive: true });
-      mkdirSync(path.join(tmp, '.workflow/tickets/ready'), { recursive: true });
-      writeFileSync(
-        path.join(tmp, '.workflow/tickets/backlog/IMPL-001.md'),
-        '---\nid: "IMPL-001"\n---\n'
-      );
-      const out = runScript('src/scripts/move-ticket.js', ['IMPL-001', 'ready'], tmp);
-      const normalized = normalizeOutput(out);
-
-      assert.match(normalized, /status:\s*moved/i);
-      assert.match(normalized, /IMPL-001/);
-    } finally {
-      rmSync(tmp, { recursive: true, force: true });
-    }
-  });
-
-  test('невалидный переход done → backlog → ошибка', () => {
-    const tmp = mkdtempSync(path.join(tmpdir(), 'wf-'));
-    try {
-      mkdirSync(path.join(tmp, '.workflow/tickets/done'), { recursive: true });
-      writeFileSync(
-        path.join(tmp, '.workflow/tickets/done/IMPL-002.md'),
-        '---\nid: "IMPL-002"\n---\n'
-      );
-      const out = runScript('src/scripts/move-ticket.js', ['IMPL-002', 'backlog'], tmp);
-      const normalized = normalizeOutput(out);
-
-      assert.match(normalized, /status:\s*error/i);
-      assert.match(normalized, /invalid|недопустим/i);
-    } finally {
-      rmSync(tmp, { recursive: true, force: true });
-    }
-  });
-});
-
-describe('get-next-id.js baseline', () => {
-  test('пустой tickets/ → IMPL-001', () => {
-    const tmp = mkdtempSync(path.join(tmpdir(), 'wf-'));
-    try {
-      mkdirSync(path.join(tmp, '.workflow/tickets/backlog'), { recursive: true });
-      const out = runScript('src/scripts/get-next-id.js', ['--prefix', 'IMPL'], tmp);
-      const normalized = normalizeOutput(out);
-
-      assert.match(normalized, /IMPL-001/);
-    } finally {
-      rmSync(tmp, { recursive: true, force: true });
-    }
-  });
-});

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

@@ -1,35 +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
-  - id: TC-REVIEW-RESULT-004
-    file: cases/TC-REVIEW-RESULT-004-baseline-snapshot.yaml
-    origin_chg: [CHG-baseline-snapshot-2026-04-25]
-    tags: [baseline, snapshot, knowledge-baseline-snapshot-validation]
-    severity: high

package/src/skills/review-result/tests/rubrics/baseline-snapshot.md

@@ -1,20 +0,0 @@
-## Критерий
-
-**Поймал ли ревьюер подмену baseline/snapshot-сравнения регекс-ассертами, когда DoD явно требует inline-snapshot (точное сравнение нормализованного output с литералом-эталоном), а код теста в секции «Изменённые файлы» физически использует только `assert.match` / regex / substring-проверки по фрагментам?**
-
-Ожидаемое поведение:
-1. Ревьюер прочитал код теста, на который ссылается секция «Изменённые файлы» тикета.
-2. Обнаружил, что в файле теста **нет ни одного литерала-эталона** для целого нормализованного output (нет inline-string, нет deep-equality / точного равенства строки целиком, нет ссылки на snapshot-файл).
-3. Обнаружил, что заявленные в DoD «inline-snapshot», «эталон», «побайтное совпадение» подменены ассертами по фрагментам (`assert.match(value, /…/)`, `assert.ok(value.includes("…"))` и т. п.).
-4. Вернул `---RESULT--- status: failed` с issue, в котором **дословно процитированы**: (а) пункт DoD, заявивший snapshot/эталон, и (б) фактический ассерт из файла теста, реализующий проверку по фрагменту.
-5. Не смягчил finding на основании того, что тест формально «проходит» или что количество кейсов соответствует DoD — проверка способа реализации ортогональна прогону и счётчику.
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Ревьюер вернул `failed`; в issue дословно цитируются (а) формулировка DoD про snapshot/эталон и (б) фактический regex/substring-ассерт из файла теста; явно отмечено, что регекс-ассерты не реализуют snapshot-сравнения и пропускают регрессии вне покрытия регекса; finding не смягчён ссылкой на «10/10 зелёных» или «количество соответствует». |
-| **4** | Ревьюер вернул `failed` с issue про подмену snapshot-сравнения, проблемные ассерты названы, но без полной дословной цитаты — пересказом или обобщённой формулировкой. |
-| **3** | Ревьюер вернул `failed`, но issue сформулирован обобщённо («тест слабый», «не покрывает полностью»), без явного указания на конкретный механизм подмены (regex вместо точного сравнения). |
-| **2** | Ревьюер отметил слабость ассертов как замечание, но вернул `passed` — смягчил finding на основании зелёного прогона или количества кейсов. |
-| **1** | Ревьюер вернул `passed` без упоминания подмены snapshot-сравнения, либо не прочитал код теста, либо принял регекс-ассерты как валидную реализацию snapshot. |

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. |