@gian-tiaga/eda 3.14.0 → 4.0.0

package/skills/eda-plan-execute/SKILL.md

@@ -5,7 +5,7 @@ description: 'Выполняет готовый план последовате
 
 # Скил: Управляющий выполнением плана (eda-plan-execute)
 
-Веди выполнение плана: фазы строго по порядку, каждая с проверяемым результатом, прогресс и журнал в актуальном состоянии. Где именно выполняются фазы, задаёт режим.
+Веди выполнение плана: фазы строго по порядку, каждая с проверяемым результатом и сверкой с рамкой, прогресс и журнал в актуальном состоянии. Где именно выполняются фазы, задаёт режим.
 
 ## Настройки
 
@@ -13,25 +13,21 @@ description: 'Выполняет готовый план последовате
 
 ```yaml
 plan-execute:
-  mode: auto
+  mode: main
 ```
 
-`plan-execute.mode` принимает `subagents`, `main` или `auto`; при отсутствующем или невалидном значении используй `auto`. Файл настроек не изменяй.
+`plan-execute.mode` принимает `main`, `auto` или `subagents`; при отсутствующем или невалидном значении используй `main`. Файл настроек не изменяй.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом — главный вход. Разбери тему, путь к файлу, ограничения, прямые указания и режим:
+Текст рядом с вызовом — главный вход: план, ограничения, прямые указания и режим:
 
 - `subagents`, `субагенты`, `изолированно` → `$MODE=subagents`;
 - `main`, `один`, `одним контекстом`, `без субагентов`, `сам` → `$MODE=main`;
 - `auto`, `авто`, `автоматически` → `$MODE=auto`;
-- без явного режима → `$MODE=plan-execute.mode` из валидных настроек, иначе `$MODE=auto`.
+- без явного режима → `$MODE=plan-execute.mode` из валидных настроек, иначе `$MODE=main`.
 
-Режим из вызова важнее настройки, настройка важнее умолчания.
-
-Считай override только прямым указанием способа выполнения этого скила. «По фазам» описывает порядок работы, а `automatic` оркестратора и слово «автоматически» без явного выбора режима исполнения не задают `$MODE=auto`.
-
-Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных планов или есть риск выполнить не тот план.
+Режим из вызова важнее настройки, настройка важнее умолчания. Override — только прямое указание способа выполнения этого скила: «по фазам» и `automatic` оркестратора режим не задают.
 
 ## Режимы выполнения
 
@@ -41,48 +37,43 @@ plan-execute:
 | `main` | основной агент подряд в одном контексте | сам основной агент |
 | `auto` | решает по плану до старта: `main` или `subagents` | по выбранному режиму |
 
-`auto` выбирай `main`, только когда весь план реально помещается в один контекст: немного фаз, небольшой объём задач и файлов, одна область кода, нет тяжёлых по контексту фаз вроде крупного рефакторинга, миграции данных или множества карточек. Иначе — `subagents`; при сомнении тоже `subagents`. Решение и его причину запиши в журнал.
-
-Выбранный режим обязателен: `main` из вызова, `plan-execute.mode` или переданного оркестратором override запрещает делегацию независимо от размера плана. Критерии объёма выше применяй только при `$MODE=auto`; не переоценивай по ним явно заданный режим. После выбора в `auto` итоговый режим также зафиксирован. Менять его можно только по новому прямому указанию пользователя; решение оркестратора в `automatic` не заменяет такого указания.
+`auto` выбирай `main`, только когда весь план реально помещается в один контекст: немного фаз, небольшой объём задач и файлов, одна область кода, нет тяжёлых по контексту фаз вроде крупного рефакторинга, миграции данных или множества карточек. Иначе — `subagents`; при сомнении тоже `subagents`.
 
-В `main` не запускай `spawn_agent`, `Agent`, аналогичные инструменты или отдельный CLI для делегирования подготовки, фаз и проверок. При нехватке контекста сохрани текущую фазу, незавершённую работу, результаты проверок и режим в журнале; после сжатия контекста продолжай основным агентом с этого места. Если продолжить в выбранном режиме технически невозможно, сохрани `status: blocked` с причиной. Размер плана, желание ускорить работу и предположение о нехватке контекста сами по себе не являются блокером или разрешением сменить режим.
+Выбранный режим обязателен до конца: `main` из вызова, настройки или override оркестратора запрещает делегацию независимо от размера плана, критерии объёма применяются только к `auto`. Менять режим можно только по новому прямому указанию пользователя. В `main` не запускай `spawn_agent`, `Agent` или отдельный CLI; при нехватке контекста сохрани текущую фазу, незавершённую работу и режим в журнале и продолжай с этого места. Если продолжить в выбранном режиме технически невозможно, сохрани `status: blocked` с причиной.
 
-## Главные правила
+## Правила
 
-1. **В `subagents` основной агент только управляет.** Ему разрешены чтение контекста, запуск и контроль субагентов, вопросы пользователю, обновление `$PLAN_FILE` и `$EXECUTION_FILE`. Код, тесты, миграции, конфиги, зависимости, документацию и git-состояние меняют только назначенные субагенты. В `main` основной агент выполняет фазы и проверки сам и остаётся единственным исполнителем.
+1. **В `subagents` основной агент только управляет.** Ему разрешены чтение контекста, запуск и контроль субагентов, вопросы пользователю, обновление `$PLAN_FILE` и `$EXECUTION_FILE`. Код, тесты, миграции, конфиги, зависимости, документацию и git-состояние меняют только назначенные субагенты. В `main` основной агент выполняет фазы и проверки сам.
 2. **Фазы выполняй строго последовательно.** Не начинай следующую, пока текущая не выполнена и её проверка не прошла.
-3. **В `subagents` одна фаза — один исполнитель.** Запускай каждую фазу целиком в новом субагенте со свежим контекстом без истории диалога. Идентификатор исполнителя сохраняй и продолжай его же для вопросов и исправлений этой фазы.
-4. **Рамку читает тот, кто выполняет фазу.** Он целиком читает план, `docs/rules.md` и `docs/arch.md`. Для поведения своей фазы читает карточки из `sources.business`; у старого плана без поля выбирает через `docs/business.md` только непосредственно применимые карточки. Для затронутых компонентов так же выбирает технические карточки через `sources.references` или `docs/references.md`. Если выполнение фазы затрагивает компонент, для которого в `docs/references.md` указана карточка, он читает эту карточку целиком перед соответствующим изменением. Нерелевантные карточки не загружает.
-5. **Исполнитель не додумывает план.** Если в фазе не хватает решения, это вопрос пользователю или возврат в `eda-plan`, но не импровизация в коде. В `subagents` исполнитель возвращает `needs_input`, в `main` основной агент останавливается и спрашивает.
-6. **Блокируй конфликт.** План задаёт область выполняемой работы, а применимые business-карточки — требования к затронутому поведению. Если план противоречит business-карточке, `rules.md`, `arch.md` или reference-карточке, останови фазу и через `AskUserQuestion` спроси: изменить план через `eda-plan` или сначала пересогласовать правило через `eda-business`.
-7. **Отмечай только подтверждённое.** Фазу закрывай только после выполнения и прошедшей проверки: в `subagents` это `completed` от исполнителя и отдельный `passed` от проверяющего, в `main` — пройденные критерии и команды проверки фазы с сохранённым выводом. При последующем опровержении верни отметку в незавершённое состояние.
-8. **Проверки нельзя подавлять.** Не отключай и не поручай отключать линтеры, тесты, typecheck, static analysis и другие проверки, не добавляй игноры и не ослабляй команды и правила. Сначала исправляется причина падения, затем проверка повторяется.
-9. **Новый проект разворачивай штатным CLI.** Если фаза создаёт основу нового проекта и для выбранного стека существует официальный generator/scaffold CLI, исполнитель обязан вызвать его через подходящий package manager или runtime (`composer create-project`, `npm create`, `npx`, `cargo new` или реальный аналог). Не создавай вручную файлы, которые генерирует CLI; после генерации изменяй результат только в границах плана. Если точная команда отсутствует в плане и проектных правилах, верни фазу в `eda-plan`, а не импровизируй ручной scaffold.
-10. **Не коммить, не пушь и не делай ревью.** Это другие скилы.
-
-## Вопросы
-
-Блокирующий вопрос: Claude Code — `AskUserQuestion`; Codex interactive — `request_user_input` или короткий вопрос с вариантами 1–3; Codex exec — не читай stdin, заверши со статусом `blocked: нужен ответ пользователя`. Не запускай команды, ждущие интерактивного ввода.
+3. **В `subagents` одна фаза — один исполнитель.** Запускай каждую фазу целиком в новом субагенте со свежим контекстом без истории диалога. Его идентификатор сохраняй и продолжай его же для вопросов и исправлений этой фазы.
+4. **Рамку читает тот, кто выполняет фазу.** Он полностью читает план, его раздел `Рамка` и все файлы из `sources`; большой файл — частями до последней строки, обрезанный вывод не считается прочитанным файлом. План без раздела `Рамка` — старый: исполнитель читает `docs/rules.md` и `docs/arch.md` и выбирает по их таблицам карточки областей фазы, у старого плана без поля выбирает через `docs/business.md` только непосредственно применимые карточки, а через `docs/references.md` — карточки затронутых компонентов. Если фаза затрагивает компонент, для которого в `docs/references.md` указана карточка, он читает эту карточку целиком перед соответствующим изменением.
+5. **План исполняется буквально.** Пункты `Рамки` и `Принятых решений` обязательны так же, как фазы. Не хватает решения — вопрос пользователю или возврат в `eda-plan`, а не импровизация. Не добавляй механизмов, которых нет в плане: шифрование, повторные проверки типизированных ответов, обёртки, сервисы, скрипты, контейнеры, повторы, кэши и ожидания. В `subagents` исполнитель возвращает `needs_input`, в `main` основной агент спрашивает.
+6. **Блокируй конфликт.** План задаёт область выполняемой работы, а применимые business-карточки — требования к затронутому поведению. Если план противоречит business-карточке, правилу, архитектуре или эталону, останови фазу и спроси: изменить план через `eda-plan` или сначала пересогласовать правило через `eda-business`.
+7. **Согласование — остановка.** Фаза с полем `Согласование` показывает пользователю указанный результат и ждёт ответа: в `subagents` исполнитель готовит его и возвращает `needs_input`. До ответа работа, которая от него зависит, не начинается, фаза не завершается и следующая не стартует.
+8. **Сверка с рамкой.** Перед сдачей фазы исполнитель проходит её изменения по каждому пункту `Рамки` и `Принятых решений`: `соблюдено`, `нарушено` с файлом и строкой или `не затронуто`. Нарушение исправляется до сдачи фазы.
+9. **Документы рамки правятся на месте.** Изменение `docs/rules*`, `docs/arch*`, `docs/references*` вносится в раздел-владелец по структуре документа и в пределах его лимита, без датированных дополнений и журналов изменений.
+10. **Отмечай только подтверждённое.** Фазу закрывай только после выполнения и прошедшей проверки: в `subagents` — `completed` от исполнителя и `passed` от проверяющего, в `main` — пройденные критерии и команды с сохранённым выводом. При опровержении верни отметку в незавершённое состояние.
+11. **Проверки нельзя подавлять.** Не отключай и не поручай отключать линтеры, тесты, typecheck, static analysis и другие проверки, не добавляй игноры и не ослабляй команды и правила. Сначала исправляется причина падения, затем проверка повторяется.
+12. **Новый проект разворачивай штатным CLI.** Если фаза создаёт основу нового проекта и для стека есть официальный generator/scaffold CLI, вызови его через подходящий package manager или runtime (`composer create-project`, `npm create`, `npx`, `cargo new` или реальный аналог). Не создавай вручную файлы, которые генерирует CLI. Если точной команды нет в плане и правилах, верни фазу в `eda-plan`.
+13. **Не коммить, не пушь и не делай ревью.** Это другие скилы.
+
+Блокирующий вопрос — `AskUserQuestion`: задав его, остановись до ответа. В неинтерактивном запуске не читай stdin и заверши `blocked: нужен ответ пользователя`. Не запускай команды, ждущие интерактивного ввода.
+
+<!-- include: skills/_shared/done.md -->
 
 ## Этапы
 
 ### 1. Выбрать план
 
-Путь — используй как есть. Название или его часть — ищи совпадение в `docs/artifacts/plans/`. «Последний план» — бери самый новый файл. Вставленный текст плана сначала сохрани или однозначно привяжи к файлу.
-
-Один план — продолжай без вопроса. Несколько равных — `AskUserQuestion`. Плана нет — `blocked: нужен план`.
-
-Не исполняй план с открытыми вопросами или неразрешёнными развилками: сначала заверши `eda-plan` или `eda-plan-polish`.
+Путь — используй как есть. Название или его часть — ищи в `docs/artifacts/plans/`. «Последний план» — самый новый файл. Вставленный текст плана сначала сохрани или однозначно привяжи к файлу. Несколько равных — спроси; плана нет — `blocked: нужен план`. План с открытыми вопросами или неразрешёнными развилками не исполняй: сначала `eda-plan` или `eda-plan-polish`.
 
 ### 2. Выбрать место выполнения
 
-Через `AskUserQuestion` предложи текущую ветку, новую ветку от `main`, новую ветку от текущей или worktree от `main`. Если вызывающий оркестратор уже передал подтверждённый выбор, не спрашивай повторно.
-
-В `subagents` git-команды сам не выполняй: для новой ветки или worktree запусти отдельного субагента подготовки окружения; в `main` подготовь окружение сам. Передай ему только выбранный вариант, slug плана, рабочую директорию и запрет менять код. После успешного создания worktree остановись и дай команду перехода и нового запуска `eda-plan-execute <PLAN_FILE>`.
+Спроси: текущая ветка, новая ветка от `main`, новая ветка от текущей или worktree от `main`. Подтверждённый выбор вызывающего оркестратора повторно не спрашивай. В `subagents` ветку или worktree готовит отдельный субагент без права менять код; в `main` — ты сам. После создания worktree остановись и дай команду перехода и нового запуска `eda-plan-execute <PLAN_FILE>`.
 
 ### 3. Прочитать план и проверить фазы
 
-Прочитай `$PLAN_FILE`, включая `test_strategy`. Для каждой фазы извлеки цель, что сделать, результат и проверку. До запуска убедись, что у каждой фазы есть проверяемый результат и команда или критерий проверки.
+Прочитай `$PLAN_FILE` полностью. Для каждой фазы извлеки цель, что сделать, согласование, результат и проверку. Фаза без проверяемого результата или исполнимой проверки — предложи вернуть план в `eda-plan` или `eda-plan-polish`, смысл не достраивай.
 
 `test_strategy` управляет не только написанием тестов, но и фазовыми проверками:
 
@@ -93,15 +84,13 @@ plan-execute:
 | `phase_tests_final_checks` | написать тесты в фазе, но запустить только добавленные или изменённые этой фазой тесты; остальные проверки отложить |
 | `end_of_plan` | до финальной фазы использовать только указанные неавтоматические критерии готовности; тесты и автоматические проверки не запускать |
 
-Полный набор тестов и обязательных проверок всё равно запускается в финале. Если план не соответствует своей стратегии, верни его в `eda-plan` или `eda-plan-polish`, а не меняй стратегию при выполнении.
+Полный набор проверок всё равно запускается в финале. План, не соответствующий своей стратегии, возвращается в `eda-plan` или `eda-plan-polish`; стратегию при выполнении не меняй.
 
-Если фаза не описывает проверяемый результат или её проверку нечем выполнить, не достраивай смысл молча: через `AskUserQuestion` предложи вернуть план в `eda-plan` или `eda-plan-polish`.
+### 4. Зафиксировать режим и завести журнал
 
-### 4. Определить режим и инициализировать прогресс
+Если `$MODE=auto`, сравни разобранные фазы с критериями из «Режимы выполнения» и зафиксируй итоговый режим до первой фазы. Сообщи режим и источник — вызов, override оркестратора, `plan-execute.mode` или default — и запиши их в журнал, для `auto` с причиной. После сжатия контекста восстанови режим из журнала.
 
-Если `$MODE=auto`, сравни разобранные фазы с критериями из «Режимы выполнения» и зафиксируй итоговый режим `main` или `subagents` до первой фазы. Дальше действуй по зафиксированному режиму. Перед выполнением коротко сообщи режим и его источник: вызов, override оркестратора, `plan-execute.mode` или default; сохрани их в журнале. Для `auto` также запиши причину выбора. При продолжении после сжатия контекста восстанови зафиксированный режим из журнала, если пользователь не изменил его прямо.
-
-Создай `$EXECUTION_FILE` по пути `docs/artifacts/executions/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. В `$PLAN_FILE` добавь или актуализируй один раздел `## Прогресс выполнения` со ссылкой на журнал и списком фаз.
+Создай `$EXECUTION_FILE` в `docs/artifacts/executions/{YYYY-MM-DD}_{HH-MM}_{slug}.md`, а в `$PLAN_FILE` — один раздел `## Прогресс выполнения` со ссылкой на журнал и списком фаз.
 
 ```markdown
 ---
@@ -115,8 +104,8 @@ current_phase: <номер>
 # Журнал выполнения: <заголовок>
 
 ## Фазы
-| Фаза | Результат | Проверка | Статус |
-|---|---|---|---|
+| Фаза | Результат | Проверка | Сверка с рамкой | Статус |
+|---|---|---|---|---|
 
 ## Запуски
 | Время | Исполнитель | Фаза | Результат | Файлы | Проверки |
@@ -127,30 +116,15 @@ current_phase: <номер>
 ## Финальная проверка
 ```
 
-Журнал и отметки прогресса в плане ведёт только основной агент. В `main` записывай выбор режима с причиной, а в колонке «Исполнитель» — `основной агент`; в `subagents` явно запрети субагентам менять `$PLAN_FILE` и `$EXECUTION_FILE`.
+Журнал и отметки прогресса в плане ведёт только основной агент; в `main` в колонке «Исполнитель» пиши `основной агент`.
 
-### 5. Запускать изолированных субагентов
+### 5. Выполнить фазу
 
-Весь этап — только для `subagents`. В `main` пропусти его и выполняй фазы сам.
+В `main` выполни фазу сам по правилам 4–9, запиши в журнал сделанное, файлы, сверку и проверки и переходи к проверке фазы.
 
-В Codex используй `spawn_agent` с `fork_turns: "none"`, в Claude Code — новый `Agent` с самодостаточным сообщением. Если изоляция или субагенты недоступны, остановись: `blocked: недоступно изолированное выполнение`. Работу основным агентом не делай и CLI-fallback не добавляй.
+Дальше весь этап — только для `subagents`. Используй в Codex `spawn_agent` с `fork_turns: "none"`, в Claude Code — новый `Agent` с самодостаточным сообщением. Если изоляция недоступна, остановись: `blocked: недоступно изолированное выполнение`; работу основным агентом не делай и CLI-fallback не добавляй.
 
-#### Технические остановки субагентов
-
-Техническую ошибку инструмента субагентов не смешивай со статусами `failed` и `blocked` содержательного контракта. Сохрани полный исходный текст ошибки и обработай её по причине:
-
-- лимит параллельности или отсутствие свободного слота — дождись уже запущенного этим workflow агента, при необходимости закрой завершённые потоки и повтори тот же запуск; если управляемых активных агентов нет, заверши `blocked: заняты слоты субагентов`;
-- лимит глубины вложения — не повторяй запуск и не выполняй этап сам; заверши `blocked: достигнут лимит глубины субагентов`, указав наблюдаемую и требуемую глубину;
-- исчерпана usage-квота — не делай автоматических повторов; заверши `blocked: исчерпана квота`, сохрани время reset или условие продолжения, если хост его сообщил;
-- не хватает разрешения — запроси одно конкретное разрешение по правилам текущей среды и после ответа продолжи того же агента; в неинтерактивной среде заверши `blocked: нужно разрешение пользователя`;
-- временная API-, server-, overload- или network-ошибка — один раз продолжи того же агента; если resume недоступен, один раз запусти ту же роль с исходным входом, полным частичным результатом и требованием сначала сверить текущее состояние; повторный такой сбой заверши как `blocked` с исходной ошибкой;
-- неизвестная техническая ошибка — не угадывай причину и не зацикливай retry; заверши `blocked: техническая ошибка субагента` с полным исходным текстом.
-
-Ожидание слота и один технический retry не считаются попыткой исправления фазы и не расходуют её лимит сходимости.
-
-Каждому исполнителю фазы передай: рабочую директорию, `$PLAN_FILE`, номер и полный текст фазы, `test_strategy`, краткие результаты завершённых фаз, пути к `docs/rules.md`, `docs/arch.md`, `docs/business.md` и `docs/references.md`, ограничения пользователя, критерии проверки фазы и запрет коммитить и менять план и журнал. Явно передай разрешённый фазовый прогон из таблицы стратегии; не разрешай запускать отложенные ею проверки досрочно.
-
-Требуй YAML-результат:
+Запусти одного нового изолированного исполнителя и сохрани его идентификатор как исполнителя этой фазы. Передай рабочую директорию, `$PLAN_FILE`, номер и полный текст фазы, `test_strategy` и разрешённый фазовый прогон, краткие результаты завершённых фаз, ограничения пользователя, раздел «Доказательство готовности» целиком и запрет коммитить и менять план и журнал. Требуй YAML:
 
 ```yaml
 status: completed | needs_input | failed | blocked
@@ -159,33 +133,43 @@ summary: <что сделано>
 files_changed: [<пути>]
 business_read: [<пути или пусто>]
 references_read: [<пути или пусто>]
+frame_check:
+  - item: <пункт Рамки или Принятых решений>
+    status: соблюдено | нарушено | не затронуто
+    evidence: <файл:строка или пусто>
 checks:
   - command: <команда или критерий>
     status: passed | failed | not_run
     result: <кратко>
 deviations: [<отклонения от плана или пусто>]
-risks: [<остаточные риски или пусто>]
 questions: [<вопросы или пусто>]
 ```
 
-Не принимай `completed`, если обязательная проверка фазы не прошла, исполнитель вышел за назначенный scope, молча отклонился от рамки или изменил план либо журнал.
+Не принимай `completed`, если проверка фазы не прошла, в сверке есть `нарушено`, исполнитель вышел за scope или изменил план либо журнал. Дальше:
 
-### 6. Выполнять фазы
+- `needs_input` — один блокирующий вопрос пользователю, затем продолжи того же исполнителя фазы с ответом; если продолжить нельзя, запусти нового с полным предыдущим результатом;
+- `failed` — продолжи того же исполнителя фазы с полным результатом и поручением исправить причину; две попытки подряд с той же причиной без содержательного изменения — `blocked: выполнение не сходится`;
+- `blocked` — останови выполнение и вынеси блокер вопросом;
+- `completed` — переходи к проверке фазы.
 
-В `subagents` для каждой фазы по порядку:
+#### Технические остановки субагентов
+
+Техническую ошибку инструмента субагентов не смешивай со статусами контракта; сохрани исходный текст и обработай по причине:
 
-1. Запусти одного нового изолированного исполнителя и сохрани его идентификатор как исполнителя этой фазы.
-2. Проверь YAML-контракт, фактический scope файлов и результаты проверок. Запиши запуск в журнал.
-3. `needs_input` передай пользователю одним блокирующим вопросом, затем продолжи того же исполнителя фазы с ответом и его предыдущим результатом. Если среда не умеет продолжать завершённого субагента, запусти нового с полным предыдущим результатом.
-4. `failed` — продолжи того же исполнителя фазы с полным неуспешным результатом и поручением исправить причину и повторить проверки. Если две попытки подряд дают ту же причину без содержательного изменения, остановись: `blocked: выполнение не сходится`.
-5. `blocked` — останови выполнение. Внешний блокер или изменение scope выноси вопросом; сам его не устраняй.
-6. После `completed` запусти независимую проверку фазы.
+- нет свободного слота — дождись запущенного этим workflow агента, закрой завершённые и повтори; если управляемых активных агентов нет — `blocked: заняты слоты субагентов`;
+- лимит глубины — не повторяй и не выполняй сам: `blocked: достигнут лимит глубины субагентов` с наблюдаемой и требуемой глубиной;
+- исчерпана квота — без повторов: `blocked: исчерпана квота` с временем reset, если хост его сообщил;
+- нет разрешения — запроси одно конкретное разрешение и продолжи того же агента; в неинтерактивной среде — `blocked: нужно разрешение пользователя`;
+- временная API-, server-, overload- или network-ошибка — один раз продолжи того же агента, иначе один раз запусти ту же роль с исходным входом и частичным результатом; повторный сбой — `blocked` с исходной ошибкой;
+- неизвестная ошибка — не угадывай причину и не зацикливай retry: `blocked: техническая ошибка субагента` с полным текстом.
 
-В `main` перед первой фазой один раз прочитай план целиком, `docs/rules.md` и `docs/arch.md`, а карточки выбирай по правилу 4 под каждую фазу. Затем для каждой фазы по порядку выполни работу фазы, запиши в журнал сделанное, изменённые файлы и результаты проверок и переходи к проверке фазы. Не хватает решения — спроси пользователя; конфликт с правилами или карточками — останови фазу как `blocked`; та же причина падения дважды подряд без содержательного изменения — остановись: `blocked: выполнение не сходится`.
+Ожидание слота и один технический retry не расходуют лимит сходимости фазы.
 
-### 7. Проверять каждую фазу
+### 6. Проверить фазу
 
-В `subagents` после `completed` запусти нового изолированного субагента-проверяющего. Он не меняет файлы, целиком читает план, `docs/rules.md` и `docs/arch.md`, читает только применимые карточки, выполняет разрешённый стратегией фазовый прогон и подтверждает критерии результата. При `phase_tests_final_checks` он запускает только тесты, добавленные или изменённые в этой фазе. При `end_of_plan` он не запускает автоматические команды и проверяет только указанные неавтоматические критерии готовности.
+Проверка выполняет разрешённый стратегией фазовый прогон, подтверждает критерии `Результата` и заново сверяет изменения фазы с `Рамкой` и `Принятыми решениями`, не доверяя сверке исполнителя. При `phase_tests_final_checks` запускаются только добавленные или изменённые фазой тесты, при `end_of_plan` — только неавтоматические критерии.
+
+В `subagents` проверяет новый изолированный субагент-проверяющий: он не меняет файлы, читает рамку по правилу 4 и получает раздел «Доказательство готовности» целиком.
 
 ```yaml
 status: passed | failed | blocked
@@ -194,35 +178,31 @@ checks:
   - command: <команда или критерий>
     status: passed | failed
     result: <кратко>
+frame_violations: [<пункт, файл:строка или пусто>]
 failures: [<проблемы с доказательствами или пусто>]
 business_read: [<пути или пусто>]
 references_read: [<пути или пусто>]
 ```
 
-При `failed` передай полный результат исполнителю этой фазы, поручи исправить подтверждённые проблемы и запусти нового проверяющего. Основной агент код не чинит и контекст прежнего проверяющего не переиспользует.
-
-В `main` сам выполни разрешённый стратегией фазовый прогон и сверь результат с критериями плана, а не с собственным впечатлением. Для `phase_tests_final_checks` запускай только добавленные или изменённые текущей фазой тесты; для `end_of_plan` не запускай автоматические команды до финальной фазы. Падение исправляй и повторяй проверку заново целиком.
+При `failed` передай результат исполнителю этой фазы и после исправления запусти нового проверяющего; основной агент код не чинит. В `main` проверяешь сам по критериям плана, а не по впечатлению; падение исправляешь и повторяешь проверку целиком.
 
-При `passed` отметь фазу завершённой и только тогда переходи к следующей.
+При `passed` отметь фазу завершённой и переходи к следующей.
 
-### 8. Финальная проверка
+### 7. Финальная проверка
 
-После всех фаз прогони полный набор тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. Для `phase_tests_final_checks` и `end_of_plan` это первый полный прогон; он обязан включить созданные по фазам и существующие тесты проекта вместе со всеми отложенными проверками. Для `after_each_phase` и `tdd_each_phase` это итоговый повтор полного набора после интеграции всех фаз. В `subagents` это делает отдельный новый субагент: он только проверяет, целиком читает план, `docs/rules.md` и `docs/arch.md` и выбирает карточки итогового изменённого поведения. В `main` тот же полный набор запускает основной агент.
+После всех фаз прогони полный набор тестов, линтеров, typecheck, static analysis и других обязательных команд проекта и сверь всё изменение с `Рамкой` и `Принятыми решениями`. Для `phase_tests_final_checks` и `end_of_plan` это первый полный прогон; он включает тесты всех фаз, существующие тесты и отложенные проверки. Для `after_each_phase` и `tdd_each_phase` — итоговый повтор после интеграции. В `subagents` это делает отдельный новый субагент, который только проверяет.
 
-Падение из-за сделанных изменений сопоставь с фазами и исправь по порядку плана: в `subagents` передай каждую группу исполнителю соответствующей фазы. Затем повтори всю финальную проверку целиком. Чужую или несвязанную поломку зафиксируй и вынеси вопросом, если без решения нельзя завершить план. Запрещено делать проверки зелёными через подавление ошибок, игноры, исключения, ослабление конфигов или изменение команд проверки.
+Падение из-за изменений сопоставь с фазами и исправь по порядку плана, затем повтори финальную проверку целиком. Чужую поломку зафиксируй и вынеси вопросом, если без решения нельзя завершить план. Запрещено делать проверки зелёными через подавление ошибок, игноры, исключения, ослабление конфигов или изменение команд проверки.
 
-Запиши команды и результаты в `## Финальная проверка`. Только после `passed` поставь `status: done` и время завершения. Если обязательная проверка объективно недоступна, сохрани `status: blocked`, причину и непройденные критерии; выполненным план не объявляй.
+Запиши команды и результаты в `## Финальная проверка`. Только после `passed` поставь `status: done` и время завершения. Если обязательная проверка недоступна, сохрани `status: blocked` с причиной.
 
-### 9. Финал
+### 8. Финал
 
-Коротко сообщи режим выполнения, пути к плану и журналу, завершённые фазы, результат фазовых и финальной проверок, оставшиеся блокеры, состояние git «не закоммичено» и следующий шаг: `eda-review` или `eda-commit`.
+Сообщи режим, пути к плану и журналу, завершённые фазы, результаты проверок и сверки, блокеры, что изменения не закоммичены, и следующий шаг: `eda-review` или `eda-commit`.
 
 ## Чего НЕ делать
 
 - В `subagents` самому менять код, тесты, миграции, конфиги и зависимости или самому запускать проверки проекта.
-- В `subagents` дробить фазу между исполнителями, давать одному исполнителю несколько фаз, давать субагентам историю диалога или разрешать менять план и журнал.
-- Самостоятельно менять зафиксированный режим или применять критерии `auto` к `main` из вызова, настроек либо override оркестратора.
-- Запускать следующую фазу до успешной проверки текущей.
-- Додумывать недостающее решение вместо вопроса.
+- В `subagents` дробить фазу между исполнителями, давать одному исполнителю несколько фаз, передавать историю диалога или разрешать менять план и журнал.
 - Подавлять ошибки проверок, ослаблять правила или менять команды ради зелёного результата.
 - Коммитить, пушить, создавать PR или делать ревью.

package/skills/eda-plan-polish/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: eda-plan-polish
-description: 'Доводит план циклом ревью и исправлений, останавливается при отсутствии роста и оставляет лучшую версию.'
+description: 'Доводит план циклом ревью и исправлений до 100/100 или лимита попыток.'
 ---
 
 # Скил: Полировка плана (eda-plan-polish)
 
 Оркестрируй цикл `eda-plan-review` → `eda-plan-review-fix`. Сам план не правь и score не выставляй: ты выбираешь план, запускаешь каждый скил в отдельном изолированном субагенте, следишь за ростом оценки и решаешь, когда остановиться.
 
-Главное отличие от простого повторения итераций: **цикл останавливается, как только оценка перестаёт расти, и оставляет лучшую версию плана, а не последнюю.**
+Штатно завершай цикл только при подтверждённых 100/100 или достижении лимита. Кроме них цикл останавливают только: технический блокер субагента, нарушение контракта (SHA-256 цепочка, противоречивый gate) и вопрос пользователю, на который в текущей среде нельзя получить ответ; это `blocked`, а не успех. Отсутствие прогресса — не причина остановки: рост score прекратился, score снизился, пункты повторяются, fix вернул `partial` или `no-change` — продолжай до лимита.
 
 ## Вход из сообщения пользователя
 
@@ -19,9 +19,9 @@ description: 'Доводит план циклом ревью и исправл
 
 Прочитай `docs/settings.yaml`, если есть. Поддерживается только `version: 3`; иначе defaults и предупреждение.
 
-- `plan-review.threshold` — доля закрытых пунктов для `ready`, default `100`;
-- `plan-polish.limit` — максимум итераций «проверка + исправление», default `1`;
-- прямые `threshold N` и `limit N` в сообщении важнее файла.
+- `plan-review.threshold` — настройка самостоятельного review, default `100`; внутри полировки всегда передавай `threshold 100`;
+- `plan-polish.limit` — максимум итераций «проверка + исправление», default `5`;
+- прямой `limit N` в сообщении важнее файла; `threshold N` не меняет цель полировки 100/100, о проигнорированном пороге сообщи в финале.
 
 `strict` и кросс-CLI здесь не поддерживаются.
 
@@ -29,7 +29,7 @@ description: 'Доводит план циклом ревью и исправл
 
 1. Каждый вызов `eda-plan-review` и `eda-plan-review-fix` запускай отдельным изолированным субагентом с чистым контекстом.
 2. Если нативные субагенты недоступны, остановись. Не делай review или fix сам и не используй CLI-fallback.
-3. Успех — только review со статусом `ready`. Остановка сразу после fix успехом не считается.
+3. Успех — только review со статусом `ready`, `score: 100` и без открытых пунктов. Остановка сразу после fix успехом не считается.
 4. Основной агент не меняет содержание плана. После `ready` он может обновить только front matter: `status`, `plan_review`, `plan_review_fix`.
 5. Не запускай проверки проекта и не коммить.
 
@@ -58,7 +58,7 @@ description: 'Доводит план циклом ревью и исправл
 
 Итерация — это `eda-plan-review` плюс `eda-plan-review-fix`. `$LIMIT` считает именно их, поэтому `limit 1` означает одну проверку и одно исправление. Отдельного подтверждающего прохода нет: исправление проверяет review следующей итерации, а после последнего исправления цикл заканчивается непроверенным — это цена низкого лимита.
 
-Сформируй `$PLAN_FILE`, `$THRESHOLD`, `$LIMIT` и журнал: итерация, путь review, SHA-256 плана, score, открытые пункты, путь fix.
+Сформируй `$PLAN_FILE`, `$THRESHOLD = 100`, `$LIMIT` и журнал: итерация, путь review, SHA-256 плана, score, открытые пункты, путь fix.
 
 Для `$ITERATION` от `1` до `$LIMIT`:
 
@@ -72,18 +72,18 @@ description: 'Доводит план циклом ревью и исправл
 
 2. Прочитай отчёт и проверь, что score, порог и статус согласованы со списком пунктов.
 3. Обнови лучшую версию по правилу снапшота.
-4. Если статус `ready` — обнови front matter плана (`status: reviewed`, последние `plan_review` и `plan_review_fix`), удали снапшот, заверши успешно.
-5. **Стоп по отсутствию роста.** Если это не первая итерация и score не вырос относительно предыдущей — останови цикл, восстанови лучшую версию и сообщи, какая итерация была лучшей. Дальнейшие круги только ухудшают план.
+4. Если статус `ready`, score равен 100 и открытых пунктов нет — обнови front matter плана (`status: reviewed`, последние `plan_review` и `plan_review_fix`), удали снапшот, заверши успешно. Противоречие статуса, score и открытых пунктов при threshold 100 — `blocked: ревью нарушает контракт gate`.
+5. Если score не вырос или снизился относительно предыдущей итерации, продолжай цикл на текущей версии до 100/100 либо исчерпания `$LIMIT`; снапшот до завершения цикла не восстанавливай.
 6. Если статус `changes-required`, но проваленных пунктов нет — остановись: `blocked: ревью нарушает контракт gate`.
 7. Запусти новый изолированный субагент:
 
    ```text
    Используй eda-plan-review-fix для <REVIEW_FILE>.
    Закрой все пункты со статусом fail минимальным изменением плана, без роста объёма.
-   Верни путь к fix, before_sha256, after_sha256, before_bytes, after_bytes и закрытые пункты.
+   Верни путь к fix, status, before_sha256, after_sha256, before_bytes, after_bytes, закрытые и не закрытые пункты.
    ```
 
-8. Проверь, что `before_sha256` равен `plan_sha256` из review. Если `after_sha256` равен `before_sha256` — остановись: `blocked: fix не изменил план`.
+8. Проверь, что `before_sha256` равен `plan_sha256` из review; несовпадение — `blocked: fix нарушает SHA-256 цепочку`. Статусы fix `partial` и `no-change`, как и совпадение `after_sha256` с `before_sha256`, — отсутствие прогресса: запиши в журнал не закрытые пункты и продолжай в пределах лимита. Если fix вернул вопрос пользователю, передай его по правилам текущей среды и после ответа продолжи тот же fix; в неинтерактивной среде заверши `blocked: нужен ответ пользователя`.
 9. Если план вырос больше чем на 3%, зафиксируй это в журнале как предупреждение: рост объёма — причина следующих находок.
 10. Сохрани review и fix как предыдущую цепочку. Есть неизрасходованные итерации — начни следующую: её review заодно проверит это исправление. Иначе остановись с причиной `достигнут limit`.
 
@@ -93,7 +93,7 @@ Score сам не считай и не корректируй: он приход
 
 Сообщи:
 
-- результат: `ready`, `limit`, `нет роста` или `blocked`, и было ли последнее исправление перепроверено;
+- результат: `ready`, `limit` или `blocked`, и было ли последнее исправление перепроверено;
 - путь к плану и какая версия в нём осталась — последняя или восстановленная лучшая;
 - траекторию score по итерациям и номер лучшей;
 - последние review и fix, порог, открытые пункты;
@@ -104,8 +104,8 @@ Score сам не считай и не корректируй: он приход
 ## Чего НЕ делать
 
 - Делать review, выставлять score или править содержание плана самому.
-- Продолжать цикл, когда score не растёт.
-- Оставлять последнюю версию, если лучшая была раньше.
+- Останавливаться раньше лимита из-за отсутствия роста score, повторных находок, fix со статусом `partial` или `no-change` либо отсутствия изменений после fix.
+- Откатывать текущую версию к лучшей посреди цикла или восстанавливать снапшот поверх неперепроверенного последнего fix.
 - Выдавать план за подтверждённый, когда после последнего исправления review не было.
 - Запускать кросс-CLI, `strict`, `codex exec` или `claude -p`.
 - Писать журнал полировки в тело плана, менять код или запускать проверки проекта.

package/skills/eda-plan-review/SKILL.md

@@ -7,7 +7,7 @@ description: 'Проверяет готовый план по фиксирова
 
 Read-only проверка одного плана по списку ниже. Список конечный и один и тот же для всех планов: поэтому проверка заканчивается, а оценка растёт по мере закрытия пунктов.
 
-Ты проверяешь **исполнимость плана**, а не правильность решений. Вопрос: «можно это исполнить, не переспрашивая?» Правильность решений закрыта на этапе Plan Mode через `decision_mode`, а ошибки в чужих API дешевле ловит статический анализ на коде.
+Ты проверяешь **исполнимость плана**, а не правильность решений. Вопрос: «можно это исполнить, не переспрашивая?» Правильность решений закрыта при планировании через `decision_mode`, а ошибки в чужих API дешевле ловит статический анализ на коде.
 
 Всю работу делай сам, одним проходом. Не запускай субагентов и не дроби проверку по ролям.
 
@@ -15,7 +15,7 @@ Read-only проверка одного плана по списку ниже.
 
 Текст рядом с вызовом — главный вход. Разбери путь или название плана, «последний план», threshold и предыдущий review.
 
-`$PLAN_FILE` ищи только в `docs/artifacts/plans/`: явный путь, однозначное совпадение или самый новый файл при словах «последний план». Без плана остановись. Если вариантов несколько и выбрать нельзя — `AskUserQuestion`.
+`$PLAN_FILE` ищи только в `docs/artifacts/plans/`: явный путь, однозначное совпадение или самый новый файл при словах «последний план». Без плана остановись. Если вариантов несколько и выбрать нельзя — `AskUserQuestion` и остановка до ответа; в неинтерактивном запуске — `blocked: нужен выбор плана` со списком вариантов.
 
 ## Настройки
 
@@ -26,7 +26,7 @@ Read-only проверка одного плана по списку ниже.
 ## Подготовка
 
 1. Прочитай план целиком и вычисли SHA-256 его байтов как `$PLAN_SHA256`.
-2. Прочитай `docs/rules.md`, `docs/arch.md` и только применимые карточки из `sources.business` и `sources.references` плана. Для старого плана выбери только применимые карточки через `docs/business.md`, а для старого плана выбери только карточки затронутых компонентов через `docs/references.md`; нерелевантные не загружай.
+2. Прочитай `docs/rules.md`, `docs/arch.md` и все файлы из `sources` плана полностью; большой файл — частями до последней строки. Для старого плана без раздела `Рамка` выбери только применимые карточки через `docs/business.md`, а для старого плана выбери только карточки затронутых компонентов через `docs/references.md`; нерелевантные не загружай.
 3. Определи `$PREVIOUS_REVIEW`: явный путь либо последний review того же плана, у которого `plan_sha256` совпадает с текущим SHA-256 или с `after_sha256` связанного fix. Несвязанную историю не подмешивай.
 
 ## Чек-лист
@@ -35,26 +35,36 @@ Read-only проверка одного плана по списку ниже.
 
 | № | Пункт |
 |---|---|
-| 1 | Каждая часть запроса покрыта планом |
-| 2 | В плане нет работы вне запроса |
+| 1 | Каждая часть запроса покрыта планом; каждый сценарий `Целевого алгоритма` и каждый контракт реализует какая-то фаза |
+| 2 | В плане нет работы и механизмов вне запроса, рамки и подтверждённых решений |
 | 3 | Применимые business-карточки записаны в `sources.business` и отражены в результатах фаз |
-| 4 | План не отклоняется от `docs/rules.md`, `docs/arch.md` и карточек. Где нужно другое поведение, есть отдельный пункт на изменение самого документа до зависимой реализации |
+| 4 | `Рамка` содержит каждое применимое требование правил, архитектуры, эталонов, бизнес-карточек и `AGENTS.md` с источником и разделом; план им не противоречит. Где нужно другое поведение, есть отдельный пункт на изменение самого документа до зависимой реализации |
 | 5 | Все существенные решения имеют источник подтверждения: ответ пользователя, research или `autonomous` с причиной |
 | 6 | В плане не осталось решений, которые придётся принимать исполнителю |
 | 7 | Пакеты, библиотеки и сервисы имеют конкретные версии или ссылку на существующий lock |
-| 8 | Есть `Целевой алгоритм` и `Контракты реализации` с подразделами `Данные и БД`, `API и внешние контракты`, `Интерфейс и дизайн` и `Консольные команды` |
+| 8 | Разделы идут по порядку: `Задача`, `Рамка`, `Целевой алгоритм`, `Контракты реализации` с подразделами `Данные и БД`, `API и внешние контракты`, `Интерфейс и дизайн` и `Консольные команды`, `Фазы выполнения`, `Тесты и проверки`, `Логирование`, `Документация и эксплуатация`, `Принятые решения` |
 | 9 | Ни один факт не описан в двух разделах |
 | 10 | В плане нет сигнатур чужих методов, приведений типов, формы классов, внутренних вычислений без контрактного смысла и пересказа кодовых примеров карточек; формулы, задающие обязательное поведение, допустимы |
-| 11 | У каждой фазы есть цель, что сделать, результат и проверка |
+| 11 | У каждой фазы есть цель, что сделать, результат и проверка; проверка — команда с ожидаемым результатом или наблюдаемое состояние системы, а не «работает корректно» |
 | 12 | Каждая фаза выполнима одним агентом за один проход вместе с её проверками |
 | 13 | Команды в `Проверке` фазы существуют к моменту её выполнения или создаются в этой же фазе |
 | 14 | План доведён до точки, где результат можно запустить и проверить целиком |
 | 15 | Объём в пределах потолка: `normal` — 40 КБ, `short` — 12 КБ и 2 фазы |
 | 16 | В плане нет раздела `Открытые вопросы` и незакрытых развилок |
+| 17 | Если план затрагивает инфраструктуру, публичные индексируемые страницы или ввод-вывод на частом пути, решения этих областей записаны: переменные окружения и где они задаются, порт, healthcheck, образ, прокси и CI; адреса, 301 со старых адресов, canonical, индексация и sitemap; допустимое число запросов к БД и внешних вызовов на операцию со способом проверки |
+| 18 | `Целевой алгоритм` — сценарии из нумерованных шагов в порядке выполнения, ветки подпунктами, ошибки после шагов; таблица только для матрицы статусов и формул. В `Данных и БД` у каждой изменяемой таблицы своя таблица колонок |
+| 19 | У каждого сценария с внешним вызовом или изменением данных описаны ошибки: что видит пользователь, в каком состоянии остаются данные и как продолжить после сбоя посередине — повтор, откат или ручное действие |
+| 20 | Каждая ветка «Если …» и каждая ошибка `Целевого алгоритма` проверяются сценарием в `Тестах и проверках` или в проверке фазы по `test_strategy` |
+| 21 | Каждая сущность, поле, статус, endpoint, команда и событие называются одинаково во всех разделах и фазах; всё, на что ссылаются алгоритм и фазы, определено в `Контрактах реализации` или уже есть в проекте |
+| 22 | Если задача удаляет или переименовывает поведение, поле, endpoint, страницу или команду, план называет, что становится со старыми данными, адресами и клиентами, и как проверить, что старое поведение исчезло, а при переименовании — что оно сохранилось |
+
+### Как проверять пункт 4
+
+Сверь `Рамку` с прочитанными документами. Применимое требование, которого в ней нет, — `fail` с цитатой документа. Пункт без источника и раздела или пересказ целого документа вместо применимого требования — тоже `fail`.
 
 ### Как проверять пункт 6
 
-Ищи шесть форм. Для каждой находки приведи цитату.
+Ищи семь форм. Для каждой находки приведи цитату.
 
 | Форма | Пример | Как должно быть |
 |---|---|---|
@@ -64,11 +74,16 @@ Read-only проверка одного плана по списку ниже.
 | Число без числа | «разумный таймаут», «оптимальный размер батча», «достаточное количество попыток» | «таймаут 30 с», «батч 100» |
 | Отложенное решение | «уточнить позже», «решить при реализации», «TBD» | решено до сохранения плана |
 | Обобщение вместо требования | «обработать ошибки корректно», «добавить нужные индексы», «настроить логирование» | что происходит при ошибке; какие индексы; какие поля в логах |
+| Качество без меры | «быстро», «удобно», «надёжно», «безопасно», «масштабируемо» | «ответ до 300 мс на списке из 1000 записей», «форма проходится с клавиатуры» |
 
 Критерий: если по формулировке два исполнителя сделают существенно разные вещи — `fail`.
 
 Пункт не касается: условных веток («при ошибке — повтор» это описание ветки, а не модальность) и умолчаний, заданных `rules.md` или карточкой — их повторять в плане не нужно.
 
+### Как проверять пункты 19 и 20
+
+Пройди каждый сценарий алгоритма. Шаг, который обращается к внешнему сервису, отправляет сообщение или меняет данные, без строки `Ошибки` — `fail` по пункту 19 с цитатой шага. Затем сопоставь каждую ветку «Если …» и каждую ошибку со сценарием теста; ветка без теста — `fail` по пункту 20 с цитатой ветки. Тест на каждый шаг без ветки не требуй.
+
 ### Как проверять пункт 10
 
 Сам по себе формульный синтаксис не является основанием для `fail`. Формула или компактный псевдокод допустимы, если они точнее прозы задают бизнес-правило, контракт, инвариант или критерий приёмки. Например, `retryAt = now + 5 minutes` фиксирует обязательный момент повторной обработки и остаётся в плане. Ставь `fail` только за внутренние вычисления и кодовые детали, которые не меняют наблюдаемое поведение и не нужны исполнителю для однозначного результата.
@@ -125,7 +140,7 @@ date: <YYYY-MM-DD HH:MM>
 - **Исправление:** назвать число или сослаться на настройку, где оно задано.
 
 ## Итог
-- **Закрыто:** 14 из 16 → score 88
+- **Закрыто:** 20 из 22 → score 91
 - **Порог:** 100
 - **Результат:** changes-required
 - **Открытые пункты:** 6, 9