workflow-ai 1.1.0 → 1.2.1

package/src/skills/create-plan/knowledge/task-verification-pairs.md

@@ -1,151 +0,0 @@
-# Парные задачи верификации
-
-Каждая задача плана, которая изменяет код продукта, должна сопровождаться задачами верификации. Набор парных задач зависит от характера изменения.
-
-## Правило
-
-Если задача плана предполагает **изменение кода продукта** (исправление, доработка, новая функциональность), определи для неё необходимые задачи верификации:
-
-1. **Актуализация автотестов** (обязательна всегда) — добавление или обновление unit/integration-тестов, покрывающих изменённое поведение
-2. **Ручная проверка** (если изменение наблюдаемо пользователем) — тестировщик вручную проверяет исправление по шагам воспроизведения или acceptance criteria
-
-## Определение набора парных задач
-
-Для каждой задачи, изменяющей код, архитектор определяет какие верификационные задачи нужны, задавая два вопроса:
-
-1. **Может ли пользователь заметить изменение?** (видимый эффект в UI, поведении, выводе) → если да, нужна **ручная проверка**
-2. **Можно ли покрыть изменение автоматическим тестом?** (есть вход/выход, поведение формализуемо) → если да, нужна **актуализация автотестов**
-
-| Ответы на вопросы | Автотесты | Ручная проверка |
-|---|---|---|
-| Пользователь заметит + можно покрыть тестом | Да | Да |
-| Пользователь заметит + нельзя покрыть тестом (чисто визуальное) | Нет | Да |
-| Пользователь не заметит + можно покрыть тестом | Да | Нет |
-| Пользователь не заметит + нельзя покрыть тестом | Обосновать в плане, почему верификация не нужна |
-
-Если не очевидно — включай обе задачи (лучше проверить лишний раз).
-
-## Структура группы задач
-
-```
-# Полная группа (изменение с наблюдаемым эффектом):
-Задача N:   Изменение кода (исполнитель: agent)
-Задача N+1: Ручная проверка задачи N (исполнитель: agent, зависимость: задача N)
-Задача N+2: Актуализация автотестов для задачи N (исполнитель: agent, зависимость: задача N)
-
-# Сокращённая группа (внутреннее изменение без UI-эффекта):
-Задача N:   Изменение кода (исполнитель: agent)
-Задача N+1: Актуализация автотестов для задачи N (исполнитель: agent, зависимость: задача N)
-```
-
-## Когда применять
-
-- **Применяется:** задача изменяет исходный код продукта (логику, UI, стили, конфигурацию продукта)
-- **НЕ применяется:** задача изменяет только документацию, тестовые утилиты (mock, test helpers), workflow-артефакты, или является чисто исследовательской
-
-## Исключения
-
-Объединение ручных проверок нескольких задач в одну сводную задачу **по умолчанию запрещено**. Каждая задача изменения кода с наблюдаемым эффектом получает **свою** парную задачу ручной проверки рядом — не в конце плана.
-
-**Когда сводная задача допустима** (все условия одновременно):
-1. Объединяемые задачи изменяют **один и тот же UI-объект** (одна view, один компонент, один экран) — а не несколько независимых областей продукта
-2. Каждая отдельная проверка тривиальна (1-2 шага) — иначе сводный сценарий распухает и теряет фокус
-3. В плане **явно перечислены** ID объединяемых задач и обоснование, почему раздельная проверка избыточна
-
-**Антипаттерн:** одна задача «Ручная проверка задач 1-7» в конце плана, охватывающая разные UI-области. Это не сводная проверка — это пропуск парных задач. Декомпозитор не сможет создать корректные парные тикеты, верификация теряет связь с исходной задачей, ревью затрудняется.
-
-## Self-check перед сохранением плана
-
-Перед записью файла плана пройди по списку задач и для **каждой** задачи, изменяющей код продукта с наблюдаемым эффектом, ответь:
-
-1. Есть ли рядом с этой задачей парная задача ручной проверки именно для неё?
-2. Если ручная проверка вынесена в сводную задачу — выполнены ли все три условия из секции «Исключения»?
-3. Если не выполнены — разбей сводную задачу на парные и помести каждую рядом с её основной задачей.
-
-Если задача изменения кода найдена без парной ручной проверки и без обоснованного исключения — план **не готов к сохранению**.
-
-## Data assertions в QA-задачах
-
-Каждый тест-кейс в QA-задаче плана должен содержать **ожидаемое значение**, а не только ожидаемое наличие элемента.
-
-### Правило
-
-Вместо «компонент X находится в состоянии Y» → «компонент X показывает конкретное значение `Z`».
-
-### Критерий применения
-
-Задай вопрос: **«Может ли значение измениться между запусками или зависит от входных данных?»**
-
-| Ответ | Тип данных | Примеры | Нужен data assertion |
-|-------|-----------|---------|----------------------|
-| Да | Динамические: счётчики, имена, время, параметризованные статусы | «Прогресс: 3 из 5» | ✅ Да |
-| Нет | Статические: иконки, фиксированные подписи, кнопки | «Кнопка «Открыть» видна» | ❌ Нет |
-
-### Примеры переформулировки
-
-| Слабое (только наличие) | Сильное (data assertion) |
-|-------------------------|--------------------------|
-| «Статус-строка показывает Running» | «Статус-строка показывает `Running \| <имя текущего шага>`» |
-| «История содержит записи» | «История содержит N записей, каждая с временем > 0s» |
-
-### Ограничения
-
-- Не требуй data assertion для непредсказуемых значений (случайные ID, временны́е метки с миллисекундной точностью) — в таких случаях проверяй формат: «timestamp соответствует паттерну `ISO 8601`»
-- Одна проверка значения на ключевой динамический элемент достаточна — не раздувай тест-кейс
-
-<!-- РАСШИРЕНИЕ: добавляй уточнения и исключения ниже -->
-
-## Entry points и config variations в QA-задачах
-
-При создании QA-задачи для функции/команды необходимо перечислить ВСЕ способы её вызова и все конфигурации, влияющие на поведение.
-
-### Правило
-
-Для каждой тестируемой функции/команды выполни 4 шага:
-
-1. **Определи все entry points** — изучи проектный манифест (конфиг, декларацию расширения/плагина) и код, чтобы найти ВСЕ точки входа (меню, сочетания клавиш, inline UI, контекстное меню, программный API). Каждый entry point — потенциально отдельный TC.
-
-2. **Покрой каждый entry point TC-ом** — не ограничивайся «основным» способом запуска. Функция считается протестированной только если каждый задекларированный entry point проверен отдельно.
-
-3. **Определи config variations** — найди все конфигурационные параметры, влияющие на поведение функции: допустимые значения, граничные значения, отсутствие опциональных параметров. Каждая значимая вариация — отдельный TC или параметризованный шаг.
-
-4. **Добавь persistence TC для stateful-функций** — если функция сохраняет данные (история, кэш, настройки), включи TC: данные сохраняются после перезапуска приложения и корректно накапливаются при повторных запусках.
-
-### Критерий применения
-
-Задай вопрос: **«Может ли пользователь вызвать эту функцию более чем одним способом?»**
-
-| Ответ | Действие |
-|-------|----------|
-| Да | Перечислить все entry points, добавить TC на каждый |
-| Нет | Один TC на единственный entry point |
-
-И: **«Зависит ли поведение от конфигурации или сохраняет ли функция данные между сессиями?»**
-
-| Ответ | Действие |
-|-------|----------|
-| Да, конфиг влияет | TC для каждого значения/варианта, влияющего на поведение |
-| Да, данные сохраняются | TC на persistence и накопление |
-| Нет | Конфигурационные и persistence TC не нужны |
-
-### Пример структуры анализа entry points (абстрактный)
-
-```
-Функция: «Запустить проверку»
-
-Entry points (из манифеста и кода):
-  [ ] Главное меню → «App: Run Check»
-  [ ] Клавиатурное сочетание → Ctrl+Shift+R
-  [ ] Контекстное меню → правый клик → «Run Check»
-  [ ] Inline-кнопка → иконка ▶ в строке элемента
-  [ ] Программный API → app.runCheck()
-
-Config variations:
-  [ ] mode = fast (по умолчанию)
-  [ ] mode = full
-  [ ] mode отсутствует (edge case)
-
-Persistence (если stateful):
-  [ ] История запусков сохраняется после перезапуска
-  [ ] Накопление: N запусков → N записей в истории
-```

package/src/skills/create-plan/knowledge/test-hygiene.md

@@ -1,47 +0,0 @@
-# Изоляция тестов в плане
-
-Когда план содержит задачи на создание/правку автотестов, в **описании** задачи и в её DoD должно быть зафиксировано требование: **тест не пишет артефакты (файлы, директории, конфиги, БД) в рабочий репозиторий или в общие системные пути**. Все файловые операции теста — во временной директории, создаваемой стандартной библиотекой языка.
-
-## Зачем
-
-Тесты, которые пишут в рабочий репозиторий:
-- затирают файлы, нужные параллельно выполняющимся задачам/агентам проекта;
-- оставляют "призрачный" state при прерывании (Ctrl+C, краш, таймаут) — следующий прогон подхватывает оставленные данные как настоящие и даёт ложный результат;
-- делают тесты зависимыми от чистоты CWD — то же поведение на машине разработчика и в CI отличается;
-- провоцируют ложные вердикты механических проверок, завязанных на mtime/наличие файлов (verify-artifacts, git-status-снапшоты);
-- могут случайно коммититься в историю, если test-runner создал файл в tracked-директории.
-
-## Критерий проверки для плана
-
-Каждая задача, результат которой — тестовый файл или правка тестового файла, должна явно описывать **корень изоляции**. Варианты:
-
-| Источник корня | Когда подходит |
-|----------------|----------------|
-| Стандартный системный tmp языка | Тест создаёт одноразовое окружение на прогон (самое частое) |
-| Специально выделенная fixtures-директория теста | Неизменяемые шаблонные данные, read-only |
-| Изолированный git-worktree | Тест проверяет поведение на полноценной копии репо |
-| Иной способ изоляции | Явно обоснован в плане: почему перечисленных выше недостаточно |
-
-Если задача не попадает ни в один вариант — план должен явно обосновать, почему этот тест имеет право писать в рабочий репозиторий (например, тест-генератор, который коммитится в репо как артефакт).
-
-**Конкретное имя функции стандартной библиотеки — на стороне исполнителя**, не на стороне плана. План фиксирует требование, не реализацию.
-
-## Что фиксировать в задаче плана
-
-- **Корень изоляции** — один из вариантов из таблицы выше (или явно обоснованный иной).
-- **Гарантия очистки** — тест обязан удалять созданный корень при любом исходе, включая падение assertion (teardown/after-hook, а не ad-hoc cleanup в конце test-функции).
-- **Антипаттерн** — явный запрет на запись в реальные каталоги проекта (любые config-, data-, state-, cache-каталоги внутри корня репозитория).
-
-## Что фиксировать в DoD
-
-- Пункт DoD явно требует изолированный корень (формулировка вроде «тест создаёт и уничтожает tmp-корень, не пишет в рабочий репозиторий»).
-- При наличии соседних тестовых файлов в модуле — пункт DoD требует сверки с уже принятым в проекте паттерном изоляции (не изобретать новый способ).
-
-## Self-check при создании плана
-
-Перед сохранением плана ответь себе по каждой задаче, результат которой связан с тестами:
-1. Указан ли корень изоляции в описании задачи?
-2. Зафиксирован ли teardown в DoD?
-3. Есть ли в проекте уже принятый паттерн изоляции, и задача ссылается на него?
-
-Если хотя бы на один вопрос "нет" — задача недооформлена.

package/src/skills/create-plan/scripts/validate-completeness.js

@@ -1,182 +0,0 @@
-#!/usr/bin/env node
-
-/**
- * validate-completeness.js — валидация полноты плана по чеклисту из plan-completeness.md
- *
- * Использование:
- *   node validate-completeness.js <path-to-plan>
- *
- * Проверяет:
- * - Обязательные поля frontmatter (id, title, status, author, created_at)
- * - Обязательные секции (# Цель, ## Контекст, ## Справочные данные, ## Scope, ## Высокоуровневые задачи, ## Риски, ## Критерии успеха)
- * - Красные флаги (отсылки вместо содержания, пустые секции)
- *
- * Вывод: JSON {errors, warnings, valid} через ---RESULT---
- */
-
-import fs from 'fs';
-import path from 'path';
-import { findProjectRoot } from 'workflow-ai/lib/find-root.mjs';
-import { printResult } from 'workflow-ai/lib/utils.mjs';
-
-const REQUIRED_FRONTMATTER_FIELDS = ['id', 'title', 'status', 'author', 'created_at'];
-
-const REQUIRED_SECTIONS = [
-  '# Цель',
-  '## Контекст',
-  '## Справочные данные',
-  '## Scope',
-  '## Высокоуровневые задачи',
-  '## Риски',
-  '## Критерии успеха'
-];
-
-const RED_FLAG_PATTERNS = [
-  { pattern: /см\.\s*ТЗ|по ссылке|см\.\s*документацию|описано в спецификации/gi, message: 'Отсылка к внешнему документу вместо содержания' },
-  { pattern: /URL[а-яё]*\s*(уже создан|создан|получен)|credentials\s*(настроены|получены|готовы)/gi, message: 'Значение не указано (только упоминание)' },
-  { pattern: /^#\s*.+\n\n+$/gm, message: 'Пустая секция (только заголовок без содержания)', isEmptySection: true }
-];
-
-function parseArgs() {
-  const args = process.argv.slice(2);
-  if (args.length === 0) {
-    console.error('Ошибка: не указан путь к файлу плана');
-    console.error('Использование: node validate-completeness.js <path-to-plan>');
-    process.exit(1);
-  }
-  return args[0];
-}
-
-function parseFrontmatter(content) {
-  const fmMatch = content.match(/^---\n([\s\S]*?)\n---/);
-  if (!fmMatch) {
-    return { raw: null, data: null };
-  }
-
-  const fmContent = fmMatch[1];
-  const data = {};
-
-  const lines = fmContent.split('\n');
-  for (const line of lines) {
-    const colonIdx = line.indexOf(':');
-    if (colonIdx === -1) continue;
-
-    const key = line.slice(0, colonIdx).trim();
-    let value = line.slice(colonIdx + 1).trim();
-
-    if (value.startsWith('"') && value.endsWith('"')) {
-      value = value.slice(1, -1);
-    } else if (value.startsWith("'") && value.endsWith("'")) {
-      value = value.slice(1, -1);
-    }
-
-    data[key] = value;
-  }
-
-  return { raw: fmMatch[0], data };
-}
-
-function checkFrontmatter(fm) {
-  const errors = [];
-
-  if (!fm || !fm.data) {
-    errors.push({ field: 'frontmatter', message: 'Frontmatter отсутствует' });
-    return errors;
-  }
-
-  for (const field of REQUIRED_FRONTMATTER_FIELDS) {
-    if (!fm.data[field]) {
-      errors.push({ field, message: `Обязательное поле "${field}" отсутствует` });
-    }
-  }
-
-  return errors;
-}
-
-function checkSections(content) {
-  const errors = [];
-  const lines = content.split('\n');
-
-  for (const section of REQUIRED_SECTIONS) {
-    const sectionPattern = section.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
-    const regex = new RegExp(sectionPattern, 'i');
-
-    if (!regex.test(content)) {
-      errors.push({ section, message: `Секция "${section}" отсутствует` });
-    }
-  }
-
-  return errors;
-}
-
-function checkRedFlags(content) {
-  const warnings = [];
-  const lines = content.split('\n');
-
-  for (const { pattern, message, isEmptySection } of RED_FLAG_PATTERNS) {
-    if (isEmptySection) {
-      const matches = content.match(/^#+\s+.+$/gm);
-      if (matches) {
-        for (const heading of matches) {
-          const headingLineNum = content.split('\n').findIndex(l => l.trim() === heading.trim());
-          if (headingLineNum !== -1) {
-            const nextLine = lines[headingLineNum + 1];
-            if (!nextLine || !nextLine.trim()) {
-              warnings.push({ pattern: heading, message: `Пустая секция: ${heading}` });
-            }
-          }
-        }
-      }
-    } else {
-      const matches = content.match(pattern);
-      if (matches) {
-        for (const match of matches) {
-          warnings.push({ pattern: match.slice(0, 50), message });
-        }
-      }
-    }
-  }
-
-  return warnings;
-}
-
-function validatePlan(planPath) {
-  const errors = [];
-  const warnings = [];
-
-  if (!fs.existsSync(planPath)) {
-    errors.push({ file: planPath, message: 'Файл не существует' });
-    return { errors, warnings, valid: false };
-  }
-
-  const content = fs.readFileSync(planPath, 'utf-8');
-
-  const fmErrors = checkFrontmatter(parseFrontmatter(content));
-  errors.push(...fmErrors);
-
-  const sectionErrors = checkSections(content);
-  errors.push(...sectionErrors);
-
-  const redFlagWarnings = checkRedFlags(content);
-  warnings.push(...redFlagWarnings);
-
-  const valid = errors.length === 0;
-
-  return { errors, warnings, valid };
-}
-
-function main() {
-  const planPath = parseArgs();
-
-  const absolutePath = path.isAbsolute(planPath)
-    ? planPath
-    : path.resolve(process.cwd(), planPath);
-
-  const result = validatePlan(absolutePath);
-
-  console.log('---RESULT---');
-  console.log(JSON.stringify(result, null, 2));
-  console.log('---RESULT---');
-}
-
-main();

package/src/skills/create-plan/tests/cases/TC-CREATE-PLAN-001/current/claude-sonnet/trial-1.md

@@ -1,5 +0,0 @@
-# TRIAL ERRORED
-
-agent: claude-sonnet
-trial: 1
-error: Stage "TC-CREATE-PLAN-001-claude-sonnet-trial-1" timed out after 1200s

package/src/skills/create-plan/tests/cases/TC-CREATE-PLAN-001/current/claude-sonnet/trial-2.md

@@ -1,39 +0,0 @@
-`valid: true`, errors пусты. Предупреждения о "пустых секциях" — артефакт валидатора, который проверяет следующую строку после заголовка: в markdown принято оставлять пустую строку после `##`. Эти предупреждения некритичны (они есть в любом корректно отформатированном Markdown-файле).
-
-Финальный план сохранён:
-
-`.workflow/plans/current/PLAN-001.md`
-
----
-
-## PLAN-001: Добавить тёмную тему в приложение
-
-**Статус:** `draft`
-
-### Что сделано
-
-**Цель (SMART):** реализовать переключение light/dark-темы с сохранением выбора в `localStorage` без перезагрузки страницы, подтверждённое ручной проверкой и автотестами.
-
-**Справочные данные зафиксированы:** ключ localStorage — `app-theme`, атрибут — `data-theme`, дефолт — `light`, файл токенов — `src/styles/tokens.css`.
-
-**13 задач** с парными задачами верификации:
-
-| Задача | Тип |
-|--------|-----|
-| 1. Аудировать цветовую схему | Исследование |
-| 2. Создать CSS-токены light/dark | Реализация |
-| 2.1. Ручная проверка токенов | Верификация |
-| 3. Заменить хардкод-цвета на CSS-переменные | Реализация |
-| 3.1. Ручная проверка регрессии светлой темы | Верификация |
-| 3.2. Актуализировать автотесты | Верификация |
-| 4. Создать компонент ThemeToggle | Реализация |
-| 4.1. Ручная проверка переключателя | Верификация |
-| 4.2. Автотесты ThemeToggle | Верификация |
-| 5. Логика переключения + localStorage | Реализация |
-| 5.1–5.2. Ручная проверка + автотесты | Верификация |
-| 6. Инициализация темы при старте | Реализация |
-| 6.1–6.2. Ручная проверка + автотесты | Верификация |
-| 7. Совместимость иконок/изображений | Реализация |
-| 7.1. Ручная проверка иконок | Верификация |
-
-**4 риска** оценены по матрице (MEDIUM×2, HIGH×1, MEDIUM×1) с митигацией.

package/src/skills/create-plan/tests/cases/TC-CREATE-PLAN-001/current/claude-sonnet/trial-3.md

@@ -1,35 +0,0 @@
-Валидация прошла: `valid: true`. Предупреждения о "пустых секциях" — ложные срабатывания скрипта (он проверяет только следующую строку после заголовка, а стандартный Markdown предполагает пустую строку между заголовком и контентом). Все секции плана содержат содержательный текст.
-
----
-
-План создан: **`.workflow/plans/current/PLAN-001.md`**
-
-## Что сделано
-
-**SMART-цель:** к 2026-04-27 пользователь может переключать light/dark тему через кнопку в Header, выбор сохраняется между сессиями, все основные компоненты корректно стилизованы.
-
-**Справочные данные** содержат:
-- Полные CSS design tokens (14 переменных для обеих тем)
-- localStorage-схему (ключ `theme`, допустимые значения)
-- Алгоритм инициализации с fallback на `prefers-color-scheme`
-- Таблицу иконок и aria-label для ThemeToggle
-
-**15 задач** — атомарные, одно действие на задачу:
-
-| Задачи | Тип |
-|--------|-----|
-| 1 | Аудит хардкодных цветов (исследование) |
-| 2 | CSS custom properties → global.css |
-| 3–4 | Ручная проверка + автотесты для задачи 2 |
-| 5 | ThemeContext с `data-theme` на `<html>` |
-| 6–7 | Ручная проверка + автотесты для задачи 5 |
-| 8 | Сохранение темы в localStorage |
-| 9–10 | Ручная проверка + автотесты для задачи 8 |
-| 11 | Компонент ThemeToggle |
-| 12 | Интеграция ThemeToggle в Header |
-| 13 | Сводная ручная проверка задач 11+12 |
-| 14–15 | Автотесты для задач 11 и 12 |
-
-**5 рисков** с митигацией (2× HIGH: хардкодные цвета и CSS-in-JS стек).
-
-**Статус:** `draft` — ожидает утверждения стейкхолдером.

package/src/skills/create-plan/tests/cases/TC-CREATE-PLAN-001/current/judge.json

@@ -1,167 +0,0 @@
-{
-  "per_model": {
-    "claude-sonnet": {
-      "pass_count": 0,
-      "total": 3,
-      "trials": [
-        {
-          "trial": 1,
-          "score": null,
-          "passed": false
-        },
-        {
-          "trial": 2,
-          "score": 2,
-          "passed": false
-        },
-        {
-          "trial": 3,
-          "score": 3,
-          "passed": false
-        }
-      ]
-    },
-    "kilo-glm": {
-      "pass_count": 2,
-      "total": 3,
-      "trials": [
-        {
-          "trial": 1,
-          "score": 4,
-          "passed": true
-        },
-        {
-          "trial": 2,
-          "score": 5,
-          "passed": true
-        },
-        {
-          "trial": 3,
-          "score": null,
-          "passed": false
-        }
-      ]
-    },
-    "kilo-minimax": {
-      "pass_count": 0,
-      "total": 3,
-      "trials": [
-        {
-          "trial": 1,
-          "score": 2,
-          "passed": false
-        },
-        {
-          "trial": 2,
-          "score": 3,
-          "passed": false
-        },
-        {
-          "trial": 3,
-          "score": 3,
-          "passed": false
-        }
-      ]
-    },
-    "kilo-deepseek": {
-      "pass_count": 0,
-      "total": 3,
-      "trials": [
-        {
-          "trial": 1,
-          "score": null,
-          "passed": false
-        },
-        {
-          "trial": 2,
-          "score": 2,
-          "passed": false
-        },
-        {
-          "trial": 3,
-          "score": null,
-          "passed": false
-        }
-      ]
-    }
-  },
-  "rubric_scores": [
-    {
-      "agentId": "claude-sonnet",
-      "trial": 1,
-      "score": null,
-      "errored": true,
-      "error": "Stage \"TC-CREATE-PLAN-001-claude-sonnet-trial-1\" timed out after 1200s"
-    },
-    {
-      "agentId": "claude-sonnet",
-      "trial": 2,
-      "score": 2,
-      "errored": false
-    },
-    {
-      "agentId": "claude-sonnet",
-      "trial": 3,
-      "score": 3,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-deepseek",
-      "trial": 1,
-      "score": null,
-      "errored": true,
-      "error": "Stage \"TC-CREATE-PLAN-001-kilo-deepseek-trial-1\" timed out after 1200s"
-    },
-    {
-      "agentId": "kilo-deepseek",
-      "trial": 2,
-      "score": 2,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-deepseek",
-      "trial": 3,
-      "score": null,
-      "errored": true,
-      "error": "Stage \"TC-CREATE-PLAN-001-kilo-deepseek-trial-3\" timed out after 1200s"
-    },
-    {
-      "agentId": "kilo-glm",
-      "trial": 1,
-      "score": 4,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm",
-      "trial": 2,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm",
-      "trial": 3,
-      "score": null,
-      "errored": true,
-      "error": "Stage \"TC-CREATE-PLAN-001-kilo-glm-trial-3\" timed out after 1200s"
-    },
-    {
-      "agentId": "kilo-minimax",
-      "trial": 1,
-      "score": 2,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-minimax",
-      "trial": 2,
-      "score": 3,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-minimax",
-      "trial": 3,
-      "score": 3,
-      "errored": false
-    }
-  ],
-  "timestamp": "2026-04-20T12:04:59.082Z"
-}

package/src/skills/create-plan/tests/cases/TC-CREATE-PLAN-001/current/kilo-deepseek/trial-1.md

@@ -1,5 +0,0 @@
-# TRIAL ERRORED
-
-agent: kilo-deepseek
-trial: 1
-error: Stage "TC-CREATE-PLAN-001-kilo-deepseek-trial-1" timed out after 1200s

package/src/skills/create-plan/tests/cases/TC-CREATE-PLAN-001/current/kilo-deepseek/trial-2.md

@@ -1,10 +0,0 @@
-План создан и сохранён в `.workflow/plans/current/PLAN-001.md`.
-
-**Ключевые элементы плана:**
-- Цель: реализация тёмной темы с переключением без перезагрузки
-- Справочные данные: цветовые палитры для светлой и тёмной тем
-- Scope: включено переключение темы, обновление стилей, сохранение в localStorage; исключена системная тема и кастомизация
-- 10 задач с парной верификацией (ручные проверки и автотесты для каждой задачи изменения кода)
-- Риски и митигация, критерии успеха
-
-План имеет статус `draft` и готов к утверждению стейкхолдером перед декомпозицией.

package/src/skills/create-plan/tests/cases/TC-CREATE-PLAN-001/current/kilo-deepseek/trial-3.md

@@ -1,5 +0,0 @@
-# TRIAL ERRORED
-
-agent: kilo-deepseek
-trial: 3
-error: Stage "TC-CREATE-PLAN-001-kilo-deepseek-trial-3" timed out after 1200s