workflow-ai 1.0.68 → 1.2.1

package/src/skills/analyze-report/tests/cases/TC-ANALYZE-REPORT-001/current/kilo-glm/trial-1.md

@@ -1,77 +0,0 @@
-Now I have all the context. Let me produce the analysis.
-
----
-
-# Анализ: Прогресс PLAN-001
-
-**Дата анализа:** 2026-04-20
-**Анализируемый план:** PLAN-001
-**Анализируемый отчёт:** REPORT-002
-**Тип анализа:** PROGRESS
-
----
-
-## Executive Summary
-
-При верификации REPORT-002 по логу пайплайна обнаружена **некорректная атрибуция** root cause пропуска тикета QA-001. Предыдущий отчёт возложил вину на стейдж проверки условий, однако лог однозначно показывает, что решение о пропуске принял стейдж `check-relevance` (строка 26 лога: `status="irrelevant"`, `reason="dependencies_inactive"`). Требуется исправление логики релевантности и корректировка отчёта.
-
----
-
-## Ключевые находки
-
-### 1. Некорректная атрибуция root cause в REPORT-002
-**Уверенность:** [HIGH]
-**Данные из лога:**
-
-| Шаг | Стейдж | Скрипт | Результат | Строка лога |
-|-----|--------|--------|-----------|-------------|
-| 313 | `check-conditions` | `check-conditions.js` | `conditions_ok` (dependencies.resolved=true, prerequisites.met=true, blocking_tickets=[]) | 16–17 |
-| **314** | **`check-relevance`** | **`check-relevance.js`** | **`irrelevant` (dependencies.status=inactive, reason=dependencies_inactive)** | **26** |
-| 315 | `skip-ticket` | `script-skip` | `skipped` (reason from check-relevance: dependencies_inactive) | 31 |
-
-Стейдж проверки условий **успешно пропустил** тикет дальше (result=`conditions_ok`). Итоговое решение `irrelevant` принял стейдж `check-relevance`. Атрибуция в REPORT-002 ошибочна.
-
-### 2. Противоречие между стейджами
-**Уверенность:** [HIGH]
-**Данные:** `check-conditions` зафиксировал `dependencies.resolved: true` (строка 13), а `check-relevance` — `dependencies.status: inactive` (строка 24). Оба стейджа проверяют зависимости, но получают разные результаты. Вероятно, стейджи используют разные источники данных или разные критерии оценки зависимостей.
-
----
-
-## Проблемы и риски
-
-| # | Проблема | Серьёзность | Данные из лога | Рекомендация |
-|---|---------|-------------|----------------|-------------|
-| 1 | `check-relevance.js` ошибочно признал QA-001 нерелевантным при разрешённых зависимостях | HIGH | Стр. 24: `dependencies.status: inactive` при `dependencies.resolved: true` (стр. 13) | Исправить логику `check-relevance.js`: синхронизировать проверку статуса зависимостей с `check-conditions` |
-| 2 | Расхождение данных о зависимостях между стейджами | HIGH | `resolved: true` vs `status: inactive` для одних и тех же зависимостей | Унифицировать источник данных о зависимостях между стейджами |
-| 3 | Некорректная атрибуция в предыдущем отчёте | MEDIUM | REPORT-002 называет неверный root cause | Исправить REPORT-002: указать `check-relevance.js` как источник решения о skip |
-
----
-
-## Рекомендации
-
-| # | Действие | Приоритет | Почему | Ожидаемый результат |
-|---|---------|-----------|--------|-------------------|
-| 1 | Исправить логику оценки зависимостей в `check-relevance.js` — сверять `dependencies.resolved` с результатом `check-conditions` | CRITICAL | Стейдж проигнорировал `resolved=true` и принял решение по `status=inactive` | QA-001 и аналогичные тикеты не пропускаются ошибочно |
-| 2 | Унифицировать источник данных о зависимостях между стейджами `check-conditions` и `check-relevance` | HIGH | Противоречивые данные для одного тикета (стр. 13 vs стр. 24) | Единая картина состояния зависимостей |
-| 3 | Добавить кросс-валидацию: если `check-conditions` вернул `conditions_ok`, `check-relevance` не должен пропускать по тем же зависимостям | HIGH | Предотвращение противоречивых решений в рамках одного пайплайна | Исключение ситуации, когда один стейдж одобряет, а следующий — отклоняет по тому же критерию |
-
----
-
-## За пределами скоупа
-
-- Причины, по которым `dependencies.status` стал `inactive` — требуется анализ данных тикета QA-001 и его зависимостей, что выходит за рамки анализа лога.
-
----
-
-## Решение
-
-**Статус плана:** AT_RISK — тикет QA-001 ошибочно пропущен из-за бага в `check-relevance.js`, требуется исправление до следующей итерации.
-**Рекомендуемое действие:** скорректировать — исправить `check-relevance.js` и перезапустить QA-001.
-
----
-
----RESULT---
-status: has_gaps
-report_id: REPORT-002
-gaps: "Тикет QA-001 ошибочно пропущен стейджем check-relevance (атрибут dependencies.status=inactive при dependencies.resolved=true). Некорректная атрибуция в предыдущем отчёте исправлена: root cause — check-relevance.js, а не check-conditions.js."
----RESULT---

package/src/skills/analyze-report/tests/cases/TC-ANALYZE-REPORT-001/current/kilo-glm/trial-2.md

@@ -1,64 +0,0 @@
-# REPORT-002 (исправленный) — Верификация атрибуции root cause для QA-001
-
-**Дата:** 2026-04-06  
-**План:** PLAN-001  
-**Источник:** верификация REPORT-002 по логу `pipeline-2026-04-06_qa-001-skip.log`
-
-## Executive Summary
-
-Предыдущий отчёт REPORT-002 неверно атрибутировал root cause пропуска QA-001 стейджу `check-conditions.js`. Верификация по логу пайплайна однозначно показывает: стейдж `check-conditions` отработал корректно (`conditions_ok`), а решение о skip принято стейджем `check-relevance` на основании признака `dependencies.status: inactive`. Корректный root cause — `check-relevance.js`.
-
-## Верификация по логу (пошаговая)
-
-| Step | Стейдж | Результат | Вклад в skip |
-|------|--------|-----------|-------------|
-| 313 | `check-conditions` | `conditions_ok` (deps resolved: true, prerequisites met: true) | **Нет** — пропустил тикет дальше |
-| 314 | `check-relevance` | `irrelevant` (reason: `dependencies_inactive`) | **Да** — принял решение о нерелевантности |
-| 315 | `skip-ticket` | `skipped` (reason from check-relevance: `dependencies_inactive`) | Исполнитель решения step 314 |
-
-### Ключевое противоречие в отчёте
-
-REPORT-002 утверждает: _«`check-conditions.js` — стейдж неверно определил, что условия запуска не выполнены»_. Лог показывает обратное: `check-conditions` определил условия **выполненными** и передал тикет дальше. Стейдж `check-relevance` — это совершенно отдельный стейдж, который проверяет **актуальность** (relevance), а не условия запуска.
-
-**Природа ошибки в REPORT-002:** смешение двух разных стейджей — `check-conditions` (условия запуска) и `check-relevance` (актуальность тикета). Решение принял `check-relevance`.
-
-## Исправленные находки
-
-### QA-001 — тикет ошибочно пропущен
-
-| Поле | Было в REPORT-002 | Исправлено по логу |
-|------|-------------------|--------------------|
-| **Root cause** | `check-conditions.js` | **`check-relevance.js`** `[HIGH]` |
-| **Механизм** | Неверно определены условия запуска | Стейдж `check-relevance` определил `dependencies.status: inactive`, хотя `check-conditions` зафиксировал `dependencies.resolved: true` |
-| **Затронутые компоненты** | `check-conditions.js` | **`check-relevance.js`**, источник данных о статусе зависимостей |
-| **Приоритет** | HIGH | HIGH |
-
-### Дополнительная находка: рассогласование данных
-
-Между стейджами `check-conditions` и `check-relevance` зафиксировано **противоречивое состояние зависимостей**:
-
-- `check-conditions` (step 313): `dependencies.resolved: true`
-- `check-relevance` (step 314): `dependencies.status: inactive`
-
-Оба стейджа запрашивают статус зависимостей, но получают **разные результаты**. Возможные причины: разные источники данных, кэширование, race condition. Уровень уверенности: `[MEDIUM]` — требуется дополнительное расследование.
-
-## Исправленные рекомендации
-
-| # | Действие | Приоритет | Обоснование |
-|---|----------|-----------|-------------|
-| 1 | Пересмотреть логику проверки `dependencies.status` в **`check-relevance.js`** — почему статус `inactive` при `resolved: true` | **CRITICAL** | Именно этот стейдж принял ошибочное решение о skip |
-| 2 | Унифицировать источник данных о зависимостях между `check-conditions` и `check-relevance` | **HIGH** | Рассогласование данных между стейджами — системная проблема |
-| 3 | Добавить cross-check: если `check-conditions` дал `conditions_ok`, а `check-relevance` — `irrelevant` по зависимостям, логировать warning | **MEDIUM** | Раннее обнаружение рассогласований |
-
-## За пределами скоупа
-
-- Почему `dependencies.status` вернул `inactive` в `check-relevance` — требует доступа к состоянию зависимостей тикета на момент итерации.
-- Были ли другие тикеты с аналогичной проблемой в этой итерации — требует полного лога.
-
----
-
----RESULT---
-status: has_gaps
-report_id: REPORT-002
-gaps: "Root cause пропуска QA-001 неверно атрибутирован в REPORT-002: виновен check-relevance.js, а не check-conditions.js. Обнаружено рассогласование данных о зависимостях между стейджами. Требуется исправление логики check-relevance.js и унификация источника данных."
----RESULT---

package/src/skills/analyze-report/tests/cases/TC-ANALYZE-REPORT-001/current/kilo-glm/trial-3.md

@@ -1,110 +0,0 @@
-Данные загружены. Теперь я провожу верификацию по логу пайплайна и формирую отчёт анализа.
-
-# Анализ: PROGRESS
-
-**Дата анализа:** 2026-04-20
-**Анализируемый план:** PLAN-001
-**Анализируемый отчёт:** REPORT-002
-**Тип анализа:** PROGRESS
-
----
-
-## Executive Summary
-
-Отчёт REPORT-002 содержит **неверную атрибуцию** root cause пропуска тикета QA-001. Стейдж `check-conditions` корректно пропустил тикет дальше (status=`conditions_ok`), а решение о skip принял стейдж `check-relevance` (reason=`dependencies_inactive`). Также обнаружено противоречие между оценками двух стейджей: `check-conditions` считает зависимости разрешёнными, а `check-relevance` — неактивными. Требуется исправление отчёта и диагностика расхождения в логике стейджей.
-
----
-
-## Метрики
-
-Данные для количественных метрик ограничены — лог содержит только траекторию одного тикета (QA-001). Метрики рассчитаны на основе доступных данных.
-
-| Метрика | Значение | Статус |
-|---------|----------|--------|
-| Тикетов в логе | 1 (QA-001) | — |
-| Успешно обработано | 0 | 🔴 |
-| Пропущено (skipped) | 1 | 🔴 |
-| Неверная атрибуция в отчёте | 1 finding | 🔴 |
-
----
-
-## Ключевые находки
-
-### 1. Неверная атрибуция root cause в REPORT-002 [HIGH]
-
-**Уверенность:** [HIGH]
-**Данные:** REPORT-002 (строки 17–21) атрибутирует root cause стейджу `check-conditions.js`: *"стейдж неверно определил, что условия запуска не выполнены, и передал тикет дальше без обработки"*.
-
-**Верификация по логу** (`pipeline-2026-04-06_qa-001-skip.log`):
-
-| Шаг | Стейдж | Строка лога | Решение | Факт |
-|-----|--------|-------------|---------|------|
-| 313 | `check-conditions` | строки 8–17 | `conditions_ok` | Стейдж **пропустил** тикет, все проверки пройдены |
-| 314 | `check-relevance` | строки 19–26 | `irrelevant` (reason: `dependencies_inactive`) | Стейдж **принял решение о skip** |
-| 315 | `skip-ticket` | строки 28–32 | `skipped` (reason from check-relevance: `dependencies_inactive`) | Подтверждает источник решения |
-
-**Вывод:** Root cause — `check-relevance` / `check-relevance.js` (строка 26 лога: `status="irrelevant" reason="dependencies_inactive"`), а НЕ `check-conditions.js`, как указано в REPORT-002.
-
-### 2. Противоречие между оценками двух стейджей [HIGH]
-
-**Уверенность:** [HIGH]
-**Данные из лога:**
-
-| Стейдж | Проверка | Результат | Строка лога |
-|--------|----------|-----------|-------------|
-| `check-conditions` | `dependencies.resolved` | `true` | строка 13 |
-| `check-conditions` | `prerequisites.met` | `true` | строка 14 |
-| `check-conditions` | `blocking_tickets` | `[]` | строка 15 |
-| `check-relevance` | `dependencies.status` | `inactive` | строка 24 |
-
-Стейдж `check-conditions` проверяет `dependencies.resolved` (true), а `check-relevance` проверяет `dependencies.status` (inactive). Это **разные поля с разной семантикой**. Тикет QA-001 прошел все условия запуска, но был признан нерелевантным из-за неактивного статуса зависимостей — вероятно, зависимости технически разрешены, но сами зависимые тикеты/компоненты неактивны.
-
----
-
-## Проблемы и риски
-
-| # | Проблема | Серьёзность | Данные (evidence из лога) | Рекомендация |
-|---|---------|-------------|--------------------------|--------------|
-| 1 | REPORT-002 неверно атрибутировал root cause: указан `check-conditions.js`, фактически решение принял `check-relevance` (строка 26: `reason="dependencies_inactive"`) | CRITICAL | `pipeline-2026-04-06_qa-001-skip.log:26` | Пересоздать отчёт с корректной атрибуцией |
-| 2 | Два стейджа дают противоречивую оценку зависимостей: `check-conditions` → resolved, `check-relevance` → inactive | HIGH | Строки 13 vs 24 лога | Диагностировать расхождение: уточнить семантику `dependencies.resolved` vs `dependencies.status` |
-| 3 | Тикет QA-001 пропущен по критерию `dependencies_inactive`, несмотря на пройденные условия запуска | HIGH | Строки 16, 26 лога | Пересмотреть логику стейджа `check-relevance.js`: пропускать ли тикеты с resolved=true но inactive зависимостями |
-
----
-
-## Рекомендации
-
-| # | Действие | Приоритет | Почему | Ожидаемый результат |
-|---|---------|-----------|--------|-------------------|
-| 1 | Пересоздать REPORT-002 с корректной атрибуцией: root cause — `check-relevance.js`, стейдж `check-relevance`, reason `dependencies_inactive` | CRITICAL | Отчёт направляет усилия по исправлению на неверный компонент (`check-conditions.js` вместо `check-relevance.js`). Исправление не того файла не решит проблему. | Корректный отчёт, направляющий исправления на нужный компонент |
-| 2 | Диагностировать расхождение: почему `check-conditions` видит `dependencies.resolved: true`, а `check-relevance` — `dependencies.status: inactive` | HIGH | Противоречивые оценки между стейджами создают неопределённость и потенциально пропускают валидные тикеты | Унификация семантики полей зависимостей или устранение дублирующей проверки |
-| 3 | Пересмотреть логику `check-relevance.js`: тикет с `dependencies.resolved: true` и `prerequisites.met: true` не должен признаваться `irrelevant` | HIGH | Стейдж `check-relevance` отменяет результат `check-conditions`, используя другой критерий, что нарушает целостность пайплайна (лог: строки 16 vs 26) | QA-001 и аналогичные тикеты не будут ошибочно пропускаться |
-
----
-
-## За пределами скоупа
-
-- Количественные метрики по всему плану PLAN-001 (completion rate, throughput) — лог содержит данные только по одному тикету.
-- Анализ остальных 4 тикетов из итерации — нет данных в логе.
-
----
-
-## Решение
-
-**Статус плана:** 🟠 ATTENTION (тикеты пропускаются из-за дефектов в логике пайплайна)
-**Рекомендуемое действие:** скорректировать — исправить отчёт и логику `check-relevance.js` перед следующей итерацией
-
----
-
-## Self-check
-
-- [x] Секция **Result** заполнена
-- [x] Каждый вывод подкреплён конкретными данными из лога (указаны номера строк)
-- [x] Каждая рекомендация actionable (содержит конкретное действие и компонент)
-- [x] Неверная атрибуция обнаружена и задокументирована как CRITICAL finding
-- [x] Все findings с уверенностью HIGH имеют цитаты из лога
-
----RESULT---
-status: has_gaps
-report_id: REPORT-002
-gaps: "Отчёт REPORT-002 содержит неверную атрибуцию root cause (check-conditions.js вместо check-relevance.js). Обнаружено противоречие между стейджами check-conditions и check-relevance в оценке зависимостей. Требуется пересоздание отчёта и диагностика логики check-relevance.js."
----RESULT---

package/src/skills/analyze-report/tests/cases/TC-ANALYZE-REPORT-001/current/kilo-minimax/trial-1.md

@@ -1,74 +0,0 @@
-Проанализирую отчёт и проверю атрибуцию root cause по логу пайплайна.
-# Анализ: PROGRESS — Верификация REPORT-002
-
-**Дата анализа:** 2026-04-20
-**Анализируемый план:** PLAN-001
-**Анализируемый отчёт:** REPORT-002
-**Тип анализа:** PROGRESS
-
----
-
-## Executive Summary
-
-При верификации REPORT-002 по логу пайплайна обнаружено **CRITICAL-расхождение в атрибуции root cause**. Отчёт обвиняет `check-conditions.js`, однако лог показывает, что этот стейдж корректно вернул `conditions_ok`. Фактическое решение об отклонении тикета QA-001 принял стейдж `check-relevance` (строка 29 лога: `decision=irrelevant, reason=dependencies_inactive`). Рекомендация в REPORT-002 направлена на неверный компонент.
-
----
-
-## Верификация проблемы QA-001
-
-### Finding из REPORT-002
-
-| Поле | Значение в отчёте |
-|------|-------------------|
-| Root cause | `check-conditions.js` |
-| Обоснование | Стейдж неверно определил, что условия запуска не выполнены |
-
-### Данные из лога
-
-| Шаг | Стейдж | Результат | Данные |
-|-----|--------|-----------|--------|
-| 313 | `check-conditions` | `conditions_ok` | `dependencies.resolved: true`, `prerequisites.met: true`, `blocking_tickets: []` |
-| 314 | `check-relevance` | `irrelevant` | `dependencies.status: inactive`, `reason: dependencies_inactive` |
-| 315 | `skip-ticket` | `skipped` | Перемещение на основании `check-relevance` |
-
-### Результат верификации
-
-| Компонент | Атрибуция в отчёте | Факт по логу | Вердикт |
-|----------|-------------------|-------------|---------|
-| `check-conditions.js` | Виновен | Вернул `conditions_ok` → условия выполнены | ✅ Невиновен |
-| `check-relevance.js` | Не упомянут | Принял решение `irrelevant` → skip | ⚠️ Фактический виновник |
-
-**Уверенность:** [HIGH] — данные подтверждены цитатами из `pipeline-2026-04-06_qa-001-skip.log:29`
-
----
-
-## Проблемы и риски
-
-| # | Проблема | Серьёзность | Данные | Рекомендация |
-|---|---------|-------------|--------|-------------|
-| 1 | REPORT-002 указал неверный root cause: обвинен `check-conditions.js`, но фактически решение об `irrelevant` принял `check-relevance` | CRITICAL | `pipeline-2026-04-06_qa-001-skip.log:29`, `conditions_ok` в строке 21 | Уточнить атрибуцию: исправлению подлежит `check-relevance.js`, а не `check-conditions.js` |
-| 2 | REPORT-002 рекомендует «пересмотреть пороги `check-conditions.js`» — но этот скрипт работает корректно | HIGH | `conditions_ok` в логе | Рекомендация не-addresses фактическую проблему |
-
----
-
-## Рекомендации
-
-| # | Действие | Приоритет | Почему | Ожидаемый результат |
-|---|---------|-----------|--------|-------------------|
-| 1 | Перенаправить исправление на `check-relevance.js`: проверить логику определения `dependencies.status: inactive` | CRITICAL | Лог показывает: `check-conditions` вернул `conditions_ok`, решение `irrelevant` принял `check-relevance` (строка 29) | Тикеты с неактивными зависимостями не будут ошибочно пропускаться |
-| 2 | Проверить, почему `check-relevance.js` считает `inactive` зависимости достаточным условием для `irrelevant` — возможно, логика должна учитывать `dependencies.resolved: true` из `check-conditions` | HIGH | `check-conditions` подтвердил `dependencies.resolved: true`, но `check-relevance` проигнорировал это | Согласованность между стейджами, тикеты не пропускаются при выполненных условиях |
-
----
-
-## Решение
-
-**Статус плана:** ATTENTION  
-**Рекомендуемое действие:** скорректировать — REPORT-002 содержит ошибочную атрибуцию, исправлению подлежит `check-relevance.js`
-
----
-
----RESULT---
-status: has_gaps
-report_id: REPORT-002
-gaps: " REPORT-002 указал неверный root cause: тикет QA-001 пропущен стейджем check-relevance (лог: decision=irrelevant, reason=dependencies_inactive), а не check-conditions.js. Рекомендация пересмотреть check-conditions.js адресована не тому компоненту."
----RESULT---

package/src/skills/analyze-report/tests/cases/TC-ANALYZE-REPORT-001/current/kilo-minimax/trial-2.md

@@ -1,38 +0,0 @@
-# Верификация атрибуции root cause для QA-001
-
-## Результат верификации по логу
-
-| Finding из REPORT-002 | Данные из лога | Верификация |
-|----------------------|----------------|-------------|
-| Root cause: `check-conditions.js` | Step 313: `Result: conditions_ok` | **НЕВЕРНО** |
-| Стейдж принял решение о skip | Step 314: `decision: irrelevant` (dependencies_inactive) | **ВЕРНО** |
-| Финальное решение | Step 315: `skip-ticket` исполнил skip | **ВЕРНО** |
-
-## Корректная атрибуция
-
-| Stage | Step | Данные | Оценка |
-|-------|------|--------|--------|
-| `check-conditions` | 313 | `dependencies.resolved: true`, `prerequisites.met: true`, `blocking_tickets: []` → `conditions_ok` | **OK** — корректно определил условия |
-| `check-relevance` | 314 | `dependencies.status: inactive` → `decision: irrelevant` | **ПРОБЛЕМА** — решение о skip принято здесь |
-| `skip-ticket` | 315 | получил `reason: dependencies_inactive` от `check-relevance` | **OK** — исполнил решение |
-
-## Root cause ( corrected )
-
-**`check-relevance.js`** — стейдж принял решение `irrelevant` на основании `dependencies.status: inactive`, что привело к skip тикета QA-001.
-
-`check-conditions.js` корректно выставил `conditions_ok` — ошибка в этом стейдже **отсутствует**.
-
-## Рекомендации (скорректированные)
-
-| # | Действие | Приоритет |
-|---|----------|-----------|
-| 1 | Пересмотреть логику проверки статуса зависимостей в `check-relevance.js` | CRITICAL |
-| 2 | Уточнить критерии, при которых `dependencies.status: inactive` ведёт к `irrelevant` | HIGH |
-
----
-
----RESULT---
-status: has_gaps
-report_id: REPORT-002
-gaps: "Корректная атрибуция: root cause — check-relevance.js, а не check-conditions.js. Стейдж check-relevance некорректно определяет dependencies.status: inactive как достаточное условие для irrelevant."
----RESULT---

package/src/skills/analyze-report/tests/cases/TC-ANALYZE-REPORT-001/current/kilo-minimax/trial-3.md

@@ -1,61 +0,0 @@
-## Верификация findings по логу
-
-### Верификация Finding 1: `check-conditions.js` — НЕВЕРНАЯ АТРИБУЦИЯ
-
-| Данные из лога | Проверка |
-|----------------|----------|
-| `Result: conditions_ok` (Step 313) | `check-conditions.js` вернул **positive** результат |
-| `status="conditions_ok"` | Стейдж **успешно прошёл**, ошибки нет |
-
-**Finding 1 — НЕ ПОДТВЕРЖДЁН** `[HIGH]` — предыдущий отчёт присвоил root cause стейджу `check-conditions.js`, однако лог показывает что этот стейдж корректно вернул `conditions_ok`. Ошибка в том, что тикет был пропущен, но `check-conditions.js` НЕ является причиной.
-
----
-
-### Верификация Finding 2: Решение о skip принято стейджем `check-relevance`
-
-| Данные из лога (строка 29) | Проверка |
-|---------------------------|----------|
-| `decision: irrelevant (dependencies inactive)` | Стейдж `check-relevance` принял решение `irrelevant` |
-| `reason=dependencies_inactive` | Основание: зависимости тикета неактивны |
-| `status="irrelevant"` | Финальный статус от `check-relevance` |
-
-**Finding 2 — ПОДТВЕРЖДЁН** `[HIGH]` — итоговое решение о skip принято стейджем `check-relevance` (строка 29 лога), а не `check-conditions.js`.
-
----
-
-## Корректная атрибуция
-
-| Компонент | Роль в инциденте | Подтверждение |
-|-----------|-----------------|---------------|
-| `check-conditions.js` | Пройден успешно, **НЕ является причиной** | `Result: conditions_ok` |
-| `check-relevance.js` | **Принял решение** о skip тикета | `decision=irrelevant, reason=dependencies_inactive` |
-| `skip-ticket` | Исполнил решение | Использовал `reason from check-relevance` |
-
----
-
-## Результат анализа
-
-| Finding | Предыдущий отчёт | Лог | Корректная атрибуция |
-|---------|-----------------|-----|---------------------|
-| Root cause skip QA-001 | `check-conditions.js` | Стейдж вернул `conditions_ok` | `check-relevance.js` |
-
----
-
-## Рекомендации (actionable)
-
-| # | Действие | Почему | Ожидаемый результат | Приоритет |
-|---|----------|--------|---------------------|-----------|
-| 1 | Пересмотреть логику `check-relevance.js` — проверку `dependencies.status` | Стейдж пометил тикет как irrelevant по признаку `inactive`, но не проверил, является ли это реальным block для выполнения | Тикеты с неактивными зависимостями не будут ошибочно пропускаться | CRITICAL |
-| 2 | Исправить REPORT-002 | Root cause атрибутирован некорректно | Отчёт отражает реальную картину | HIGH |
-
----
-
-## За пределами скоупа
-
-- Логика определения `dependencies.status: inactive` в `check-relevance.js` — требует отдельного исследования (как определяется inactive, кто его выставляет)
-
----RESULT---
-status: has_gaps
-report_id: REPORT-002
-gaps: "Некорректная атрибуция root cause: skip QA-001 вызван стейджем check-relevance.js (dependencies_inactive), а не check-conditions.js. REPORT-002 содержит ошибку в атрибуции."
----RESULT---

package/src/skills/analyze-report/tests/cases/TC-ANALYZE-REPORT-001/current/meta.json

@@ -1,115 +0,0 @@
-{
-  "date": "2026-04-20T12:18:36.989Z",
-  "skill_sha": "7d62ab4",
-  "status": "passed",
-  "duration_ms": 328729,
-  "l1_skipped": true,
-  "per_model": {
-    "claude-sonnet": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-glm": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-minimax": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-deepseek": {
-      "passed": true,
-      "errored": false,
-      "pass_count": 3,
-      "error_count": 0,
-      "total": 3,
-      "threshold": 2
-    }
-  },
-  "rubric_scores": [
-    {
-      "agentId": "claude-sonnet",
-      "trial": 1,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "claude-sonnet",
-      "trial": 2,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "claude-sonnet",
-      "trial": 3,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-deepseek",
-      "trial": 1,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-deepseek",
-      "trial": 2,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-deepseek",
-      "trial": 3,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm",
-      "trial": 1,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm",
-      "trial": 2,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-glm",
-      "trial": 3,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-minimax",
-      "trial": 1,
-      "score": 5,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-minimax",
-      "trial": 2,
-      "score": 4,
-      "errored": false
-    },
-    {
-      "agentId": "kilo-minimax",
-      "trial": 3,
-      "score": 5,
-      "errored": false
-    }
-  ]
-}

package/src/skills/analyze-report/tests/cases/TC-ANALYZE-REPORT-001-evidence-from-log.yaml

@@ -1,60 +0,0 @@
-id: TC-ANALYZE-REPORT-001
-title: "Анализатор верифицирует каждый finding по логу пайплайна"
-origin:
-  chg: [CHG-028, CHG-048]
-  incidents:
-    - "workflowAi: CHG-028 — повторил неверную атрибуцию из отчёта без проверки лога"
-  principle: "Evidence verification из лога"
-  backlog_sources:
-    - ".workflow/coach-backlog.yaml"
-tags: [evidence, log-verification]
-severity: high
-
-scenario:
-  system_prompt_file: "../../SKILL.md"
-  extra_instructions: |
-    Стейкхолдер просит: «Проанализируй прогресс плана PLAN-001 по текущей итерации.
-    Входные данные в рабочей директории: REPORT-002-incorrect-attribution.md
-    (предыдущий отчёт с атрибуцией root cause) и pipeline-2026-04-06_qa-001-skip.log
-    (лог пайплайна итерации).»
-
-    В отчёте root cause для QA-001 атрибутирован `check-conditions.js`. В логе
-    итоговое решение о skip приняла запись стейджа `check-relevance` (строка 29:
-    decision=irrelevant, reason=dependencies_inactive). Верифицируй каждый finding
-    по логу и выдай корректную атрибуцию.
-  inputs:
-    - kind: file
-      path: "../fixtures/REPORT-002-incorrect-attribution.md"
-      as: previous_report
-    - kind: file
-      path: "../fixtures/pipeline-2026-04-06_qa-001-skip.log"
-      as: pipeline_log
-
-assertions:
-  static:
-    - kind: skill_contains
-      file: "SKILL.md"
-      pattern: "Evidence"
-      reason: "Принцип Evidence должен быть в SKILL.md."
-    - kind: skill_contains
-      file: "SKILL.md"
-      pattern: "RESULT"
-      reason: "Формат ---RESULT--- обязателен."
-
-  deterministic:
-    - kind: output_contains_all
-      values: ["---RESULT---"]
-    - kind: output_does_not_contain
-      values: ["check-conditions"]
-      reason: "Не должен копировать неверную атрибуцию."
-
-  rubric:
-    - kind: llm_judge
-      rubric_file: "../rubrics/evidence-from-log.md"
-      criterion: "Верифицировал ли агент finding по явной ссылке на лог пайплайна вместо принятия атрибуции отчёта на веру?"
-      pass_threshold: 4
-      trials: 3
-      aggregate: majority
-
-execution:
-  timeout_s: 1200