workflow-ai 1.2.1 → 1.3.0

package/CHANGELOG.md

@@ -1,4 +1,16 @@
-## [1.2.0] — 2026-04-28
+## [1.3.0] — 2026-04-30
+
+### Добавлено
+- **Новый тип стейджа: `mark-blocked` и расширение frontmatter** — Добавлены поля `auto_blocked_reason`, `auto_blocked_attempts`, `auto_blocked_at` для автоматического отслеживания причин и попыток блокировки тикетов. Стейдж `mark-blocked` позволяет устанавливать эти поля в зависимости от условий бизнес-логики.
+- **Новый тип стейджа: `manual-gate-human`** — Добавлен статус `human_ready` в `pick-next-task.js`. При достижении этого статуса задача ожидает ручного решения оператора перед продолжением выполнения.
+- **Хук одобрения в `move-ticket.js`** — Добавлен approval-hook, проверяющий наличие ожидающих решения одобрений перед перемещением тикета в терминальные состояния.
+- **Расширение START-лога полем `ticket="X"`** — Добавлено поле с идентификатором тикета в стартовый лог для улучшенной трассировки и связывания логов с конкретными задачами.
+- **Исправление `approval-pending.mjs` (поле `created_at`)** — Исправлено некорректное заполнение поля `created_at` при создании файлов ожидающих решения.
+
+> **Примечание:** версия 1.2.0 не была опубликована в npm. При выполнении `npm publish`
+> сработал prepublishOnly/postversion скрипт, автоматически поднявший версию до 1.2.1.
+> Git-тег `v1.2.0` (коммит 179d52b) соответствует состоянию до publish; `v1.2.1` (коммит 83d1b70) —
+> фактически опубликованной версии.
 
 ### New Features
 - **New built-in stage type: `manual-gate`** — Adds support for manual approval steps in pipelines. When a stage with `type: manual-gate` is encountered, the runner creates a pending approval file in `.workflow/approvals/{step_id}.json` and enters a polling loop, waiting for an external decision (`approved`/`rejected`).
@@ -35,7 +47,7 @@
 - No breaking changes. All existing pipelines without `manual-gate` stages are fully backward compatible.
 
 ### Fixes
-- None
+- Исправлено сохранение временной метки `created_at` в файлах одобрений (approval-pending.mjs)
 
 ### Technical Notes
 - Approval files are stored in `<project_root>/.workflow/approvals/`

package/README.md

@@ -1,475 +1,37 @@
-# workflow-ai
-
-Координатор воркфлоу для AI-агентов — конвейер на основе канбан-доски для AI-агентов, пишущих код.
-
-Система координации AI-агентов через файловую канбан-доску. Автоматически оркестрирует выполнение задач: берёт тикеты из очереди, запускает нужного агента, проверяет результат и генерирует отчёты.
-
-## Установка
-
-```bash
-npm install -g workflow-ai
-```
-
-## Быстрый старт
-
-```bash
-# 1. Инициализировать воркфлоу в вашем проекте
-workflow init
-```
-
-```text
-# 2. Открыть проект в AI-агенте (Claude Code, Kilo, и т.д.) и попросить создать план через скил:
-Создай план <описание задачи> используя скил .workflow/src/skills/create-plan/SKILL.md
-```
-
-```bash
-# 3. Запустить конвейер — он декомпозирует план на тикеты и начнёт исполнение
-workflow run
-```
-
-## Команды
-
-| Команда | Описание |
-|---------|----------|
-| `workflow init [path] [--force]` | Инициализировать директорию `.workflow/` со структурой канбан-доски |
-| `workflow run [options]` | Запустить AI-конвейер |
-| `workflow update [path]` | Обновить глобальную директорию и пересоздать junctions |
-| `workflow eject <skill> [path]` | Извлечь скил (скопировать из глобальной директории в проект) |
-| `workflow eject-scripts [path]` | Извлечь скрипты (скопировать из глобальной директории в проект) |
-| `workflow eject-configs [path]` | Извлечь конфиги (скопировать из глобальной директории в проект) |
-| `workflow list [path]` | Вывести список скилов со статусом (shared/ejected/project-only) |
-| `workflow help` | Показать справку |
-| `workflow version` | Показать версию |
-
-### Опции команды `run`
-
-| Опция | Описание |
-|-------|----------|
-| `--plan <plan>` | ID плана для выполнения |
-| `--config <path>` | Путь к конфиг-файлу |
-| `--project <path>` | Корень проекта (по умолчанию: автоопределение) |
-
-## Инициализация
-
-Команда `workflow init` создаёт структуру директории `.workflow/`:
-
-```
-.workflow/
-├── config/                       # → junction на ~/.workflow/configs/ (eject для кастомизации)
-├── plans/
-│   ├── current/                  # Текущие планы разработки
-│   ├── templates/                # Шаблоны планов с триггерами (повторяющиеся планы)
-│   └── archive/                  # Архивные планы
-├── tickets/
-│   ├── backlog/                  # Ожидают условий
-│   ├── ready/                    # Готовы к выполнению
-│   ├── in-progress/              # В работе
-│   ├── blocked/                  # Заблокированы зависимостями
-│   ├── review/                   # Ожидают ревью
-│   └── done/                     # Завершены
-├── reports/                      # Сгенерированные отчёты
-├── logs/                         # Логи выполнения конвейера
-├── metrics/                      # Метрики производительности
-├── templates/                    # Шаблоны тикетов/планов/отчётов
-└── src/
-    ├── skills/                   # Инструкции скилов (junctions на глобальные, по каждому скилу)
-    └── scripts/                  # Скрипты автоматизации (junction на глобальные)
-```
-
-## Конвейер
-
-Команда `workflow run` исполняет многоэтапный конвейер:
-
-1. **pick-first-task** — выбрать тикет из очереди ready
-2. **check-plan-templates** — проверить триггеры шаблонов планов, создать планы при срабатывании
-3. **check-plan-decomposition** — проверить состояние декомпозиции/активации планов
-4. **allocate-ticket-ids** — выделить стартовые ID для префиксов до декомпозиции
-5. **decompose-plan** — разбить план на тикеты (при необходимости)
-6. **check-atomicity-limit / verify-atomicity / increment-atomicity-counter** — проверить атомарность тикетов плана
-7. **check-conditions** — проверить условия готовности тикета
-8. **move-to-ready** — переместить тикеты из backlog в ready
-9. **pick-next-task** — выбрать следующий тикет для выполнения
-10. **move-to-in-progress** — начать выполнение
-11. **check-relevance** — проверить, что тикет всё ещё актуален (на скриптах, без LLM)
-12. **check-mcp** — проверить доступность MCP-зависимостей тикета
-13. **execute-task** — выполнить работу через AI-агента
-14. **move-to-review** — отправить на ревью
-15. **verify-artifacts** — детерминированная проверка артефактов тикета
-16. **review-result** — проверить результаты по Definition of Done
-17. **increment-task-attempts** — учесть попытки повторов
-18. **move-ticket** — переместить в done/blocked по результатам ревью
-19. **create-report** — сгенерировать отчёт о выполнении
-20. **analyze-report / decompose-gaps** — проанализировать результаты и итерировать
-21. **complete-plan / increment-plan-iterations** — закрыть план или запустить следующую итерацию
-
-### Типы стадий
-
-#### `update-counter`
-Встроенная стадия, инкрементирует счётчик и возвращает статус для перехода. Требует `counter` и опционально `max`. Возвращает `default` или `max_reached`.
-
-#### `manual-gate`
-Встроенная стадия для ручного одобрения. Создаёт файл `.workflow/approvals/{step_id}.json` со статусом `pending` и ждёт решения через polling (интервал по умолчанию 2000мс).
-
-**Параметры:**
-- `poll_interval_ms` — интервал опроса (опц., default 2000)
-- `timeout_seconds` — таймаут в секундах (опц., default без таймаута)
-
-**Требуемые goto:**
-- `approved` — обязательный, переход при одобрении
-- `rejected` — обязательный, переход при отклонении
-
-**Опциональные goto:**
-- `timeout` — при истечении таймаута
-- `aborted` — при остановке runner'а (SIGTERM)
-
-**Формат step_id:** `{ticket_id}_{stageId}_{attempt}` (например, `QA-12_manual-approve_0`)
-
-**Approval-файл содержит:**
-```json
-{
-  "step_id": "QA-12_manual-approve_0",
-  "ticket_id": "QA-12",
-  "stage_id": "manual-approve",
-  "attempt": 0,
-  "status": "pending",
-  "created_at": "2026-04-28T12:34:56.789Z",
-  "updated_at": "2026-04-28T12:34:56.789Z",
-  "decided_by": null,
-  "comment": null,
-  "context_snapshot": { ... }
-}
-```
-
-**Два способа одобрения:**
-1. **Через MCP-клиент** (например `workflow-mcp`): tool `approve_step({step_id, decision, comment})` пишет в файл approval
-2. **Прямая правка файла:** открыть `.workflow/approvals/{step_id}.json`, изменить `"status": "pending"` на `"approved"` или `"rejected"`, сохранить
-
-**Важное:** `manual-gate` — **opt-in**. Если ваш pipeline не использует стадии `manual-gate`, поведение полностью идентично предыдущим версиям! Никаких breaking changes.
-
-**Пример:**
-```yaml
-stages:
-  manual-approve-deploy:
-    type: manual-gate
-    poll_interval_ms: 2000
-    timeout_seconds: 86400
-    goto:
-      approved: continue-deploy
-      rejected: rollback
-      timeout: notify-stuck
-      aborted: end
-```
-
-Агенты настраиваются в `configs/pipeline.yaml`.
-
-## Скилы
-
-Встроенные скилы для разных типов задач:
-
-| Скил | Описание |
-|------|----------|
-| `analyze-report` | Анализ отчёта |
-| `coach` | Управление и улучшение скилов |
-| `create-plan` | Создание плана |
-| `create-report` | Генерация отчёта |
-| `decompose-gaps` | Декомпозиция пробелов |
-| `decompose-plan` | Декомпозиция плана на тикеты |
-| `deep-research` | Глубокий ресерч |
-| `execute-task` | Выполнение задачи |
-| `manual-testing` | UI-observability: ручное тестирование сценариев |
-| `review-result` | Ревью результата по DoD |
-
-Скилы хранятся глобально в `~/.workflow/skills/` и подключаются в проекты через junctions.
-
-Используйте `workflow eject <skill>` для копирования скила в проект для кастомизации.
-
-### Как работать с коучем
-
-Коуч — мета-скил для создания и улучшения остальных скилов. Правки в `.workflow/src/skills/` делаются **только** через него.
-
-```text
-# Запрос к AI-агенту:
-Загрузи коуча из .workflow/src/skills/coach/SKILL.md и <действие>
-```
-
-Варианты `<действия>`:
-
-| Тип задачи | Пример запроса |
-|------------|----------------|
-| Создать новый скил | `создай скил <имя> для <назначение>` |
-| Аудит существующего | `сделай аудит скила <имя>` |
-| Анализ эффективности | `проанализируй результаты скила <имя> по завершённым тикетам` |
-| Точечное улучшение | `улучши скил <имя>: <что именно>` |
-| Ресерч практик | `найди лучшие практики для <тема> и обогати скил <имя>` |
-| Ревью скила | `сделай ревью скила <имя>` |
-
-Коуч сам определит тип задачи, загрузит нужный воркфлоу, внесёт правку, прогонит тест скила и запишет результат в `.workflow/coach-backlog.yaml`. Коммит делает пользователь.
-
-## Регрессионные тесты скилов
-
-Трёхуровневая система тестирования скилов для проверки качества AI-агентов.
-
-### Три слоя тестирования
-
-| Уровень | Название | Описание |
-|---------|----------|----------|
-| L0 | Static | Базовая проверка синтаксиса и структуры: YAML-валидация, проверка обязательных полей, линтер |
-| L1 | Deterministic | Детерминированные тесты: эталонные входные данные → ожидаемый результат (strict match) |
-| L2 | Rubric | Гибкая оценка по критериям: scorer выставляет баллы на основе качества результата |
-
-### Структура директорий
-
-```
-src/skills/<name>/tests/
-├── index.yaml      # Метаданные тестов, список test cases
-├── cases/          # Входные данные для тестов
-│   └── <case-id>/
-│       └── input.yaml
-├── fixtures/       # Ожидаемые выходные данные (для L1)
-│   └── <case-id>/
-│       └── expected.yaml
-└── rubrics/        # Критерии оценки (для L2)
-    └── <case-id>/
-        └── rubric.yaml
-```
-
-### Запуск тестов
-
-```bash
-npm run test:skills
-```
-
-### CLI-флаги
-
-| Флаг | Описание |
-|------|----------|
-| `--skill <name>` | Запустить тесты только для указанного скила |
-| `--relevant` | Запустить только тесты, соответствующие изменённым файлам |
-| `--establish-baseline` | Запустить тесты и сохранить результаты как baseline |
-| `--baseline-ref <ref>` | Использовать конкретный baseline (коммит, тег) |
-| `--yes` | Автоматически подтверждать все действия |
-
-### Режимы вердикта
-
-| Режим | Описание |
-|-------|----------|
-| `no-baseline` | Первый запуск — результаты сохраняются как baseline без сравнения |
-| `no-regression` | Сравнение с baseline — тест считается пройденным, если результат не хуже baseline |
-
-### Принцип git write
-
-Runner и коуч **не выполняют git write-операций**. Все изменения в кодовой базе делает исключительно пользователь. Runner только анализирует и рекомендует, но не коммитит.
-
-### Первый запуск на новом проекте
-
-1. Запустить тесты с флагом `--establish-baseline`
-2. Проверить результаты: красные тесты — ожидаемы для нового проекта
-3. Зафиксировать baseline: `git commit current/` как baseline-коммит
-
-## Скрипты
-
-Скрипты хранятся глобально в `~/.workflow/scripts/` и подключаются одним junction в `.workflow/src/scripts/`.
-
-Используйте `workflow eject-scripts` для копирования скриптов в проект для кастомизации.
-
-## Конфиги
-
-Конфиги хранятся глобально в `~/.workflow/configs/` и подключаются одним junction в `.workflow/config/`.
-
-Используйте `workflow eject-configs` для копирования конфигов в проект для кастомизации.
-
-## Шаблоны планов
-
-Шаблоны планов позволяют автоматически создавать повторяющиеся планы. Шаблоны лежат в `.workflow/plans/templates/` и содержат условия триггеров во frontmatter.
-
-### Формат шаблона
-
-```yaml
-id: "TMPL-001"
-title: "Daily manual testing"
-type: template
-trigger:
-  type: daily          # daily | weekly | date_after | interval_days
-  params: {}           # параметры, зависящие от типа
-last_triggered: ""     # обновляется автоматически при срабатывании
-enabled: true
-```
-
-### Типы триггеров
-
-| Тип | Параметры | Описание |
-|-----|-----------|----------|
-| `daily` | — | Раз в день |
-| `weekly` | `days_of_week: [1,3,5]` (0=вс) | В указанные дни недели |
-| `date_after` | `date: "2026-04-01"` | Один раз после указанной даты |
-| `interval_days` | `days: 3` | Каждые N дней |
-
-При срабатывании триггера конвейер создаёт план в `plans/current/` со статусом `approved`, далее идёт обычный поток декомпозиции.
-
-## Типы задач
-
-| Тип | Префикс | Описание |
-|-----|---------|----------|
-| `arch` | ARCH | Архитектура и планирование |
-| `impl` | IMPL | Реализация кода |
-| `fix` | FIX | Исправления ошибок |
-| `review` | REVIEW | Ревью кода/документации |
-| `docs` | DOCS | Документация |
-| `admin` | ADMIN | Административные задачи |
-
-## Fallback агентов и правила здоровья
-
-Система включает механизм in-stage fallback и health-мониторинг агентов.
-
-### Механика fallback
-
-Когда агент падает во время выполнения задачи, система использует **artifact-snapshot** для принятия решения:
-- Если snapshot пустой (нет записанных файлов) → выполняется fallback на следующего агента
-- Если snapshot непустой (есть изменения) → задача переходит в состояние `goto.error`
-
-**Пример сценария:** Qwen превысил quota и упал без записи файлов → Kilo вызван в той же попытке, task_attempts не инкрементирован.
-
-Конфигурация snapshot:
-```yaml
-execution:
-  artifact_snapshot_enabled: false  # по умолчанию выключено
-  snapshot_paths: ["src/", "configs/"]  # что мониторить
-  snapshot_max_file_size: 524288  # файлы >512KB — только mtime+size
-```
-
-**Baseline производительности:** `p50=169ms p95=299ms files=598` (из QA-20 benchmark).
-
-### Классификатор ошибок и health-реестр
-
-Ошибки классифицируются по классам:
-- `unavailable` — агент временно недоступен (quota, rate limit)
-- `transient` — временная ошибка сети (timeout, 5xx)
-- `misconfigured` — ошибка конфигурации (401, 403, отсутствует API key)
-- `unmatched` — ошибка не распознана
-
-**Семантика TTL:**
-- `5m` — 5 минут
-- `1h` — 1 час
-- `until_utc_midnight` — до полуночи UTC (минимум 30 минут)
-- `infinite` — навсегда
-
-Файл конфигурации: `configs/agent-health-rules.yaml`. Файл состояния: `.workflow/state/agent-health.json`.
-
-### Команда сброса
-
-```bash
-# показать текущее состояние
-node .workflow/src/scripts/reset-agent-health.js
-
-# сбросить конкретного агента
-node .workflow/src/scripts/reset-agent-health.js --agent qwen-code
-
-# сбросить всех агентов
-node .workflow/src/scripts/reset-agent-health.js --all
-```
-
-### Пример добавления правила
-
-```yaml
-# В configs/agent-health-rules.yaml:
-agents:
-  my-new-agent:
-    rules:
-      - id: "my-agent-quota"
-        class: "unavailable"
-        ttl: "until_utc_midnight"
-        pattern: "quota exceeded|daily limit reached"
-        exit_codes: "any"
-```
-
-## Конфигурация
-
-### `configs/config.yaml`
-
-Основная конфигурация воркфлоу: информация о проекте, типы задач, приоритеты, статусы, типы условий, пути, настройки отчётности.
-
-### `configs/pipeline.yaml`
-
-Определение конвейера: агенты, стадии, управление потоком, goto-логика, стратегии повторов.
-
-#### `manual-gate` stage
-
-`type: manual-gate` — встроенный тип стадии для ручного одобрения. Создаёт файл `.workflow/approvals/{step_id}.json` со статусом `pending` и ждёт решения через polling.
-
-**Поля:**
-- `type: manual-gate` — обязательное, идентификатор типа стадии
-- `poll_interval_ms` — опциональное, интервал опроса в мс (default: 2000, минимум: 100)
-- `timeout_seconds` — опциональное, таймаут в секундах (default: null — без таймаута)
-- `goto.approved` — обязательное, следующая стадия при одобрении
-- `goto.rejected` — обязательное, следующая стадия при отклонении
-- `goto.timeout` — опциональное, следующая стадия при истечении таймаута
-- `goto.aborted` — опциональное, следующая стадия при остановке runner'а (SIGTERM)
-
-**Пример:**
-```yaml
-stages:
-  manual-approve-deploy:
-    type: manual-gate
-    poll_interval_ms: 2000
-    timeout_seconds: 86400
-    goto:
-      approved: continue-deploy
-      rejected: rollback
-      timeout: notify-stuck
-      aborted: end
-```
-
-**Два способа одобрения:**
-1. **Через MCP-клиент** (например `workflow-mcp`): tool `approve_step({step_id, decision, comment})` пишет в файл approval. Опционально — пользователю не обязал подключать MCP.
-2. **Прямая правка файла:** открыть `.workflow/approvals/{step_id}.json`, изменить `"status": "pending"` на `"approved"` или `"rejected"`, сохранить. **Базовый способ, работающий без какой-либо внешней инфраструктуры** — достаточно текстового редактора.
-
-**Важное:** `manual-gate` — **opt-in**. Если ваш pipeline не использует стадии `manual-gate`, поведение полностью идентично предыдущим версиям! Никаких breaking changes.
-
-**Формат approval-файла:**
-```json
-{
-  "step_id": "QA-12_manual-approve_0",
-  "ticket_id": "QA-12",
-  "stage_id": "manual-approve",
-  "attempt": 0,
-  "status": "pending",
-  "created_at": "2026-04-28T12:34:56.789Z",
-  "updated_at": "2026-04-28T12:34:56.789Z",
-  "decided_by": null,
-  "comment": null,
-  "context_snapshot": { ... }
-}
-```
-
-### `configs/ticket-movement-rules.yaml`
-
-Правила автоматического перемещения тикетов на основе статуса ревью.
-
-## Структура проекта
-
-```
-workflow-ai/
-├── bin/                    # Точка входа CLI
-├── src/
-│   ├── cli.mjs             # Парсинг команд
-│   ├── runner.mjs           # Оркестратор конвейера
-│   ├── init.mjs             # Инициализация проекта
-│   ├── global-dir.mjs       # Управление глобальной ~/.workflow/
-│   ├── junction-manager.mjs # Управление junction/symlink
-│   ├── wf-loader.mjs        # Загрузчик конфигов
-│   ├── lib/                 # Библиотеки утилит
-│   └── tests/               # Набор тестов
-├── configs/                # Файлы конфигурации (источник)
-├── templates/              # Шаблоны воркфлоу (источник)
-├── agent-templates/        # Шаблоны инструкций для AI-агентов
-└── package.json
-```
-
-## Требования
-
-- Node.js >= 18.0.0
-- npm
-
-## Лицензия
-
-MIT
+
+- Добавлено упоминание `human-gate` в разделе про runner-стадии (пример конфига в pipeline.yaml: human-review-step типа manual-gate).
+- Добавлено упоминание `mark-blocked` как механизм нотификации autoblocked-тикетов (поля auto_blocked_reason/attempts/at).
+
+## Runner-стадии
+
+В системе поддерживаются различные типы стадий для управления процессами разработки:
+
+### Human Gate
+
+`human-gate` — стадия ручного контроля, которая требует вмешательства человека для продолжения выполнения пайплайна. Используется для критических точек, где необходима ручная проверка или утверждение.
+
+**Условия срабатывания:**
+- Стадия `manual-gate-human` блокирует пайплайн до ручного снятия gate
+- Gate снимается через команду `move-ticket.js <id> unblock`
+- Поддерживает настройку таймаутов и условий повторных попыток
+
+**Пример конфигурации pipeline.yaml:**
+```yaml
+stages:
+  - name: manual-gate-human
+    type: manual-gate-human
+    config:
+      timeout: 3600  # 1 hour
+      max_attempts: 3
+      message: "Requires human approval before deployment"
+```
+
+Пример полного файла `pipeline.yaml` доступен в `docs/samples/pipeline-with-human-gate.yaml`.
+
+### Autoblock notifications
+
+Для автоматического блокировки тикетов при возникновении проблем используется механизм `mark-blocked`. Блокированные тикеты получают дополнительные поля в frontmatter для отслеживания причин и попыток:
+
+- `auto_blocked_reason` — причина автоматической блокировки
+- `auto_blocked_attempts` — количество попыток разблокировки
+- `auto_blocked_at` — время автоматической блокировки

package/configs/pipeline.yaml

@@ -185,6 +185,18 @@ pipeline:
       workdir: "."
       description: "Проверка доступности MCP-серверов"
 
+    script-mark-blocked:
+      command: "node"
+      args: [".workflow/src/scripts/mark-blocked.js"]
+      workdir: "."
+      description: "Обновление frontmatter и запись в alerts.jsonl при автоблокировке"
+
+    script-mark-human-rejected:
+      command: "node"
+      args: [".workflow/src/scripts/mark-blocked.js"]
+      workdir: "."
+      description: "Обновление frontmatter при отклонении human-тикета"
+
     script-verify-artifacts:
       command: "node"
       args: [".workflow/src/skills/review-result/scripts/verify-artifacts.js"]
@@ -274,6 +286,10 @@ pipeline:
             task_type: "$result.type"
             required_capabilities: "$result.required_capabilities"
             target: in-progress
+        human_ready:
+          stage: manual-gate-human
+          params:
+            ticket_id: "$result.ticket_id"
         in_review:
           stage: verify-artifacts
           params:
@@ -487,6 +503,10 @@ pipeline:
             task_type: "$result.type"
             required_capabilities: "$result.required_capabilities"
             target: in-progress
+        human_ready:
+          stage: manual-gate-human
+          params:
+            ticket_id: "$result.ticket_id"
         in_review:
           stage: verify-artifacts
           params:
@@ -649,6 +669,73 @@ pipeline:
             ticket_id: "$context.ticket_id"
             attempt: "$counter.task_attempts"
 
+    # -------------------------------------------------------------------------
+    # 2d. manual-gate-human
+    # Используется для созревших human-тикетов (pick-first-task возвращает human_ready).
+    # Ждёт решения по approval-файлу (approved/rejected/timeout).
+    # -------------------------------------------------------------------------
+    manual-gate-human:
+      description: "Ожидание ручного выполнения созревшего human-тикета"
+      type: manual-gate
+      poll_interval_ms: 2000
+      timeout_seconds: 86400
+      goto:
+        approved: pick-first-task
+        rejected:
+          stage: mark-human-rejected
+          params:
+            ticket_id: "$context.ticket_id"
+        timeout:
+          stage: mark-human-rejected
+          params:
+            ticket_id: "$context.ticket_id"
+            reason: "human_gate_timeout"
+        aborted: end
+
+    # -------------------------------------------------------------------------
+    # 3b. mark-blocked
+    # Записывает причину автоблокировки в frontmatter тикета и эмитит alert
+    # в alerts.jsonl. Вставлен между increment-task-attempts.max_reached и
+    # move-ticket(blocked).
+    # -------------------------------------------------------------------------
+    mark-blocked:
+      description: "Записать причину автоблокировки в frontmatter и эмитить alert"
+      agent: script-mark-blocked
+      timeout: 30
+      goto:
+        default:
+          stage: move-ticket
+          params:
+            ticket_id: "$context.ticket_id"
+            target: blocked
+        error:
+          stage: move-ticket
+          params:
+            ticket_id: "$context.ticket_id"
+            target: blocked
+
+    # -------------------------------------------------------------------------
+    # 3b'. mark-human-rejected
+    # Записывает причину отклонения human-тикета (reject/timeout) и переходит
+    # в move-ticket(blocked). Используется ветками rejected и timeout стейджа
+    # manual-gate-human.
+    # -------------------------------------------------------------------------
+    mark-human-rejected:
+      description: "Записать причину отклонения human-тикета и переместить в blocked"
+      agent: script-mark-human-rejected
+      timeout: 30
+      goto:
+        default:
+          stage: move-ticket
+          params:
+            ticket_id: "$context.ticket_id"
+            target: blocked
+        error:
+          stage: move-ticket
+          params:
+            ticket_id: "$context.ticket_id"
+            target: blocked
+
     # -------------------------------------------------------------------------
     # 3c. verify-artifacts
     # Механическая предпроверка артефактов тикета перед AI-ревью.
@@ -729,10 +816,11 @@ pipeline:
             ticket_id: "$context.ticket_id"
             target: ready
         max_reached:
-          stage: move-ticket
+          stage: mark-blocked
           params:
             ticket_id: "$context.ticket_id"
-            target: blocked
+            attempts: "$counter.task_attempts"
+            reason: "max_review_attempts"
 
     # -------------------------------------------------------------------------
     # 5. move-ticket

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "workflow-ai",
-  "version": "1.2.1",
+  "version": "1.3.0",
   "description": "AI Agent Workflow Coordinator — kanban-based pipeline for AI coding agents",
   "type": "module",
   "bin": {
@@ -36,9 +36,19 @@
   "scripts": {
     "test": "node --test src/tests/*.test.mjs",
     "test:skills": "node src/scripts/run-skill-tests.js --all",
+    "coverage": "c8 node --test src/tests/*.test.mjs",
+    "coverage:mark-blocked": "c8 node --test src/tests/scripts-mark-blocked.test.mjs",
+    "coverage:pick-next-task": "node scripts/coverage-pick-next-task.js",
+    "coverage:move-ticket": "c8 node --test src/tests/scripts-move-ticket-approval-hook.test.mjs",
+    "mutation-test": "stryker run",
     "release": "npm version patch && npm publish"
   },
   "dependencies": {
     "js-yaml": "^4.1.0"
+  },
+  "devDependencies": {
+    "@stryker-mutator/core": "^9.6.1",
+    "@stryker-mutator/javascript-mutator": "^4.0.0",
+    "c8": "^11.0.0"
   }
 }

package/src/runner.mjs

@@ -176,7 +176,8 @@ class Logger {
    */
   stageStart(stageId, agentId, skillId) {
     this.stats.stagesStarted++;
-    this.info(`START stage="${stageId}" agent="${agentId}" skill="${skillId}"`, stageId);
+    const ticketInfo = this.context && this.context.ticket_id ? ` ticket="${this.context.ticket_id}"` : "";
+    this.info(`START stage="${stageId}" agent="${agentId}" skill="${skillId}"${ticketInfo}`, stageId);
   }
 
   /**

package/src/scripts/check-relevance.js

@@ -100,10 +100,12 @@ function findTicketInColumns(ticketId) {
 
 async function checkRelevance(ticketPath) {
   if (!fs.existsSync(ticketPath)) {
+    // file_not_found — это не ошибка скрипта (verdict=relevant — fail-safe).
+    // Не выходим с exit=1, чтобы pipeline продолжил выполнение следующего стейджа.
     return {
       verdict: "relevant",
       reason: "file_not_found",
-      error: `Ticket file not found: ${ticketPath}`,
+      warning: `Ticket file not found: ${ticketPath}`,
     };
   }
 

package/src/scripts/mark-blocked.js

@@ -0,0 +1,160 @@
+#!/usr/bin/env node
+
+/**
+ * mark-blocked.js - Скрипт для обновления frontmatter тикета и записи в alerts.jsonl
+ *
+ * Использование:
+ *   node mark-blocked.js <ticket_id> --attempts=N --reason=<str>
+ *
+ * Примеры:
+ *   node mark-blocked.js IMPL-59 --attempts=6 --reason=max_review_attempts
+ *   node mark-blocked.js QA-40 --attempts=3 --reason=human_gate_rejected
+ */
+
+import fs from "fs";
+import path from "path";
+import YAML from "workflow-ai/lib/js-yaml.mjs";
+import { findProjectRoot } from "workflow-ai/lib/find-root.mjs";
+import {
+  parseFrontmatter,
+  printResult,
+  serializeFrontmatter,
+} from "workflow-ai/lib/utils.mjs";
+
+// Корень проекта
+const PROJECT_DIR = findProjectRoot();
+// Базовая директория workflow
+const WORKFLOW_DIR = path.join(PROJECT_DIR, ".workflow");
+const TICKETS_DIR = path.join(WORKFLOW_DIR, "tickets");
+// Директория state
+const STATE_DIR = path.join(PROJECT_DIR, ".workflow", "state");
+const ALERTS_FILE = path.join(STATE_DIR, "alerts.jsonl");
+
+// Парсинг аргументов
+const args = process.argv.slice(2);
+if (args.length < 3) {
+  console.error("Ошибка: недостаточно аргументов");
+  console.error("Использование: node mark-blocked.js <ticket_id> --attempts=N --reason=<str>");
+  process.exit(1);
+}
+
+const ticketId = args[0];
+let attempts = null;
+let reason = null;
+
+// Парсинг флагов
+for (let i = 1; i < args.length; i++) {
+  const arg = args[i];
+  if (arg.startsWith("--attempts=")) {
+    attempts = parseInt(arg.substring("--attempts=".length), 10);
+    if (isNaN(attempts)) {
+      console.error("Ошибка: некорректный формат --attempts");
+      process.exit(1);
+    }
+  } else if (arg.startsWith("--reason=")) {
+    reason = arg.substring("--reason=".length);
+  }
+}
+
+// Проверка обязательного параметра reason
+if (!reason) {
+  console.error("Ошибка: параметр --reason обязателен");
+  process.exit(1);
+}
+
+// Поиск файла тикета рекурсивно
+function findTicketFile(ticketId, searchDir) {
+  try {
+    const files = fs.readdirSync(searchDir, { withFileTypes: true });
+    
+    for (const file of files) {
+      const fullPath = path.join(searchDir, file.name);
+      
+      if (file.isDirectory()) {
+        // Рекурсивный поиск в поддиректориях
+        const found = findTicketFile(ticketId, fullPath);
+        if (found) return found;
+      } else if (file.isFile() && file.name.endsWith('.md') && file.name.startsWith(ticketId)) {
+        return fullPath;
+      }
+    }
+  } catch (error) {
+    console.error(`Ошибка при чтении директории ${searchDir}:`, error.message);
+  }
+  
+  return null;
+}
+
+// Основная функция
+function main() {
+  try {
+    // Поиск файла тикета
+    const ticketFile = findTicketFile(ticketId, TICKETS_DIR);
+    if (!ticketFile) {
+      console.error(`Ошибка: тикет ${ticketId} не найден в ${TICKETS_DIR}`);
+      process.exit(1);
+    }
+
+    // Чтение файла тикета
+    const content = fs.readFileSync(ticketFile, 'utf8');
+    const { frontmatter, body } = parseFrontmatter(content);
+
+    // Обновление frontmatter
+    const now = new Date().toISOString();
+    frontmatter.auto_blocked_reason = reason;
+    frontmatter.auto_blocked_attempts = attempts;
+    frontmatter.auto_blocked_at = now;
+
+    // Сериализация и запись обратно в файл
+    const newContent = serializeFrontmatter(frontmatter) + body;
+    fs.writeFileSync(ticketFile, newContent, 'utf8');
+
+    console.log(`✅ Frontmatter тикета ${ticketId} обновлен`);
+
+    // Попытка записи в alerts.jsonl
+    try {
+      // Создание директории state если не существует
+      if (!fs.existsSync(STATE_DIR)) {
+        fs.mkdirSync(STATE_DIR, { recursive: true });
+        console.log(`✅ Директория ${STATE_DIR} создана`);
+      }
+
+      // Формирование JSONL записи
+      const alertEntry = {
+        timestamp: now,
+        severity: "warning",
+        kind: "ticket_auto_blocked",
+        project: path.basename(PROJECT_DIR),
+        ticket_id: ticketId,
+        attempts: attempts,
+        reason: reason,
+        stage: "review-result"
+      };
+
+      // Append-only запись в alerts.jsonl
+      fs.appendFileSync(ALERTS_FILE, JSON.stringify(alertEntry) + '\n', 'utf8');
+      console.log(`✅ Запись добавлена в ${ALERTS_FILE}`);
+
+    } catch (alertError) {
+      console.warn(`⚠️  Предупреждение: не удалось записать в alerts.jsonl: ${alertError.message}`);
+      console.log(`ℹ️  Frontmatter обновлен, запись в alerts пропущена`);
+    }
+
+    // Вывод результата
+    printResult({
+      ticket_id: ticketId,
+      reason: reason,
+      attempts: attempts,
+      blocked_at: now,
+      alerts_file: ALERTS_FILE,
+      status: "completed"
+    });
+
+  } catch (error) {
+    console.error(`Ошибка: ${error.message}`);
+    process.exit(1);
+  }
+}
+
+// Запуск скрипта
+main();

package/src/scripts/move-ticket.js

@@ -12,6 +12,7 @@
 
 import fs from "fs";
 import path from "path";
+import { fileURLToPath } from "url";
 import YAML from "workflow-ai/lib/js-yaml.mjs";
 import { findProjectRoot } from "workflow-ai/lib/find-root.mjs";
 import {
@@ -21,6 +22,11 @@ import {
   getLastReviewStatus,
 } from "workflow-ai/lib/utils.mjs";
 
+const logger = {
+  info: (msg) => console.error(`[INFO] ${msg}`),
+  warn: (msg) => console.error(`[WARN] ${msg}`),
+};
+
 // Корень проекта
 const PROJECT_DIR = findProjectRoot();
 // Базовая директория workflow
@@ -89,6 +95,45 @@ function isValidTransition(from, to) {
   return { valid: true };
 }
 
+/**
+ * Hook для обновления approval-файлов при перемещении тикета
+ * @param {string} ticketId - ID тикета
+ * @param {string} target - целевой статус
+ * @param {object} fsModule - модуль fs (для mock в тестах)
+ * @param {string} workflowDir - директория .workflow
+ */
+function updateApprovalFilesHook(ticketId, target, fsModule = fs, workflowDir = WORKFLOW_DIR) {
+  try {
+    const approvalsDir = path.join(workflowDir, "approvals");
+    if (fsModule.existsSync(approvalsDir)) {
+      const files = fsModule.readdirSync(approvalsDir);
+      const escapedTicketId = ticketId.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
+      const pattern = new RegExp(`^${escapedTicketId}_manual-gate-.*_\\d+\\.json$`);
+      for (const file of files) {
+        if (!pattern.test(file)) continue;
+        const filePath = path.join(approvalsDir, file);
+        try {
+          const data = JSON.parse(fsModule.readFileSync(filePath, "utf8"));
+          if (data.status === "pending") {
+            data.status = "approved";
+            data.decided_by = "move-ticket";
+            data.comment = `auto-approved on move to ${target}`;
+            data.updated_at = new Date().toISOString();
+            fsModule.writeFileSync(filePath, JSON.stringify(data, null, 2), "utf8");
+            logger.info(`Approval file ${file} auto-approved on move to ${target}`);
+          }
+        } catch (err) {
+          logger.warn(`Corrupt approval file ${file}: ${err.message}`);
+          // продолжаем, не падаем
+        }
+      }
+    }
+  } catch (err) {
+    // Ошибка hook'а не должна фейлить само перемещение
+    logger.warn(`Approval hook error: ${err.message}`);
+  }
+}
+
 /**
  * Основная функция перемещения тикета
  */
@@ -210,6 +255,9 @@ async function moveTicket(ticketId, target) {
     };
   }
 
+  // Hook: обновление approval-файлов (если есть) — срабатывает на любой move
+  updateApprovalFilesHook(ticketId, target);
+
   return {
     status: "moved",
     ticket_id: ticketId,
@@ -218,43 +266,60 @@ async function moveTicket(ticketId, target) {
   };
 }
 
-// Main entry point
-const rawArgs = process.argv.slice(2);
-let ticketId, target;
-
-if (rawArgs.length >= 2) {
-  // Прямой вызов: node move-ticket.js IMPL-001 in-progress
-  ticketId = rawArgs[0];
-  target = rawArgs[1];
-} else if (rawArgs.length === 1) {
-  // Вызов через pipeline runner: один аргумент — промпт с контекстом
-  // Формат: "skill-name\n\nContext:\n  ticket_id: X\n  target: Y\n..."
-  const prompt = rawArgs[0];
-  const ticketMatch = prompt.match(/ticket_id:\s*(\S+)/);
-  const targetMatch = prompt.match(/target:\s*(\S+)/);
-  ticketId = ticketMatch?.[1];
-  target = targetMatch?.[1];
-  if (!ticketId || !target) {
-    console.error(
-      "[ERROR] Cannot parse ticket_id or target from pipeline context",
-    );
-    printResult({
-      status: "error",
-      error: "Missing ticket_id or target in pipeline context",
-    });
-    process.exit(1);
+// Export for testing
+export { moveTicket, updateApprovalFilesHook };
+
+// Main entry point — guard prevents execution when imported as module in tests.
+// Используем fs.realpathSync чтобы корректно сравнивать пути на Windows когда .workflow/src/scripts/ — junction.
+// Без realpathSync argv[1] = путь через junction, а import.meta.url = разрешённый target — строки не совпадают.
+function __isMainModule() {
+  try {
+    const argvPath = fs.realpathSync(path.resolve(process.argv[1] || ""));
+    const metaPath = fileURLToPath(import.meta.url);
+    return argvPath === metaPath;
+  } catch {
+    return false;
   }
-} else {
-  console.error("Usage: node move-ticket.js <ticket_id> <target>");
-  console.error("Example: node move-ticket.js IMPL-001 in-progress");
-  console.error("Available targets:", VALID_STATUSES.join(", "));
-  printResult({ status: "error", error: "Missing arguments" });
-  process.exit(1);
 }
 
-moveTicket(ticketId, target).then((result) => {
-  printResult(result);
-  if (result.status === "error") {
+if (__isMainModule()) {
+  const rawArgs = process.argv.slice(2);
+  let ticketId, target;
+
+  if (rawArgs.length >= 2) {
+    // Прямой вызов: node move-ticket.js IMPL-001 in-progress
+    ticketId = rawArgs[0];
+    target = rawArgs[1];
+  } else if (rawArgs.length === 1) {
+    // Вызов через pipeline runner: один аргумент — промпт с контекстом
+    // Формат: "skill-name\n\nContext:\n  ticket_id: X\n  target: Y\n..."
+    const prompt = rawArgs[0];
+    const ticketMatch = prompt.match(/ticket_id:\s*(\S+)/);
+    const targetMatch = prompt.match(/target:\s*(\S+)/);
+    ticketId = ticketMatch?.[1];
+    target = targetMatch?.[1];
+    if (!ticketId || !target) {
+      console.error(
+        "[ERROR] Cannot parse ticket_id or target from pipeline context",
+      );
+      printResult({
+        status: "error",
+        error: "Missing ticket_id or target in pipeline context",
+      });
+      process.exit(1);
+    }
+  } else {
+    console.error("Usage: node move-ticket.js <ticket_id> <target>");
+    console.error("Example: node move-ticket.js IMPL-001 in-progress");
+    console.error("Available targets:", VALID_STATUSES.join(", "));
+    printResult({ status: "error", error: "Missing arguments" });
     process.exit(1);
   }
-});
+
+  moveTicket(ticketId, target).then((result) => {
+    printResult(result);
+    if (result.status === "error") {
+      process.exit(1);
+    }
+  });
+}

package/src/scripts/pick-next-task.js

@@ -567,28 +567,25 @@ function pickNextTicket(planId) {
     return { status: 'empty', reason: 'No tickets in ready/' };
   }
 
-  // Фильтрация по условиям и зависимостям
-  const eligibleTickets = tickets.filter(ticket => {
+  // Фильтрация: разделяем на обычные и human с проверкой условий/зависимостей
+  const eligibleNonHuman = [];
+  const humanCandidates = [];
+  
+  for (const ticket of tickets) {
     const { frontmatter } = ticket;
 
-    // Пропускаем тикеты, требующие ручного выполнения
-    if (frontmatter.type === 'human') {
-      logger.info(`Skipping ticket ${ticket.id}: type is 'human' (requires manual execution)`);
-      return false;
-    }
-
     // Проверка условий
     const conditions = frontmatter.conditions || [];
     const conditionsMet = conditions.every(checkCondition);
     if (!conditionsMet) {
-      return false;
+      continue;
     }
 
     // Проверка зависимостей
     const dependencies = frontmatter.dependencies || [];
     const depsMet = checkDependencies(dependencies);
     if (!depsMet) {
-      return false;
+      continue;
     }
 
     // Обнаружение и удаление дубликатов: тикет не должен существовать в других колонках
@@ -607,46 +604,75 @@ function pickNextTicket(planId) {
       } catch (err) {
         logger.error(`Failed to archive duplicate ${ticket.id}: ${err.message}`);
       }
-      return false;
+      continue;
     }
 
-    return true;
-  });
+    // Разделение по типу
+    if (frontmatter.type === 'human') {
+      humanCandidates.push(ticket);
+    } else {
+      eligibleNonHuman.push(ticket);
+    }
+  }
+
+  // Имеются ли обычные (non-human) готовые тикеты — старший приоритет
+  if (eligibleNonHuman.length > 0) {
+    eligibleNonHuman.sort((a, b) => {
+      const priorityA = a.frontmatter.priority || 999;
+      const priorityB = b.frontmatter.priority || 999;
 
-  if (eligibleTickets.length === 0) {
+      if (priorityA !== priorityB) {
+        return priorityA - priorityB;
+      }
+
+      const dateA = new Date(a.frontmatter.created_at || '9999-12-31');
+      const dateB = new Date(b.frontmatter.created_at || '9999-12-31');
+      return dateA - dateB;
+    });
+
+    const selected = eligibleNonHuman[0];
     return {
-      status: 'empty',
-      reason: 'No eligible tickets (conditions/dependencies not met)'
+      status: 'found',
+      ticket_id: selected.id,
+      priority: selected.frontmatter.priority,
+      title: selected.frontmatter.title,
+      type: selected.frontmatter.type,
+      required_capabilities: JSON.stringify(selected.frontmatter.required_capabilities || [])
     };
   }
 
-  // Сортировка по приоритету (меньше = важнее), затем по created_at
-  eligibleTickets.sort((a, b) => {
-    const priorityA = a.frontmatter.priority || 999;
-    const priorityB = b.frontmatter.priority || 999;
+  // Если есть созревшие human-тикеты — новый статус human_ready (для manual-gate)
+  if (humanCandidates.length > 0) {
+    humanCandidates.sort((a, b) => {
+      const priorityA = a.frontmatter.priority || 999;
+      const priorityB = b.frontmatter.priority || 999;
 
-    if (priorityA !== priorityB) {
-      return priorityA - priorityB;
-    }
+      if (priorityA !== priorityB) {
+        return priorityA - priorityB;
+      }
 
-    // При равном приоритете - по дате создания (старые первые)
-    const dateA = new Date(a.frontmatter.created_at || '9999-12-31');
-    const dateB = new Date(b.frontmatter.created_at || '9999-12-31');
-    return dateA - dateB;
-  });
+      const dateA = new Date(a.frontmatter.created_at || '9999-12-31');
+      const dateB = new Date(b.frontmatter.created_at || '9999-12-31');
+      return dateA - dateB;
+    });
 
-  const selected = eligibleTickets[0];
+    const selected = humanCandidates[0];
+    return {
+      status: 'human_ready',
+      ticket_id: selected.id,
+      priority: selected.frontmatter.priority,
+      title: selected.frontmatter.title,
+      pending_count: humanCandidates.length
+    };
+  }
 
   return {
-    status: 'found',
-    ticket_id: selected.id,
-    priority: selected.frontmatter.priority,
-    title: selected.frontmatter.title,
-    type: selected.frontmatter.type,
-    required_capabilities: JSON.stringify(selected.frontmatter.required_capabilities || [])
+    status: 'empty',
+    reason: 'No eligible non-human tickets (and no ready human tickets)'
   };
 }
 
+
 /**
  * Архивирует все done-тикеты, принадлежащие архивным планам (plans/archive/).
  * Сканирует все планы в plans/archive/, находит их тикеты в done/ и перемещает в archive/.
@@ -778,6 +804,9 @@ async function main() {
   }
 }
 
+// Экспортируем функции для тестирования
+export { pickNextTicket, readReadyTickets, readReviewTickets, readInProgressTickets, findCompletedInProgress, filterByPlan };
+
 main().catch(e => {
   logger.error(e.message);
   printResult({ status: 'error', error: e.message });

package/src/skills/__test-cal-001-1777553217513/SKILL.md

@@ -0,0 +1,2 @@
+# Calibration Test Skill
+version: 1.0

package/src/skills/__test-runner-1777553217483/SKILL.md

@@ -0,0 +1,5 @@
+# Test Skill
+
+SIGNATURE_PRESENT
+SomeOtherContent
+version: 1.0

package/src/skills/coach/SKILL.md

@@ -123,7 +123,7 @@ ticket_prefix: COACH
 
 ## Принципы
 
-1. **Root Cause First** — при обнаружении проблемы в артефакте (тикете, плане, отчёте) всегда определи скил-источник, который создал этот артефакт, и предложи исправить **скил** первым. Не предлагай ручную правку артефактов (последствий), пока корневая причина (скил) не исправлена. Порядок действий: (1) найти скил-источник → (2) проследить цепочку вверх: если артефакт-источник (план, шаблон) уже содержал дефект — root cause в скиле, создавшем **его**, а не в скиле-обработчике → (3) исправить скил → (4) если нужно, предложить пересоздать артефакт исправленным скилом. **Антипаттерн «остановка на ближайшем скиле»:** тикет неатомарен → правишь декомпозитор. Но если задача **плана** уже неатомарна — root cause в скиле планирования, декомпозитор — вторая линия обороны. **Антипаттерн:** если данные невалидны — root cause в том, кто/что генерирует данные (шаблон, скил, воркфлоу), а НЕ в обработчике данных (скрипт, парсер). Не правь обработчик под невалидный формат — исправь источник формата. **⚠️ Обязательно перед правкой:** прочитай лог или артефакт до конца — определи точный паттерн нарушения (кто, когда, что именно записал). Гипотеза о root cause без evidence из лога — не основание для правки. **Семантика первична:** перед диагностикой сформулируй назначение скила одним предложением (что он должен решать, что НЕ должен). Если поведение противоречит назначению — это ошибка в скиле, не в смежных компонентах. **⚠️ Физический автор ≠ семантический владелец:** при определении скила-источника ищи не «кто владеет предметной областью артефакта», а **кто физически записывает** (Edit/Write) проблемный фрагмент. Если скил A выполняет предметную работу, но скил B записывает результат в тикет — root cause в инструкциях скила B, а не A. Антипаттерн: «тикет предметной области X → правлю скил предметной области», хотя физическую запись в тикет выполняет скил-исполнитель. **⛔ Повторный инцидент по той же корневой проблеме:** перед формулированием правки **обязательно** прогрепай `coach-backlog.yaml` на ключевые термины текущей проблемы (имя скила-жертвы, имя нарушенного правила, имя задействованной нормы). Если обнаружен CHG за последние 30 дней на тот же скил и ту же корневую проблему — это сигнал, что **текстовое усиление инструкции не работает** (предыдущий текст уже содержал норму, но нарушитель её проигнорировал). В этом случае: (а) ещё одна текстовая правка того же скила — недостаточная мера; (б) обязательно создай тикет эскалации стейкхолдеру с рекомендацией ввести **машинную защиту**, не зависящую от дисциплины агента (валидация пайплайном, пост-гейт-стадия, автоматический откат, инфраструктурная проверка); (в) в тикете явно опиши, что попытки дисциплинарного усиления исчерпаны, и почему только машинная защита закрывает класс ошибки. Текстовую правку всё равно применяй — она страхует дисциплинированного агента, — но **не считай её решением проблемы**, пока машинная защита не введена. Антипаттерн: «усилю формулировку ещё жёстче, напишу ⛔ крупнее» — агент, который не прочитал прошлую норму, не прочитает и новую.
+1. **Root Cause First** — при обнаружении проблемы в артефакте (тикете, плане, отчёте) всегда определи скил-источник, который создал этот артефакт, и предложи исправить **скил** первым. Не предлагай ручную правку артефактов (последствий), пока корневая причина (скил) не исправлена. Порядок действий: (1) найти скил-источник → (2) проследить цепочку вверх: если артефакт-источник (план, шаблон) уже содержал дефект — root cause в скиле, создавшем **его**, а не в скиле-обработчике → (3) исправить скил → (4) если нужно, предложить пересоздать артефакт исправленным скилом. **Антипаттерн «остановка на ближайшем скиле»:** тикет неатомарен → правишь декомпозитор. Но если задача **плана** уже неатомарна — root cause в скиле планирования, декомпозитор — вторая линия обороны. **Антипаттерн:** если данные невалидны — root cause в том, кто/что генерирует данные (шаблон, скил, воркфлоу), а НЕ в обработчике данных (скрипт, парсер). Не правь обработчик под невалидный формат — исправь источник формата. **⚠️ Обязательно перед правкой:** прочитай лог или артефакт до конца — определи точный паттерн нарушения (кто, когда, что именно записал). Гипотеза о root cause без evidence из лога — не основание для правки. **Семантика первична:** перед диагностикой сформулируй назначение скила одним предложением (что он должен решать, что НЕ должен). Если поведение противоречит назначению — это ошибка в скиле, не в смежных компонентах. **⚠️ Физический автор ≠ семантический владелец:** при определении скила-источника ищи не «кто владеет предметной областью артефакта», а **кто физически записывает** (Edit/Write) проблемный фрагмент. Если скил A выполняет предметную работу, но скил B записывает результат в тикет — root cause в инструкциях скила B, а не A. Антипаттерн: «тикет предметной области X → правлю скил предметной области», хотя физическую запись в тикет выполняет скил-исполнитель. **⛔ Повторный инцидент по той же корневой проблеме:** перед формулированием правки **обязательно** прогрепай `coach-backlog.yaml` на ключевые термины текущей проблемы (имя скила-жертвы, имя нарушенного правила, имя задействованной нормы). Если обнаружен CHG за последние 30 дней на тот же скил и ту же корневую проблему — **сначала сравни даты выполнения тикета-нарушителя и применения предыдущего CHG, до классификации «повторный инцидент»**. Источники дат: для CHG — `git log` на файл скила (commit-дата правки) или `analyzed_tickets.analyzed_date` в `coach-backlog.yaml`; для тикета — `updated_at`/`completed_at` в frontmatter или ближайшие временные метки в логе пайплайна, где произошёл инцидент (стадии execute-task / review-result, дата записи `## Ревью`). **Если выполнение тикета предшествует дате CHG** — это **не** повторный инцидент: тикет проходил пайплайн до того, как текстовое усиление было применено, нарушение исторически объяснимо (фикса ещё не существовало). Класс — обычный новый, эскалация на машинную защиту **не нужна**, обработай как стандартный CHG. **Только если выполнение тикета строго ПОСЛЕ даты CHG** — это сигнал, что **текстовое усиление инструкции не работает** (предыдущий текст уже содержал норму, но нарушитель её проигнорировал). В этом случае: (а) ещё одна текстовая правка того же скила — недостаточная мера; (б) обязательно создай тикет эскалации стейкхолдеру с рекомендацией ввести **машинную защиту**, не зависящую от дисциплины агента (валидация пайплайном, пост-гейт-стадия, автоматический откат, инфраструктурная проверка); (в) в тикете явно опиши, что попытки дисциплинарного усиления исчерпаны, и почему только машинная защита закрывает класс ошибки. Текстовую правку всё равно применяй — она страхует дисциплинированного агента, — но **не считай её решением проблемы**, пока машинная защита не введена. Антипаттерн 1: «усилю формулировку ещё жёстче, напишу ⛔ крупнее» — агент, который не прочитал прошлую норму, не прочитает и новую. Антипаттерн 2: классифицировать «повторный инцидент» по факту повторяемости пары (скил, класс ошибки) **без сравнения дат** CHG и выполнения тикета. Эскалация без date-check — преждевременная: возможно, тикет проходил пайплайн ещё до текстового усиления, и фикс не имел шанса сработать. **Date-check — необходимое, но не достаточное условие.** Дополнительно сверь **семантический класс ошибки** предыдущего CHG и текущего инцидента: даже если выполнение тикета строго после CHG, инцидент может быть другого класса (CHG покрывал ортогональную проблему — например, semantic-mismatch vs structural-integrity, test-isolation vs review-rubric). Тогда это новый класс, а не повторный инцидент, и эскалация не требуется. Условие эскалации: **(дата выполнения > дата CHG) И (семантический класс совпадает)**.
 2. **Evidence-Based** — все выводы основаны на данных из завершённых тикетов, планов и логов пайплайна, а не на предположениях. **При анализе лога обязательно строй временную диаграмму ключевых событий по ID артефакта** (тикет, план, отчёт): проследи всю цепочку перемещений/изменений артефакта от первого упоминания до последнего, обращая внимание на события, отстоящие далеко друг от друга по времени, но связанные одним ID. **Антипаттерн:** прочитал начало лога (события archive/cleanup), прочитал середину (события create/decompose), но **не сопоставил** их — упустил коллизию ID или другой паттерн взаимного влияния. Перед формулированием findings задай себе вопрос: «Я проверил всю историю каждого упомянутого ID, или только последнее событие с ним?» **⚠️ Проверка фактической практики перед нормативной правкой:** если правка вводит новое правило про путь, имя, формат, расположение — **обязательно `Grep` по всему проекту** (код, конфиги, скилы, тикеты) на ключевой термин этого правила, чтобы измерить **масштаб уже существующей практики**. Один-два аномальных артефакта — не основание объявлять их новой нормой. Если фактическая практика противоположна гипотезе — гипотеза неверна, или (если стейкхолдер действительно хочет миграцию) нужен явный миграционный план и согласие на масштаб правок. Антипаттерн: получил короткий ответ стейкхолдера на развилку → принял за сильное правило → пошёл править скилы → не проверил, что в проекте 20+ артефактов уже живут по противоположному правилу. Перед каждой нормативной правкой задай себе вопрос: «Сколько уже существующих файлов/строк проекта противоречат тому, что я собираюсь записать?» Если ответ > 5 — остановись и переспроси у стейкхолдера, точно ли это миграция. **⚠️ Обязательный diff формулировок при анализе цепочки артефактов:** когда анализируешь инцидент, прошедший через несколько стадий (план → тикет → исполнение → ревью), **перед назначением виновного** обязан построчно сопоставить формулировки критериев на каждом стыке: (1) дословная строка критерия в плане, (2) дословная строка в тикете, (3) что реально проверяет assertion/тест, (4) что ревьюер проверял. Виновник — стадия, на которой произошла первая потеря семантики. Антипаттерн: прочитал план и увидел расхождение с результатом → обвинил последнюю стадию (ревьюера), не проверив, на какой промежуточной стадии формулировка была ослаблена. Гипотеза «ревьюер должен был поймать» невалидна, если ревьюер работал по формулировке тикета, а тикет уже не содержал потерянного уточнения.
 **⚠️ Антипаттерн «уход в формулировки вместо root cause»:** стейкхолдер задаёт вопрос о наблюдаемом дефекте («почему не поймали?»), а коуч анализирует текст формулировок, семантику переносов, чеклисты — вместо того чтобы ответить на прямой вопрос: какой конкретный шаг в какой конкретной стадии не выполнил конкретное физическое действие (открыть файл, посмотреть на картинку, запустить команду). Формулировки — это причина второго порядка; причина первого порядка — «агент X не сделал действие Y». Всегда начинай с причины первого порядка, потом объясняй, почему инструкции это допустили.
 **⚠️ Антипаттерн «оценка по результату вместо сверки с инструкцией»:** при анализе действия агента — **не оценивай** его «разумность» или «допустимость» по своему суждению. Вместо этого открой скил агента и **дословно сверь** действие с инструкцией. Если инструкция говорит «разбей тикет», а агент объединил шаги — это нарушение, даже если результат выглядит «приемлемо». Коуч не имеет права смягчать finding на основании того, что дефект «небольшой» или «единичный» — скил либо нарушен, либо нет.

package/src/skills/execute-task/SKILL.md

@@ -197,7 +197,7 @@ description: >
 
 1. **Ни одного чекбокса `[ ]`** в секции критериев готовности / DoD. Все переведены в `[x]` или помечены причиной невыполнения (`[x] Пункт — не применимо: <причина>`).
 2. **Секция `## Result` / `## Результат выполнения` физически заполнена** — содержит реальный текст (summary, изменённые файлы, заметки), а не оставлена в виде скелета-шаблона с `### Что сделано\n- ...`.
-3. **Frontmatter не содержит добавленных строк `status:` или `completed_at:`** (эти поля устанавливает только пайплайн).
+3. **Frontmatter не модифицирован вообще** — никаких новых ключей, никаких изменённых значений (включая `notes`, `tags`, `context.*`). Frontmatter — собственность создателя тикета и пайплайна. Эта проверка шире, чем запрет на `status:` и `completed_at:` (см. ограничение #5): любая правка frontmatter — потенциально источник YAML-несовместимостей (двоеточие+пробел в неэкранированном скаляре, дубль ключа, нарушенный отступ массива). Если необходимо зафиксировать прогресс/итерации/наблюдения — пиши в **тело тикета** (секции Result/Заметки), не в frontmatter.
 
 Если хоть один пункт нарушен — **вернись к шагу 5 или 7** и выполни правки инструментом `Edit` на файл тикета. Не обходи эту проверку: вывод `---RESULT---` при пустом Result или `[ ]`-чекбоксах считается **призрачным выполнением** (см. ограничение #9) и ведёт к retry → blocked.
 

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

@@ -57,7 +57,29 @@ description: >
 
 ## Шаги проверки
 
-### 0. Быстрый выход
+### 0. Целостность frontmatter (pre-flight)
+
+Перед любой содержательной проверкой убедись, что frontmatter тикета **валидно парсится** YAML-парсером. Запусти:
+
+```
+node -e "const y=require('js-yaml'),f=require('fs');const c=f.readFileSync(process.argv[1],'utf8');const m=c.match(/^---\\n([\\s\\S]*?)\\n---/);if(!m){console.log('NO_FRONTMATTER');process.exit(1)}try{y.load(m[1]);console.log('OK')}catch(e){console.log('YAML_ERROR:'+e.message);process.exit(2)}" .workflow/tickets/in-progress/{TICKET-ID}.md
+```
+
+(или эквивалент в проекте — `js-yaml.load` секции между `---`).
+
+Если parse возвращает ошибку (`duplicated mapping key`, `bad indentation`, `:` followed by space в неэкранированном скаляре и т.п.) — **немедленный fail**:
+
+```
+---RESULT---
+status: failed
+issues:
+  - "Frontmatter тикета невалиден: <текст YAML-ошибки>. Файл нельзя смержить в done — downstream MCP-ресурсы (workflow://human-queue, alerts) падают на парсинге. Исправить frontmatter и перезапустить."
+---RESULT---
+```
+
+Не пытайся «прочесть содержимое глазами» и одобрить — структурно повреждённый frontmatter ломает скрипты пайплайна и MCP-ресурсы.
+
+### 0.1. Быстрый выход
 
 Прочитай тикет. Если секция `## Ревью` существует и последняя запись — `passed` или `⏭ skipped` → немедленно верни `status: passed`.