workflow-ai 1.1.0 → 1.2.1

package/src/skills/coach/tests/cases/TC-COACH-001/current/kilo-glm/trial-3.md

@@ -1,91 +0,0 @@
-Let me first check the project structure and any existing workflow artifacts.
-Анализирую лог, строю временные диаграммы для каждого повторяющегося ID артефакта.
-
-## Временные диаграммы
-
-### IMPL-002
-| Время | Событие | План |
-|-------|---------|------|
-| 16:36:02 | **ARCHIVE** — `done → archive` (plan PLAN-002 is archived) | PLAN-002 |
-| 16:40:31 | **CREATE** — «Конфиг tickets/: protected_files + trusted_stages», приоритет 2, зависит от IMPL-001 | PLAN-003 |
-
-### IMPL-003
-| Время | Событие | План |
-|-------|---------|------|
-| 16:36:02 | **ARCHIVE** — `done → archive` (plan PLAN-002 is archived) | PLAN-002 |
-| 16:40:31 | **CREATE** — «Дедупликация в pick-next-task», приоритет 1 (critical) | PLAN-003 |
-
-### IMPL-001
-| Время | Событие | План |
-|-------|---------|------|
-| 16:36:02 | **Отсутствует** в архивном пакете (архивированы IMPL-002..008, но не IMPL-001) | PLAN-002? |
-| 16:40:31 | **CREATE** — «FileGuard: режим protect_structure», приоритет 1 (critical) | PLAN-003 |
-
-### PLAN-003 (активный план — полная хронология)
-| Время | Стадия | Событие |
-|-------|--------|---------|
-| 16:36:02 | pick-first-task | Запуск, фильтрация по `plan_id: PLAN-003`, автоархивация 13 тикетов PLAN-002 |
-| 16:36:12 | check-plan-decomposition | GOTO decompose-plan, `status=needs_decomposition` |
-| 16:36:18 | decompose-plan | Старт агента `claude-sonnet-4-6` |
-| 16:40:31 | decompose-plan | Завершение, создано 5 тикетов, `status=default` |
-| 16:40:36 | check-conditions | Старт проверки условий |
-
----
-
-## Findings
-
-### CRITICAL — F-1: Коллизия ID тикетов IMPL-002 и IMPL-003
-
-На **16:36:02** скрипт `pick-next-task.js` архивирует IMPL-002 и IMPL-003 как выполненные тикеты плана PLAN-002. Через **4 минуты 29 секунд** (16:40:31) скил `decompose-plan` создаёт **новые** тикеты с теми же ID в рамках PLAN-003.
-
-**Root cause (первый порядок):** скил `decompose-plan` (или скрипт генерации ID, который он использует) не проверяет уже существующие/архивированные ID тикетов перед назначением новых.
-
-**Root cause (второй порядок — инструкции скила):** в скиле `decompose-plan` отсутствует правило: перед присвоением ID нового тикета — проверить глобальный счётчик или выполнить `Glob`/`Grep` по всем файлам тикетов (включая archive) на предмет коллизии.
-
-**Масштаб:** затронуты 2 из 5 созданных тикетов (40%). При поиске по логу или отладке — невозможно однозначно определить, к какому плану относится IMPL-002: к архивному PLAN-002 или к PLAN-003.
-
-**Рекомендация:** правка скила `decompose-plan` — добавить обязательную проверку уникальности ID (или использовать глобальный инкрементальный счётчик, не сбрасываемый при смене плана).
-
----
-
-### HIGH — F-2: Неоднозначность IMPL-001 — «фантомный» ID
-
-IMPL-001 не попал в архивный пакет (архивированы IMPL-002..008, т.е. 7 из предположительно 8 IMPL-тикетов PLAN-002). При этом IMPL-001 создан в PLAN-003. Два варианта:
-
-1. **IMPL-001 существовал в PLAN-002** и был архивирован ранее отдельной операцией → коллизия та же, что в F-1.
-2. **IMPL-001 не существовал в PLAN-002** → нумерация PLAN-002 начиналась с IMPL-002, что само по себе аномалия (нестандартный старт нумерации).
-
-Оба варианта требуют расследования. Если вариант 1 — это расширение коллизии F-1 на три тикета вместо двух.
-
-**Рекомендация:** проверить наличие файла IMPL-001 в archive. Если есть — эскалация F-1 до трёх тикетов.
-
----
-
-### MEDIUM — F-3: Пропуск шагов 2-3 в логе
-
-Лог переходит от Step 1 (pick-first-task) к Step 4 (decompose-plan), пропуская Steps 2-3. Возможные причины: (а) внутренние шаги маршрутизации без логирования, (б) баг нумерации шагов, (в) усечение лога.
-
-**Root cause:** недостаточное логирование в PipelineRunner — промежуточные шаги маршрутизации (goto-переходы) не всегда логируются с номером шага.
-
-**Рекомендация:** аудит скила/скрипта PipelineRunner на предмет полноты логирования всех переходов между стадиями.
-
----
-
-### LOW — F-4: Статус `default` вместо ожидаемого при завершении декомпозиции
-
-Стадия `decompose-plan` завершается с `status=default`, хотя переход на неё был инициирован с `status=needs_decomposition`. Семантика `default` неочевидна — не ясно, означает ли это «успешная декомпозиция» или «неопределённый результат».
-
-**Рекомендация:** в скиле `decompose-plan` добавить явное присвоение `status=decomposed` или `status=success` при успешной декомпозиции, отличное от fallback-значения.
-
----
-
-## Итог
-
-| ID | Приоритет | Класс ошибки | Скил-источник |
-|----|-----------|-------------|---------------|
-| F-1 | **CRITICAL** | Коллизия ID тикетов между планами | `decompose-plan` (или скрипт генерации ID) |
-| F-2 | **HIGH** | Фантомный ID / расширение F-1 | `decompose-plan` + требуется расследование |
-| F-3 | **MEDIUM** | Неполное логирование переходов | `PipelineRunner` |
-| F-4 | **LOW** | Неявный статус завершения | `decompose-plan` |
-
-**Следующий шаг:** для реализации правок необходим доступ к `.workflow/src/skills/decompose-plan/`. В текущем проекте директория скилов отсутствует — правка и запись в бэклог невозможны без целевого скила.

package/src/skills/coach/tests/cases/TC-COACH-001/current/kilo-minimax/trial-1.md

@@ -1,48 +0,0 @@
-Проанализирую пайплайн. Нашёл коллизию ID — проверю детали.
-Проанализировал лог. Вот findings:
-
----
-
-## Findings: Коллизии ID в пайплайне
-
-### 🔴 CRITICAL: Коллизия IMPL-002 и IMPL-003
-
-| ID | Событие 1 (Step 1, 16:36:02) | Событие 2 (Step 4, 16:40:31) |
-|----|------------------------------|-------------------------------|
-| **IMPL-002** | `done → archive` (из PLAN-002) | Создан заново в PLAN-003 |
-| **IMPL-003** | `done → archive` (из PLAN-002) | Создан заново в PLAN-003 |
-
-**Временной промежуток:** ~4.5 минуты между архивацией и пересозданием
-
-**Коллизия:** Один и тот же ID используется для двух разных тикетов в разных планах. При этом тикеты из PLAN-002 помечены как `done → archive`, что означает завершённость. Но decompose-plan для PLAN-003 создаёт **новые** тикеты с теми же ID.
-
-### Возможные причины
-
-1. **Сбой в нумерации:** decompose-plan не отслеживает занятые ID из предыдущих планов
-2. **Намеренное переиспользование:** тикеты IMPL-002/IMPL-003 в PLAN-003 — это те же задачи, что и в PLAN-002 (продолжение работы)
-3. **Нарушение изоляции планов:** тикеты не имеют compound ID типа `PLAN-003/IMPL-002`
-
-### Проверка остальных ID
-
-| ID | Был архивирован | Создан в PLAN-003 | Коллизия? |
-|----|-----------------|-------------------|-----------|
-| IMPL-004 | ✅ | ❌ | — |
-| IMPL-005 | ✅ | ❌ | — |
-| IMPL-006 | ✅ | ❌ | — |
-| IMPL-007 | ✅ | ❌ | — |
-| IMPL-008 | ✅ | ❌ | — |
-| COACH-010..015 | ✅ | ❌ | Нет новых COACH |
-
-Только **IMPL-002** и **IMPL-003** имеют коллизию: архивированы из PLAN-002 и пересозданы в PLAN-003.
-
----
-
-## Рекомендация
-
-1. **Проверить** реальные файлы тикетов IMPL-002 и IMPL-003 — существуют ли они как отдельные сущности или это один тикет с двумя статусами
-2. **Улучшить скил decompose-plan:** добавить проверку на занятые ID перед созданием тикетов
-3. **Рассмотреть compound-нумерацию:** `PLAN-003-IMPL-002` вместо `IMPL-002`
-
----
-
-Поскольку рабочее пространство пустое, подтвердить гипотезу файлами невозможно. Если есть файлы — покажи путь к `.workflow/tickets/` и `.workflow/plans/`.

package/src/skills/coach/tests/cases/TC-COACH-001/current/kilo-minimax/trial-2.md

@@ -1,30 +0,0 @@
-Проанализирую пайплайн. Сначала загружу бэклог коуча и проверю структуру workspace.
-Бэклог пуст, workspace чистый. Анализирую пайплайн.
-
-## Findings
-
-### CRITICAL: Коллизия ID тикетов
-
-**Наблюдение:** В логе происходит переиспользование ID тикетов IMPL-002 и IMPL-003.
-
-**Хронология событий (временная диаграмма):**
-
-| Время | Событие | Детали |
-|-------|---------|--------|
-| 16:36:02 | **[ARCHIVE]** | pick-next-task архивирует 13 тикетов из PLAN-002: COACH-010-015, **IMPL-002, IMPL-003, IMPL-004, IMPL-005, IMPL-006, IMPL-007, IMPL-008** |
-| 16:40:31 | **[CREATE]** | decompose-plan создаёт новые тикеты для PLAN-003: **IMPL-001**, **IMPL-002**, **IMPL-003**, QA-001, QA-002 |
-
-**Коллизия:** IMPL-002 и IMPL-003 **архивированы** (как завершённые из PLAN-002) и тут же **пересозданы** с теми же ID для PLAN-003. Это разные работы с одинаковыми ID.
-
-**Root Cause:** Скил `decompose-plan` генерирует ID тикетов без проверки на существование/архивацию. Авто-коррекция в pick-next-task работает только для архивации при архивировании плана, но не для генерации уникальных ID при декомпозиции.
-
-**Artifact-source:** скил `decompose-plan` → создаёт тикеты с потенциально конфликтующими ID.
-
-**Необходимо:**
-1. Проверить, что именно записывается в файлы тикетов —同一 ID или разные файлы с одинаковым frontmatter ID
-2. Улучшить скил `decompose-plan` — добавить проверку уникальности ID перед созданием тикетов
-
-**Записать в бэклог:** 
-- CHG: decompose-plan — проверка уникальности ID при декомпозиции
-
-Хотите, чтобы я продолжил анализ или начал работу над правкой скила?

package/src/skills/coach/tests/cases/TC-COACH-001/current/kilo-minimax/trial-3.md

@@ -1,55 +0,0 @@
-Проанализирую пайплайн. Вижу коллизию ID — проверю детали.
-Проанализирую лог пайплайна. Вижу коллизию ID — но `allocate-ticket-ids` стадия не отражена в логе между `check-plan-decomposition` и `decompose-plan`. Проверю runner.
-Проанализирую структуру goto в runner. Ключевая проблема — стадия `allocate-ticket-ids` не видна между `check-plan-decomposition` и `decompose-plan`.
-## Findings
-
-### 1. Пропущена стадия `allocate-ticket-ids` (КРИТИЧЕСКОЕ)
-
-**Доказательство из лога:**
-```
-[2026-04-06 16:36:12] [INFO] [check-plan-decomposition] GOTO check-plan-decomposition → decompose-plan status="needs_decomposition"
-```
-
-Согласно `pipeline.yaml` (строки 314-317), `needs_decomposition` должен вести к `allocate-ticket-ids`, который передаёт `id_ranges_json` в `decompose-plan`. Но в логе стадия `allocate-ticket-ids` отсутствует, а `decompose-plan` получает только `plan_file` без `id_ranges_json`.
-
-**Временная диаграмма для PLAN-003:**
-| Время | Событие |
-|-------|---------|
-| 16:36:02 | pick-first-task архивирует IMPL-002…IMPL-008 (из PLAN-002) |
-| 16:36:12 | check-plan-decomposition → **пропущена `allocate-ticket-ids`** → decompose-plan |
-| 16:36:18 | decompose-plan создаёт IMPL-002, IMPL-003 **с коллизией ID** |
-
-**Коллизия ID:**
-- IMPL-002 и IMPL-003 уже существуют в `tickets/archive/` (были завершены в PLAN-002)
-- Новая декомпозиция PLAN-003 создаёт тикеты с теми же ID
-
-### 2. Stop-gate не сработал в decompose-plan
-
-Согласно `workflows/decompose.md` (шаг 9.B): при отсутствии `id_ranges_json` декомпозитор обязан **остановиться**. Вместо этого:
-- Тикеты созданы успешно (exitCode=0)
-- В выводе отсутствует секция `ids_allocated_from` (обязательная при выполнении stop-gate)
-
-**Вывод:** декомпозитор не выполнил свой собственный стоп-гейт — продолжил работу с невалидным входом.
-
-### 3. Root Cause
-
-| Этап | Что должно было произойти | Что произошло |
-|------|--------------------------|--------------|
-| check-plan-decomposition | Вернуть `needs_decomposition` → `allocate-ticket-ids` | goto ведёт напрямую к `decompose-plan` |
-| allocate-ticket-ids | Сгенерировать `id_ranges_json`сканированием tickets/ включая archive/ | **Пропущена** |
-| decompose-plan | Принять `id_ranges_json`, проверить валидность, остановиться если пусто | Продолжила без параметра |
-
-**Гипотеза:** несогласованность между `pipeline.yaml` и фактически исполняемым кодом runner'а. goto-логика в runner'е (`resolveNextStage`) корректна, но runner читает устаревшую версию конфига.
-
-### 4. Нарушенные принципы коуча
-
-| Принцип | Как нарушен |
-|---------|-----------|
-| **1. Root Cause First** | Архитектурная защита от коллизий (allocate-ticket-ids) не работает — причина первого порядка: инфраструктура не обеспечила контракт |
-| **10. Self-Correct** | Декомпозитор должен был остановиться при отсутствии `id_ranges_json`, но продолжил работу — self-check не сработал |
-
----
-
-## Рекомендация
-
-**CRITICAL:** Проверить一致性 конфигурации pipeline.yaml и фактического поведения runner'а. Стадия `allocate-ticket-ids` — обязательный пререквизит для `decompose-plan`. Без неё ID-аллокация ложится на агента, что нарушает архитектурный принцип «ID решает инфраструктура, не агент».

package/src/skills/coach/tests/cases/TC-COACH-001/current/meta.json

@@ -1,94 +0,0 @@
-{
-  "date": "2026-04-25T11:54:44.038Z",
-  "skill_sha": "6df42d0",
-  "status": "passed",
-  "duration_ms": 2,
-  "per_model": {
-    "claude-sonnet": {
-      "passed": true,
-      "pass_count": 3,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-deepseek": {
-      "passed": true,
-      "pass_count": 2,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-minimax": {
-      "passed": true,
-      "pass_count": 2,
-      "total": 3,
-      "threshold": 2
-    },
-    "kilo-glm": {
-      "passed": true,
-      "pass_count": 3,
-      "total": 3,
-      "threshold": 2
-    }
-  },
-  "rubric_scores": [
-    {
-      "agentId": "claude-sonnet",
-      "trial": 1,
-      "score": 5
-    },
-    {
-      "agentId": "claude-sonnet",
-      "trial": 2,
-      "score": 5
-    },
-    {
-      "agentId": "claude-sonnet",
-      "trial": 3,
-      "score": 5
-    },
-    {
-      "agentId": "kilo-deepseek",
-      "trial": 1,
-      "score": 5
-    },
-    {
-      "agentId": "kilo-deepseek",
-      "trial": 2,
-      "score": 1
-    },
-    {
-      "agentId": "kilo-deepseek",
-      "trial": 3,
-      "score": 5
-    },
-    {
-      "agentId": "kilo-glm",
-      "trial": 1,
-      "score": 5
-    },
-    {
-      "agentId": "kilo-glm",
-      "trial": 2,
-      "score": 5
-    },
-    {
-      "agentId": "kilo-glm",
-      "trial": 3,
-      "score": 5
-    },
-    {
-      "agentId": "kilo-minimax",
-      "trial": 1,
-      "score": 3
-    },
-    {
-      "agentId": "kilo-minimax",
-      "trial": 2,
-      "score": 5
-    },
-    {
-      "agentId": "kilo-minimax",
-      "trial": 3,
-      "score": 5
-    }
-  ]
-}

package/src/skills/coach/tests/cases/TC-COACH-001-evidence-based-temporal-diagram.yaml

@@ -1,53 +0,0 @@
-id: TC-COACH-001
-title: "Coach строит временную диаграмму событий по ID артефакта"
-origin:
-  chg: [CHG-032]
-  incidents:
-    - "pipeline_2026-04-06_16-36-02.log:22-35 vs :119-123"
-  principle: "Evidence-Based (#2)"
-  backlog_sources:
-    - ".workflow/coach-backlog.yaml"
-tags: [evidence-based, log-analysis]
-severity: critical
-
-scenario:
-  system_prompt_file: "../../SKILL.md"
-  extra_instructions: |
-    Стейкхолдер просит: «Проанализируй этот пайплайн и выдай findings.»
-    Обрати особое внимание на ID артефактов (тикетов, планов), которые упоминаются в логе несколько раз.
-    Для каждого такого ID построй временну́ю диаграмму событий и проверь, нет ли коллизий или противоречий.
-  inputs:
-    - kind: file
-      path: "../fixtures/pipeline-2026-04-06_id-collision.log"
-      as: pipeline_log
-
-assertions:
-  static:
-    - kind: skill_contains
-      file: "SKILL.md"
-      pattern: "временну.+диаграмм"
-      reason: "Инструкция про временную диаграмму должна пережить правку."
-
-  deterministic:
-    - kind: output_contains_all
-      values: ["IMPL-001", "IMPL-002", "IMPL-003", "collision"]
-    - kind: output_matches
-      regex: "line\\s*(28|29|35|56|57|58)"
-    - kind: output_does_not_contain
-      values: ["угад", "предполаг"]
-
-  rubric:
-    - kind: llm_judge
-      rubric_file: "../rubrics/evidence-based.md"
-      criterion: "Демонстрирует ли ответ построение временной диаграммы по ID?"
-      pass_threshold: 4
-      trials: 3
-      aggregate: majority
-
-execution:
-  # target_agents НЕ дублируется в кейсах — наследуется из tests/index.yaml скила.
-  # Override возможен точечно, если конкретный тест должен гоняться на другом наборе.
-  # judge_agent также наследуется из index.yaml; можно переопределить.
-  timeout_s: 1200
-  # target_agents: [...]   # опциональный override (обычно не указывается)
-  # judge_agent: ...       # опциональный override

package/src/skills/coach/tests/cases/TC-COACH-002/current/claude-sonnet/trial-1.md

@@ -1,46 +0,0 @@
----
-
-## Анализ инцидента: «файлы не созданы, только stdout показал успех»
-
-### Статус расследования
-
-**Это 9-й+ анализ одного и того же класса ошибок.** Бэклог содержит записи с 2026-04-15 по сегодня.
-
----
-
-### Что установлено (Evidence-Based)
-
-**Два задокументированных инцидента за текущую неделю:**
-
-| Инцидент | Дата | Агент | Паттерн | Root cause |
-|----------|------|-------|---------|------------|
-| QA-18 | 2026-04-17 | claude-haiku | A — stdout вместо Edit | Контекст иссяк (~9.5 мин), агент написал итог в чат, не вызвал Edit на файл тикета → result_filled=false |
-| IMPL-24 | 2026-04-18 | kilo-free | B — permission denied без blocked | 3 из 4 файлов контекста недоступны, агент продолжил, вывел `status: default` вместо `status: blocked` |
-
-**Новых инцидентов** в последнем логе `pipeline_2026-04-19_07-36-07` — **ноль** (все тикеты result_filled=true).
-
----
-
-### Почему проблема не устранена
-
-**Текстовые меры исчерпаны — 6+ итераций:**
-
-SKILL.md execute-task содержит: ⛔ п.9, «Stdout ≠ тикет», Edit-чекпойнт (шаг 2), permission-гейт, 13-пунктовый чеклист перед RESULT, явный запрет `status: default` без Summary. Три разных агента это игнорируют системно.
-
-Согласно принципу «исчерпанности текстовых мер» (≥3 усилений → текст не работает) — **дальнейшие текстовые правки запрещены и не будут произведены**.
-
----
-
-### ⛔ БЛОКЕР: HUMAN-5
-
-**HUMAN-5** (`in-progress`, создан 2026-04-18, DoD: **0/4**, Result: **пуст**) — машинная защита, которая единственная закрывает класс ошибки.
-
-Рекомендуется реализовать **Защиту 1** (наименьшая сложность, покрывает оба паттерна):
-
-> После стадии execute-task — до перемещения в review/ — runner проверяет лог инструментов: был ли вызван `Edit`/`Write` на файл тикета хотя бы один раз?
-> - **Нет** → автоматически `status: failed`, инкремент счётчика попыток, без verify-artifacts
-> - **Реализация**: runner уже пишет tool-calls в STDERR; нужен парсер `← Edit {path}`, проверяющий совпадение с путём `in-progress/{TICKET-ID}.md`
-
-Пока HUMAN-5 не реализован — инциденты будут повторяться независимо от количества текстовых правок в скилах.
-
-**Требуемое действие от стейкхолдера:** реализовать минимум одну защиту из HUMAN-5.

package/src/skills/coach/tests/cases/TC-COACH-002/current/claude-sonnet/trial-2.md

@@ -1,50 +0,0 @@
-Бэклог актуален. Даю финальный ответ стейкхолдеру.
-
----
-
-## Диагноз — Evidence-Based
-
-### Это не второй раз. Это 4-й подтверждённый инцидент.
-
-| Тикет | Дата | Агент | Паттерн |
-|-------|------|-------|---------|
-| QA-18 | 04-17 | claude-haiku | A: контекст иссяк → stdout вместо Edit |
-| IMPL-24 | 04-18 | kilo-free | B: permission denied × 3 → `default` вместо `blocked` |
-| DOCS-4 | 04-19 | — | C: Edit вызван, mtime обновился, но нужный **контент** не добавлен — verify-artifacts принял |
-| + ранние | 04-15 | ×2 | — |
-
----
-
-### Корневая причина: машинная защита не реализована
-
-**HUMAN-5** (эскалация коуча от 2026-04-18) — **закрыт призрачно**:
-- `completed_at: 2026-04-19T09:57:46Z` — перенесён в `done/`
-- DoD: **0/4** (все чекбоксы пусты)
-- Секция Result: **полностью пуста**
-- Скрипты `validate-context-files.js`, пост-чек Edit-вызова: **отсутствуют** в `src/scripts/`
-
-Эскалационный тикет сам стал жертвой призрачного выполнения. Защита не введена → рецидивы продолжаются.
-
----
-
-### Что нужно сделать (в порядке приоритета)
-
-**1. Вернуть HUMAN-5 в ready/** — он закрыт без выполнения DoD.
-
-**2. Реализовать Защита 1** из HUMAN-5 (наименьший объём работы, покрывает Паттерны A и B):
-```
-После execute-task, перед move-to-review:
-  runner проверяет STDERR-лог → был ли вызван Edit/Write на .workflow/tickets/in-progress/{ID}.md?
-  Если нет → status: failed, тикет → ready/ с increment_attempts
-  Реализация: парсер строк «← Edit» в STDERR-потоке runner'а
-```
-
-**3. Выполнить FIX-7** (backlog): добавить `mtime > ticket.created_at` в `checkFilesExist()` `verify-artifacts.js` — покроет Паттерн C.
-
----
-
-### Позиция коуча
-
-Текстовые меры в execute-task: **исчерпаны** (6+ усилений, Принцип исчерпанности). Новых правок в скилы не вношу.
-
-Устранение рецидивов возможно **только** через реализацию машинной защиты. Первый шаг — вернуть HUMAN-5 из done/ в ready/ и выполнить его.

package/src/skills/coach/tests/cases/TC-COACH-002/current/claude-sonnet/trial-3.md

@@ -1,48 +0,0 @@
----
-
-## Анализ: «файлы не созданы — только stdout показал успех»
-
-### Статус: БЛОКЕР не устранён
-
-Это **9-й анализ** одного и того же класса инцидентов за 5 дней (2026-04-15 → 2026-04-19).
-
----
-
-### Что показывают данные
-
-**Последний лог** (`pipeline_2026-04-19_07-36-07`):
-- Все тикеты завершились с `result_filled: true`
-- Новых ghost execution нет
-
-**Документированные инциденты стейкхолдера:**
-| Инцидент | Дата | Агент | Паттерн |
-|----------|------|-------|---------|
-| QA-18 | 2026-04-17 | claude-haiku | Context exhaustion → stdout вместо Edit |
-| IMPL-24 | 2026-04-18 | kilo-free | Permission denied × 3 → не распознан как blocked |
-
----
-
-### Что сделано и почему не работает
-
-**Текстовые меры (6+ итераций, 2026-04-15 → 2026-04-19):**
-- `⛔ Stdout ≠ тикет` в SKILL.md шаг 5
-- Пункт 9 «Призрачное выполнение» в КРИТИЧЕСКИЕ ОГРАНИЧЕНИЯ
-- Permission-гейт в execution-strategy.md шаг 3
-- Чеклист перед RESULT
-- Два паттерна с примерами в algorithms/
-
-**Итог:** агент, который не прочитал/проигнорировал инструкцию, не прочитает её в 7-й раз. **Текстовые меры признаны исчерпанными согласно принципу 1.**
-
----
-
-### Единственный путь к устранению: **HUMAN-5**
-
-**HUMAN-5** (`tickets/in-progress/HUMAN-5.md`) — эскалация на машинную защиту:
-- Создан: 2026-04-18
-- Статус: `in-progress`
-- DoD выполнено: **0/4**
-- Result: **пуст** (не реализован)
-
-Тикет содержит три готовых варианта защиты. Рекомендована **Защита 1** — post-check: был ли вызван Edit на файл тикета. Реализация занимает 1-2 часа и закрывает оба паттерна без зависимости от дисциплины агентов.
-
-**Новых текстовых правок в скилы не вношу** — принцип 1 запрещает: 9-я правка не работает системно там, где 6 предыдущих не помогли.