workflow-ai 1.0.63 → 1.0.65

package/src/skills/deep-research/workflows/trend.md

@@ -0,0 +1,40 @@
+# Воркфлоу: TREND — Исследование трендов
+
+Выявление и анализ трендов в индустрии: что меняется, куда движется рынок.
+
+## Алгоритм выполнения
+
+### 1. Определи скоуп
+
+- Какая индустрия/ниша
+- Временной горизонт (текущие тренды, прогнозы)
+- Контекст заказчика (зачем нужны тренды)
+
+### 2. Собери данные о трендах
+
+Источники:
+1. Google Trends — динамика поисковых запросов
+2. Отраслевые отчёты — прогнозы аналитиков
+3. Конференции/вебинары — темы докладов
+4. Инвестиции/стартапы — куда идут деньги (Crunchbase, PitchBook)
+5. Технологические блоги — emerging tech
+6. Регуляторные изменения — новые законы, стандарты
+
+### 3. Классифицируй тренды
+
+| Категория | Описание |
+|-----------|----------|
+| **Mega-trend** | Фундаментальный сдвиг (5+ лет) |
+| **Macro-trend** | Устойчивое направление (2-5 лет) |
+| **Micro-trend** | Текущая волна (6-24 мес) |
+| **Fad** | Краткосрочный хайп (< 6 мес) |
+
+### 4. Оцени каждый тренд
+
+- Стадия: emerging → growing → mature → declining
+- Импакт на бизнес заказчика: HIGH/MEDIUM/LOW
+- Timeframe: когда станет критичным
+
+### 5. Завершение → `workflows/base-checklist.md`
+
+Дополнительно проверь: тренды классифицированы, импакт и timeframe указаны, факты отделены от прогнозов.

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

@@ -0,0 +1,44 @@
+# Execute-task
+
+Скил исполнения задач из тикетов workflow. Берёт тикет из `in-progress/`, выполняет работу и записывает результат.
+
+## Структура
+
+```
+execute-task/
+├── SKILL.md                    # Ядро: роль, ограничения, принципы
+├── README.md                   # Этот файл
+├── algorithms/
+│   └── execution-strategy.md   # Стратегия анализа, выполнения и верификации задачи
+├── workflows/
+│   └── execute.md              # Единый универсальный воркфлоу выполнения
+└── knowledge/
+    └── ticket-structure.md     # Структура тикета, поля и их семантика
+```
+
+## Как это работает
+
+1. **Читает тикет** из `in-progress/` по `ticket_id` из контекста
+2. **Определяет подход** по описанию и DoD тикета (не по типу)
+3. **Изучает контекст** — читает файлы из `context.files`
+4. **Выполняет работу** по шагам воркфлоу
+5. **Проверяет DoD** — все критерии готовности должны быть выполнены
+6. **Записывает результат** в секцию Result тикета
+7. **НЕ перемещает тикет** — это делает pipeline автоматически
+
+## Принцип работы
+
+Скил **не знает** о типах задач проекта (`impl`, `qa`, `admin` и т.д.). Маршрутизация агентов по типам — ответственность pipeline (`pipeline.yaml:agent_by_type`). Скил работает одинаково для любого типа: читает тикет → понимает задачу из описания → выполняет → проверяет DoD.
+
+## Как расширять
+
+### Добавить knowledge-модуль
+
+1. Создать файл в `knowledge/` (например, `knowledge/code-standards.md`)
+2. Добавить запись в таблицу «Загрузка знаний» в `SKILL.md`
+3. Добавить маркер расширения: `<!-- РАСШИРЕНИЕ: ... -->`
+
+### Примеры расширений
+
+- `knowledge/code-standards.md` — стандарты кода проекта
+- `knowledge/testing-guide.md` — руководство по тестированию

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

@@ -0,0 +1,292 @@
+---
+name: execute-task
+description: >
+  Скил исполнения задач из тикетов workflow. Читает тикет из in-progress,
+  выполняет работу по описанию и DoD тикета, проверяет критерии готовности
+  и записывает результат. Перемещение тикета выполняется отдельным stage.
+---
+
+# Execute-task — Agent Skill
+
+## Роль
+
+Ты — исполнитель задач. Твоя задача — взять тикет из `in-progress/`, выполнить описанную работу и записать результат.
+
+**Ты делаешь:** чтение тикета, анализ контекста, выполнение работы по описанию и DoD, проверка критериев готовности, запись результата.
+
+**Ты НЕ делаешь:** создание тикетов, создание планов, перемещение тикетов, обновление статусов в frontmatter.
+
+## ⛔ КРИТИЧЕСКИЕ ОГРАНИЧЕНИЯ
+
+**Execute-task — скил ИСПОЛНЕНИЯ. Он НЕ создаёт артефакты workflow.**
+
+При выполнении задачи **КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО:**
+
+1. **Создавать файлы тикетов** в `.workflow/tickets/` (любая папка: backlog, ready, in-progress, review, done). Запрет распространяется не только на физическое создание файла — **запрещено также и словесно предлагать/декларировать** создание нового тикета в stdout-ответе или в секции Result: фразы вида «заведу отдельный тикет», «создам bug-report», «оформлю дефект как отдельный тикет», «рекомендую создать дефект-тикет» — эквивалент нарушения. Обнаруженный дефект фиксируется **внутри текущего тикета** (в его Result / Заметках). Если по итогам работы действительно нужна следующая задача — формулируй её как рекомендацию в секции `### Рекомендации для следующего плана`, не упоминая слово «тикет» в повелительной/будущей форме.
+2. **Создавать файлы планов** в `.workflow/plans/`
+3. **Вызывать скилы** декомпозиции, создания плана
+4. **Интерпретировать DoD буквально**, если DoD содержит «создать тикеты» или «декомпозировать в тикеты» — это рекомендация для следующего плана, а НЕ инструкция к действию
+5. **Перемещать тикет или менять его статус** — запрещено перемещать файл (mv, rename, Write в другую папку), вызывать `move-ticket.js`, а также **любым способом записывать поля `status` и `completed_at` в файл тикета** — ни обновление существующих, ни добавление новых строк. Эти поля управляются исключительно скриптами пайплайна.
+   ⛔ **Антипаттерн (ломает пайплайн):**
+   ```yaml
+   tags:
+     - cleanup
+   status: done           # ← ЗАПРЕЩЕНО: агент дописал → дубль ключа → скрипт падает
+   completed_at: "..."    # ← ЗАПРЕЩЕНО
+   ```
+   Скрипты пайплайна парсят frontmatter через строгий YAML-парсер — дублирующий ключ вызывает исключение `duplicated mapping key` и тикет застревает в текущей директории навсегда.
+6. **Заполнять секцию `## Ревью`** в тикете — это компетенция только скила ревью
+7. **Создавать вспомогательные файлы вне scope тикета** — если для выполнения задачи не хватает инфраструктуры (нет доступа к API, нет нужного инструмента), зафиксируй `status: blocked` с причиной. Признак нарушения: создаёшь файл, не описанный в тикете и не являющийся прямым deliverable задачи — зафиксируй blocked вместо создания обходного решения.
+ 8. **Создавать итерационные дубли файлов** (суффиксы `-v2`, `-v3`, `-fixed`, `-manual` и т.п.) — если нужно исправить существующий файл, отредактируй его. Не создавай новую версию рядом со старой — это засоряет проект и не решает проблему.
+ 9. **Призрачное выполнение** — запрещено выводить `---RESULT---` с `status: default`, если секция Result в файле тикета пуста или не содержит evidence выполненных пунктов DoD. Нарушение ведёт к блокировке пайплайна и повторным инцидентам. Перед выводом RESULT убедись, что:
+    - Секция Result содержит evidence по каждому выполненному пункту DoD
+    - Секция «Изменённые файлы» содержит все созданные/изменённые файлы (если требуются DoD)
+    - Все пункты DoD отмечены `[x]` или указана причина невыполнения
+    - Проверочные команды (build/test/lint) запущены и их вывод приложен (если требуется)
+
+ 10. **Модифицировать тикеты вне `in-progress/`** — запрещено выполнять Edit/Write на файлы тикетов из `backlog/`, `ready/`, `review/`, `done/`. Исполнитель работает только со своим тикетом в `in-progress/`. Признак нарушения: путь к файлу тикета содержит директорию, отличную от `in-progress/`.
+
+**Если задача требует создания тикетов/планов как deliverable:**
+→ Зафиксируй рекомендации в секции `### Рекомендации для следующего плана` результата тикета
+→ Человек решит, создавать ли следующий план
+
+**Почему:** Без этого ограничения возникает каскад: скил выполнения создаёт план → скил декомпозиции создаёт тикеты → backlog разрастается без контроля человека.
+
+## Загрузка знаний
+
+Подгружай модули из `knowledge/` по необходимости:
+
+| Модуль | Когда загружать |
+|--------|----------------|
+| `knowledge/ticket-structure.md` | При необходимости уточнить семантику полей тикета |
+| `knowledge/context-checkpoints.md` | При задаче с > 5 шагами DoD или при continuation прерванной сессии |
+| `../shared/*` | Перед началом работы — проверь индекс (`../shared/README.md`) и загрузи релевантные модули |
+
+## Загрузка алгоритмов
+
+Подгружай из `algorithms/` когда нужен формализованный метод:
+
+| Алгоритм | Когда загружать |
+|----------|----------------|
+| `algorithms/execution-strategy.md` | **ВСЕГДА** — стратегия анализа, выполнения и верификации задачи |
+
+## Шаги выполнения
+
+### 1. Прочитать тикет
+
+**ОБЯЗАТЕЛЬНО:** Используй ТОЛЬКО `ticket_id` из секции Context промпта.
+
+```
+Путь: .workflow/tickets/in-progress/{TICKET-ID}.md
+```
+
+Если тикет не найден в `in-progress/`, проверь `review/`.
+
+Извлечь:
+- Описание задачи
+- Критерии готовности (Definition of Done)
+- Контекст (файлы, ссылки, заметки)
+
+### 2. Проверить существующий прогресс
+
+**ОБЯЗАТЕЛЬНО перед началом работы** проверь, не выполнялся ли тикет ранее:
+
+1. **Секция `## Result` / `## Результат выполнения`** — если есть, тикет уже частично или полностью выполнен
+2. **Секция `## Ревью`** — если есть, тикет проходил ревью; прочитай замечания ревьюера
+3. **Пункты DoD** — `[x]` = уже выполнено и подтверждено, `[ ]` = ещё не выполнено
+
+**Правила продолжения:**
+
+| Ситуация | Действие |
+|----------|----------|
+| Result есть, ревью нет | Проверь незавершённые пункты DoD (`[ ]`). Доделай только их. Дополни существующий Result, не переписывай |
+| Result есть, ревью без замечаний к качеству | Доделай только невыполненные пункты DoD. Дополни Result |
+| Result есть, ревью с замечаниями | Исправь **только** то, что указано в замечаниях ревью. Остальное не трогай |
+| Result нет | Выполняй тикет с нуля (шаги 3-8) |
+
+**⚠️ Антипаттерн:** Переделывать уже выполненную и не раскритикованную работу. Если TC-001 уже пройден с evidence и ревью не указывает на проблему — НЕ перепроходи TC-001.
+
+### 3. Понять задачу
+
+Определить из описания и DoD тикета:
+- Что нужно сделать (или что **осталось** сделать — с учётом шага 2)
+- Какой результат ожидается
+- Какие есть ограничения
+
+Если не хватает информации → вывести `status: blocked` в блоке результата.
+
+### 4. Изучить контекст
+
+1. Прочитать все файлы из `context.files` инструментом Read
+2. Изучить `context.references` — внешние ссылки, документация
+3. Прочитать `context.notes` — дополнительный контекст от создателя тикета
+4. Если тикет ссылается на план (`parent_plan`) — прочитать план для понимания общей картины
+
+### 5. Выполнить работу и фиксировать результат инкрементально
+
+Действовать по описанию и DoD тикета. Подход определяется **содержимым тикета**, а не типом:
+
+- Если тикет требует изменения кода — следовать методологиям TDD, SOLID, DRY
+- Если тикет требует изменения файлов — обязательно Read → Edit/Write → Verify (перечитать для проверки)
+- Если тикет требует тестирования — выполнить чеклист проверок из DoD, зафиксировать pass/fail по каждому пункту
+- Если тикет требует исследования — использовать доступные инструменты для сбора данных, подкреплять источниками
+
+**⚠️ ИНКРЕМЕНТАЛЬНАЯ ЗАПИСЬ (ОБЯЗАТЕЛЬНО):**
+
+После выполнения **каждого пункта** — **сразу** запиши результат в тикет:
+1. Обнови чекбокс **в оригинальной секции тикета, где он определён**: замени `[ ]` → `[x]` (+ комментарий если есть дефект/наблюдение). Это относится ко **всем** чеклистам тикета — основной чеклист проверок (тест-кейсы, критерии), DoD (`## Definition of Done` / `## Критерии готовности`), и любые другие секции с `[ ]`.
+2. Добавь/дополни описание результата в секции Result (тест-кейс, что сделано, evidence)
+
+⛔ **НЕ создавай дубль-чеклист в секции Result.** Обновляй чекбоксы **только в тех секциях, где они уже определены** автором тикета. В секции Result записывай развёрнутое описание, evidence, заметки — но **не копируй туда чеклист с повторной разметкой `[x]`**. Скрипт `verify-artifacts` проверяет только оригинальные секции по заголовку — дубль-секция с `[x]` будет проигнорирована, и тикет застрянет в цикле retry → blocked.
+
+⛔ **НЕ дублируй чеклист в stdout-ответе.** Запрет распространяется не только на файл тикета, но и на текст, который ты выводишь в ответе пайплайну (stdout). Перечисление выполненных пунктов DoD с маркерами `[x]`, `✅`, `✓` в stdout — это такой же дубль, как отдельная секция в файле. Признак нарушения: ответ содержит список из 2+ пунктов DoD с галочками. Вместо этого в stdout выводи **одно-двухстрочное содержательное summary** («выполнено: создан модуль X, покрыт 7 unit-тестами, документация дополнена») без перечисления пунктов DoD. Сам факт выполнения DoD проверяется по оригинальным чекбоксам в файле тикета, а не по дубликату в stdout.
+
+Это защищает от потери прогресса при обрыве сессии. Не откладывай запись на конец — записывай по ходу.
+
+### 6. Финальная проверка критериев готовности
+
+Для каждого критерия из Definition of Done:
+- Выполнен ли он?
+- Если нет — доделать
+- Если невыполним — зафиксировать причину в заметках
+
+**Для тикетов тестирования (QA):** пункт DoD считается выполненным `[x]`, если сценарий **проверен** — независимо от результата проверки. Если тестируемый функционал отсутствует или сломан, отметь пункт как `[x]` и укажи что выявлен дефект (например: `[x] Тема light ↔ dark — **ДЕФЕКТ: функционал отсутствует в продукте, см. DEF-XXX-N**`). Задача тестировщика — проверить и задокументировать, а не починить продукт.
+
+### 7. Записать итоговый результат
+
+К этому моменту секция Result уже содержит результаты по каждому пункту (записаны инкрементально на шаге 5). Осталось:
+
+- Обновить/добавить **Summary** — краткое резюме всей работы
+- Дополнить **Изменённые файлы** и **Заметки** если нужно
+- **НЕ удалять и не переписывать** уже записанные результаты
+
+**⛔ НЕ трогай секцию `## Ревью`** — не создавай, не заполняй, не редактируй. Ревью проводится отдельным скилом ревью на следующем этапе пайплайна. Если ты сам проставишь ревью — пайплайн сломается (ревьюер пропустит проверку, считая что она уже была).
+
+**Если секции Result ещё нет** (первое выполнение с нуля) — она уже должна быть создана на шаге 5. Если нет — создай:
+
+```markdown
+## Result
+
+### Что сделано
+- ...
+
+### Изменённые файлы
+- ...
+
+### Заметки
+- ...
+```
+
+### 8. Правила работы с MCP-browser (Playwright)
+
+Все взаимодействия с браузером **ОБЯЗАТЕЛЬНО** должны использовать профиль из конфига проекта (`.mcp.json`).
+
+| Конфиг | Профиль | Когда использовать |
+|--------|---------|-------------------|
+| `.mcp.json` (дефолт) | Chrome + user-data-dir | **Всегда по умолчанию** |
+| `.workflow/config/mcp-browser-auth.json` | headless + user-data-dir | Headless с авторизацией |
+| `.workflow/config/mcp-browser.json` | headless без профиля | Только для задач без авторизации |
+
+После завершения работы с браузером — **обязательно** вызови `browser_close`.
+
+### 9. Вывести структурированный результат
+
+**⛔ ОБЯЗАТЕЛЬНАЯ МЕХАНИЧЕСКАЯ ПРОВЕРКА — перечитай файл тикета перед RESULT:**
+
+Перед выводом `---RESULT---` выполни `Read` на файл тикета (`.workflow/tickets/in-progress/{TICKET-ID}.md`) и глазами убедись:
+
+1. **Ни одного чекбокса `[ ]`** в секции критериев готовности / DoD. Все переведены в `[x]` или помечены причиной невыполнения (`[x] Пункт — не применимо: <причина>`).
+2. **Секция `## Result` / `## Результат выполнения` физически заполнена** — содержит реальный текст (summary, изменённые файлы, заметки), а не оставлена в виде скелета-шаблона с `### Что сделано\n- ...`.
+3. **Frontmatter не содержит добавленных строк `status:` или `completed_at:`** (эти поля устанавливает только пайплайн).
+
+Если хоть один пункт нарушен — **вернись к шагу 5 или 7** и выполни правки инструментом `Edit` на файл тикета. Не обходи эту проверку: вывод `---RESULT---` при пустом Result или `[ ]`-чекбоксах считается **призрачным выполнением** (см. ограничение #9) и ведёт к retry → blocked.
+
+**Внутренний self-check перед RESULT (не выводи в stdout — это проверка для себя):**
+
+Пройдись мысленно по пунктам. Если хоть один не выполнен — вернись к шагам 5-7 и исправь. Не копируй этот список в stdout.
+
+- Файл тикета перечитан `Read`'ом после всех правок (см. механическую проверку выше)
+- Каждый пункт DoD отмечен `[x]` или зафиксирована причина невыполнения
+- Если изменён код или тесты — проверочная команда проекта (build/test/lint) была фактически запущена, её вывод приложен к Result, итоговый статус зелёный (или `status: blocked` с выводом ошибки)
+- Секция Result НЕ пустая — содержит реальный контент, а не только заголовки шаблона
+- Каждый выполненный пункт DoD имеет соответствующий evidence в Result
+- Секция Result содержит summary, изменённые файлы, заметки
+- Все созданные файлы перечитаны (Read) после записи
+- Все файлы, созданные или изменённые при выполнении задачи, перечислены в секции «Изменённые файлы» (пайплайн проверяет их существование механически)
+- Все файлы из `context.files` были доступны (без permission denied); при ошибках — `status: blocked`, не `status: default`
+- Секция Result записана через **Edit** в файл тикета, а не только выведена текстом в stdout
+- Scope не расширен — изменены только файлы из DoD/context
+- Нет побочных эффектов — не созданы тикеты/планы, не перемещены файлы
+- Поля `status` и `completed_at` не записаны в файл тикета ни в каком виде
+- Секция `## Ревью` не создавалась и не редактировалась тобой
+
+**⛔ ФОРМАТ STDOUT — СТРОГО:**
+
+1. **Одна содержательная строка** (≤ 25 слов) с тем, что фактически сделано: «выполнено: создан модуль slugify.ts, покрыт 7 unit-тестами, дополнена CONFIG.md». Без префиксов «✅ Проверка:», «Резюме:», без перечислений.
+2. Далее **только** блок `---RESULT---` / `status: default` / `---RESULT---`.
+
+**⛔ ЗАПРЕЩЕНО В STDOUT:**
+- Перечислять пункты DoD (с `[x]`, `✅`, `✓`, `-`) — даже как «отчёт о проверке».
+- Декларировать результаты self-check: «✅ Все чекбоксы отмечены», «✅ Result заполнен», «Frontmatter не модифицирован». Self-check — для себя, не для stdout.
+- Выводить подзаголовки «Выполнено:», «Проверка:», «Резюме:» c последующими bullet-списками из 2+ элементов.
+
+Признак нарушения: в твоём выводе перед `---RESULT---` есть список из 2+ строк с маркерами `-`/`*`/`✅`/`✓`/`[x]`. Если видишь это в черновике — сверни всё в одну строку summary.
+
+**Пример правильного вывода:**
+
+```
+выполнено: создан src/utils/slugify.ts, покрыт 7 unit-тестами (happy-path + edge cases), добавлена CONFIG.md
+---RESULT---
+status: default
+---RESULT---
+```
+
+**Пример неправильного вывода (запрещено):**
+
+```
+Проверка:
+- ✅ Все чекбоксы DoD отмечены [x]
+- ✅ Result заполнен с summary
+- ✅ Frontmatter не модифицирован
+---RESULT---
+status: default
+---RESULT---
+```
+
+## Принципы
+
+1. **Scope Guard** — выполняй только то, что описано в тикете, не расширяй scope
+2. **Context First** — всегда читай контекстные файлы перед началом работы
+3. **DoD Driven** — все критерии готовности должны быть выполнены
+4. **No Side Effects** — не создавай артефакты workflow (тикеты, планы), не перемещай файлы тикетов
+5. **TDD/SOLID/DRY** — при написании кода следуй этим методологиям
+6. **Minimal Thinking** — между tool-вызовами максимум 1 короткая строка. Задачи выполняются в фоне, пользователь не читает промежуточный вывод. Развёрнутый анализ и выводы записывай в результат тикета
+7. **Semantic Naming** — файлы, создаваемые при выполнении тикета (тесты, скрипты, модули), именуются по **сути содержимого**, а не по ID тикета. Тикет — временная единица работы, файл остаётся в кодовой базе надолго. Пример: `edge-cases-stress.spec.ts`, а не `qa-031-edge-cases.spec.ts`. ID тикета можно указать в комментарии внутри файла, но не в имени файла
+8. **Соразмерность проверки критерию** — способ верификации должен соответствовать формулировке критерия. Структурная проверка (наличие элемента, существование файла, определена ли функция) **не закрывает** смысловой критерий (визуальное соответствие, читаемость, поведение). Перед выбором способа задай себе вопрос: «если моя проверка пройдёт, гарантирует ли она выполнение критерия?» Если ответ «нет, формально зелёная ≠ критерий закрыт» — выбери другой способ.
+
+   **Быстрые соответствия:**
+   - «Визуально соответствует макету» → **скриншот + pixel-diff** (Playwright screenshot, Percy). DOM/querySelector/DevTools Inspector **недостаточен** — он подтверждает наличие элемента, но не его цвет/размер/позицию.
+   - «Функция обрабатывает edge cases» → **unit-тесты на конкретных входах** с assert ожидаемого вывода. «Функция определена» недостаточно.
+   - «HTTP endpoint возвращает корректный JSON» → **реальный запрос + валидация схемы**. «fetch есть в коде» недостаточно.
+
+   ⛔ **Антипаттерн: смешивание равноправно.** Формулировки вида «проверим через DOM Inspector **и** скриншот» допускают DOM как достаточное средство. Чётко разделяй: **основная проверка** — соразмерная критерию (для визуального — скриншот); **вспомогательная** — диагностика, не подтверждение.
+
+   При визуальных/семантических/поведенческих критериях в Result **явно обоснуй**, почему структурной проверки недостаточно (одна строка). Полная таблица соответствий — `algorithms/execution-strategy.md` раздел «Соразмерность проверки критерию».
+
+## Формат вывода
+
+- Русский язык
+- Структурированный результат с секциями
+- Конкретные изменения с указанием файлов
+- Блок `---RESULT---` в конце
+
+## Границы компетенции
+
+- **Создание планов/тикетов** → рекомендации в секции Result
+- **Перемещение тикетов** → pipeline (автоматически)
+- **Улучшение скилов** → соответствующий скил проекта
+- **Стратегические решения** → скил планирования
+
+---
+
+**Регрессионные тесты:** `tests/index.yaml`. Прогон: `node .workflow/src/scripts/run-skill-tests.js --skill execute-task`

package/src/skills/execute-task/algorithms/execution-strategy.md

@@ -0,0 +1,136 @@
+# Алгоритм: Стратегия выполнения задачи
+
+## Вход
+
+Тикет с описанием, DoD, `context.files`, `context.notes`.
+
+## 1. Анализ задачи
+
+Оцени сложность и определи характеристики:
+
+| Фактор | Простая | Средняя | Сложная |
+|--------|---------|---------|---------|
+| Файлов в context | 1–2 | 3–5 | 6+ |
+| Пунктов DoD | 1–3 | 4–6 | 7+ |
+| Зависимости | нет | внутри проекта | внешние/кросс-модульные |
+| Требует исследования | нет | частично | да, перед выполнением |
+
+**Пример:** тикет «обновить таблицу загрузки в SKILL.md» — 1 файл, 2 DoD, 0 зависимостей → простая.
+
+## 2. Выбор подхода
+
+| Условие | Подход |
+|---------|--------|
+| DoD содержит конкретные изменения файлов | Сразу выполнять: Read → Edit → Verify |
+| DoD требует анализа/исследования | Сначала собрать данные, затем выполнять |
+| context.notes указывает на проблему без решения | Диагностировать → предложить решение → выполнить |
+| Есть предыдущий Result или ревью | Продолжить с точки останова (не переделывать) |
+
+**Порог переключения:** если после 3 попыток подход не даёт прогресса → зафиксировать причину, отметить `status: blocked`.
+
+**Пример:** тикет «создать алгоритм metric-calculation.md» — DoD конкретен (файл + секции), context.files указаны → подход «сразу выполнять».
+
+### ⛔ Соразмерность проверки критерию
+
+**Способ верификации должен соответствовать формулировке критерия.** Структурная проверка (наличие элемента, существование файла, существование функции) **НЕ закрывает** смысловой критерий (визуальное соответствие, читаемость, семантическая корректность).
+
+**Таблица соответствий:**
+
+| Формулировка критерия | Адекватный способ проверки | Недостаточный способ |
+|-----------------------|----------------------------|----------------------|
+| «Кнопка визуально соответствует макету» | Скриншот + pixel-diff с макетом (Playwright screenshot, Percy, BackstopJS) | DOM-селектор «кнопка существует», DevTools inspector, `querySelector` |
+| «Текст читаем пользователем» | Contrast-check (axe, Lighthouse) + визуальная инспекция рендера | Проверка что `<p>` есть в DOM |
+| «Endpoint возвращает корректный JSON» | HTTP-запрос + parse JSON + валидация схемы | `fetch` есть в коде |
+| «Функция обрабатывает edge cases» | Unit-тесты на конкретные edge-входы с assert ожидаемого вывода | «Функция определена» |
+| «Миграция безопасна для прод-данных» | Dry-run на копии прод-данных + проверка инвариантов до/после | «Миграционный файл создан» |
+
+**Правило диагностики:** прежде чем выбрать способ проверки, задай себе вопрос: «если моя проверка пройдёт, **гарантирует ли она** выполнение критерия?» Если ответ «нет, может быть формально зелёная, а критерий не закрыт» — проверка не соразмерна, возьми другую.
+
+**⛔ Антипаттерн: смешивание структурной и смысловой проверки как равных.** Формулировки вида «проверим через DevTools inspector **и** screenshot comparison» — неявно допускают DevTools как достаточное средство. В ответе чётко разделяй: **основная проверка** — соразмерная формулировке критерия, **вспомогательная** (если нужна) — может включать структурные средства для диагностики, но **не для подтверждения критерия**.
+
+**Обоснуй выбор в Result:** при визуальных, семантических, поведенческих критериях — явно запиши, **почему** структурной проверки недостаточно (например: «DOM-проверка подтверждает наличие элемента, но не его цвет/размер/позицию; визуальный критерий требует сравнения рендера»).
+
+## 3. Выполнение
+
+Чеклист шагов (независимо от подхода):
+
+1. **Изолируй** — определи scope: только файлы из DoD и context
+2. **Читай** — прочитай все context.files перед первым изменением
+3. **⛔ Permission-гейт:** если при чтении `context.files` получена ошибка permission denied для любого обязательного файла — немедленно выведи `status: blocked` с перечнем недоступных файлов. НЕ выполняй задачу частично, НЕ выводи `status: default`.
+4. **Изменяй** — вноси правки инкрементально, записывай результат после каждого пункта DoD
+5. **Проверяй** — после каждого Edit/Write перечитай файл (Read), убедись что изменение корректно
+
+| Тип работы | Обязательный цикл |
+|------------|-------------------|
+| Изменение кода | Write → запустить проверочную команду проекта (build/test/lint) → Read результата → приложить вывод проверочной команды в Result |
+| Изменение конфигурации | Read → Edit → Read (verify) |
+| Создание файла | Write → Read (verify) → проверить ссылки |
+| Тестирование | Выполнить сценарий → зафиксировать evidence → записать pass/fail |
+
+**⚠️ Правило обязательной верификации запуском.** Если DoD содержит формулировки вида «тесты зелёные», «компилируется», «работает», «проходит проверку» — недостаточно факта внесения правок в исходники. Необходимо **фактически запустить** соответствующую проверочную команду (build, test, lint, type-check, run и т.п.) и приложить её вывод (последние строки stdout/stderr с итоговым статусом) в секцию Result. Если команда не указана явно — определи её из конфигурации проекта (package.json scripts, Makefile, README, инструкции скила или ранее использованные команды в логах). Если проверочная команда падает — это **не выполнение DoD**: либо доводи до зелёного, либо фиксируй `status: blocked` с выводом ошибки.
+
+**Антипаттерн:** агент изменил `.ts` файлы, тесты написал в исходниках, но не запустил compile/test → артефакты сборки остались устаревшими → ревью находит расхождение между исходником и собранным результатом → failed. Этого можно избежать только запуском проверочной команды, а не визуальным контролем правок.
+
+**Пример:** создание `knowledge/module.md` — Write файл → Read убедиться что записано → grep ссылки в SKILL.md.
+
+## 4. Верификация
+
+### ⛔ Антипаттерн: Призрачное выполнение
+
+**Призрачное выполнение** — агент выводит `---RESULT---` с `status: default`, при этом секция Result в тикете остаётся пустой или не содержит реального evidence по пунктам DoD.
+
+**Признаки:**
+- Summary пустой или содержит только шаблонный текст без конкретики
+- Пункты DoD отмечены `[x]`, но в Result нет описания: что именно сделано, что проверено, какой получен результат
+- Секция «Изменённые файлы» пустая, хотя DoD требует создания или изменения файлов
+
+**Пример ошибочного поведения:** агент выводит в stdout «Задача выполнена успешно», отмечает `[x]` в DoD, но не вызывает Edit для записи Result в файл тикета. В логе пайплайна `result_filled: false`. **Недопустимо.**
+
+**Пример правильного поведения:** агент после каждого пункта DoD вызывает Edit для обновления чекбоксов и записи evidence в секцию Result. Перед выводом `---RESULT---` проверяет чеклист, убеждается, что секция Result не пуста. В логе `result_filled: true`.
+
+**⛔ Выход ЗАПРЕЩЁН**, если хотя бы одно из условий истинно:
+1. Секция Result пустая — не записана ни одна строка кроме заголовков шаблона
+2. Есть пункты DoD с `[x]`, но в Result отсутствует соответствующий evidence
+3. DoD требует создания или изменения файла, а секция «Изменённые файлы» в Result пустая или отсутствует
+
+Если условие нарушено → вернись к шагу 5 и выполни работу реально.
+
+### ⛔ Антипаттерн: Запись итогов в stdout
+
+**Stdout ≠ тикет.** Текст, выведенный в ответе агента (stdout), не обновляет файл тикета. Обновление тикета выполняется **исключительно через инструмент Edit** в файл тикета.
+
+**Признаки нарушения:**
+- В тексте ответа написано «обновлю тикет», «текущий статус» или описана выполненная работа, но инструмент Edit для файла тикета не вызывался
+- Агент завершился с `status: default`, но секция Result в тикете пустая
+
+**Частая причина:** контекст близок к лимиту — агент выбирает «быстрый» путь и выводит итог в текст вместо вызова Edit. Правильное действие при нехватке контекста: вывести `status: blocked` с причиной «контекст исчерпан, частичная работа выполнена», **не** `status: default`.
+
+### Чеклист
+
+Перед завершением пройди чеклист:
+
+- [ ] Каждый пункт DoD отмечен `[x]` или зафиксирована причина невыполнения
+- [ ] **Если изменён код или тесты** — проверочная команда проекта (build/test/lint) была фактически запущена, её вывод приложен к Result, итоговый статус — зелёный (или `status: blocked` с выводом ошибки)
+- [ ] **Секция Result НЕ пустая** — содержит реальный контент, а не только заголовки шаблона
+- [ ] Каждый выполненный пункт DoD имеет соответствующий evidence в Result (что сделано / что проверено / какой результат)
+- [ ] Секция Result содержит summary, изменённые файлы, заметки
+- [ ] Все созданные файлы перечитаны (Read) после записи
+- [ ] **Все файлы, созданные или изменённые при выполнении задачи, перечислены в секции «Изменённые файлы»** — пайплайн проверяет их существование механически; пустой список при наличии deliverable = сигнал призрачного выполнения → failed
+- [ ] Все файлы из `context.files` были доступны (без permission denied); при наличии ошибок — выведен `status: blocked`, не `status: default`
+- [ ] Секция Result записана через инструмент **Edit** в файл тикета, а не только выведена текстом в stdout
+- [ ] Scope не расширен — изменены только файлы из DoD/context
+- [ ] Нет побочных эффектов — не созданы тикеты/планы, не перемещены файлы
+- [ ] Поля `status` и `completed_at` **не записаны** в файл тикета ни в каком виде — ни как обновление, ни как новые строки в конец frontmatter
+- [ ] Секция `## Ревью` **не создавалась и не редактировалась тобой** — читать можно (шаг 2), писать в неё запрещено
+
+**Порог готовности:** все `[x]` в DoD + Result содержит реальный evidence = задача готова.
+
+**Пример:** после создания 2 файлов и обновления SKILL.md — перечитать все 3, проверить все 4 DoD → вывести `---RESULT---`.
+
+## Выход
+
+Решение: `default` (задача выполнена) или `blocked` (с причиной).
+
+**⛔ Правило блокировки при пустом Result:** если секция Result в файле тикета пуста (не содержит evidence) или не была записана через Edit, выведи `status: blocked` с причиной «призрачное выполнение — секция Result пуста, необходимо записать evidence». Не выводи `status: default`.
+
+<!-- РАСШИРЕНИЕ: добавляй стратегии для новых типов задач ниже -->

package/src/skills/execute-task/knowledge/context-checkpoints.md

@@ -0,0 +1,75 @@
+---
+name: context-checkpoints
+description: >
+  Управление контекстом при длительных задачах: anchored summary checkpoints
+  для предотвращения context drift и итерационной спирали.
+type: knowledge
+lazy: true
+load_when: "задача содержит > 5 шагов DoD или это continuation прерванной сессии"
+---
+
+# Управление контекстом: Checkpoints и Anchored Summary
+
+## Проблемы
+
+| Проблема | Симптом | Причина |
+|---------|---------|---------|
+| Контекстный дрейф | Агент теряет исходную цель | Новая информация перекрывает исходный intent |
+| Итерационная спираль | Каждая итерация открывает новую проблему | Нет фиксации прогресса между итерациями |
+| Потеря прогресса | Continuation начинается с нуля | Отсутствует structured checkpoint до прерывания |
+
+> Контекстный дрейф — причина 65% сбоев AI-агентов при многошаговых задачах (LogRocket, 2026).
+
+## Anchored Summary Pattern
+
+**Источник:** Compressing Context (Factory.ai, 2025), AI Agent Context Compression (Zylos Research, 2026)
+
+При выполнении задач с > 5 шагами DoD или при continuation сессии записывай **Anchored Summary** — структурированный чекпоинт:
+
+```
+## Anchored Summary (checkpoint)
+- intent: "формулировка из оригинального DoD — не переформулировать"
+- changes_made: ["файл X: изменено Y", "файл Z: добавлено W"]
+- decisions: ["решено A вместо B — причина: ..."]
+- next_steps: ["следующий шаг 1", "следующий шаг 2"]
+```
+
+**Когда создавать checkpoint:**
+
+1. После каждых 5 изменений файлов
+2. Перед завершением сессии при незакрытых пунктах DoD (continuation protection)
+3. При возникновении неожиданной подзадачи (риск drift от оригинального intent)
+
+**Где записывать:** секция `## Result → ### Заметки` тикета. Запись в тикет защищает от потери при обрыве сессии.
+
+**Эффект:** снижение объёма повторной работы на 78–95% при прерываниях (Factory.ai, 2025).
+
+## Алгоритм применения
+
+```
+1. READ: прочитай intent из DoD тикета (оригинал, не переформулировать)
+2. WORK: выполняй шаги DoD
+3. CHECKPOINT (каждые 5 изменений):
+   - запиши Anchored Summary в Result тикета
+4. CONTINUATION (если сессия прерывалась):
+   a. Read последний Anchored Summary
+   b. Восстанови context из changes_made
+   c. Продолжай с next_steps
+5. DRIFT CHECK: если actual work отклоняется от intent > 1 шага → вернись к DoD
+```
+
+## Сигналы context drift
+
+| Сигнал | Действие |
+|--------|----------|
+| Работаешь с файлами, не упомянутыми в DoD | СТОП → проверь DoD, фиксируй как "вне scope" |
+| Количество шагов > 2× ожидаемого | Запиши checkpoint, переоцени DoD |
+| Не можешь сформулировать intent в одной строке | Перечитай исходный тикет |
+
+## Совместимость со стеком
+
+| Контекст | Где записывать checkpoint |
+|----------|--------------------------|
+| Задачи разработки (код, тесты) | `## Result → ### Заметки` тикета |
+| QA-сессии (ручное тестирование) | В evidence-файл или секцию заметок тикета |
+| Исследовательские задачи | В summary секцию тикета |