@gian-tiaga/eda 2.0.0 → 3.1.0

package/skills/eda-plan/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: eda-plan
-description: 'Создаёт подробный исполнимый план реализации задачи и сохраняет его в `docs/plans/`.'
+description: 'Создаёт понятный исполнимый план реализации задачи перед началом разработки.'
 ---
 
 # Скил: Планировщик (eda-plan)
 
-Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/plans/`, явно помечаешь зависимости задач и формируешь связные фазы для выполнения одним агентом. По настройкам запускаешь один специализированный `eda-plan-review`, при необходимости один `eda-plan-review-fix`, а в strict — независимую кросс-CLI проверку.
+Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/artifacts/plans/` и делишь работу на фазы, каждую из которых один агент выполняет и проверяет за один проход. По настройкам запускаешь `eda-plan-polish`, а в strict — независимую кросс-CLI проверку.
 
 ## Режим запуска
 
@@ -28,11 +28,11 @@ description: 'Создаёт подробный исполнимый план р
 
 `test_strategy` обязан менять план: `tdd_each_phase` начинает каждую фазу с тестов, `after_each_phase` добавляет тесты после реализации каждой фазы, `end_of_plan` выносит тесты в отдельную финальную фазу. `logging_strategy` обязан отражаться в алгоритме, фазах и разделе `Логирование`.
 
-`без проверок` одновременно устанавливает `plan.review: false` и `plan.strict: false`. `plan.review` и `plan.strict` независимы: можно оставить только один вид проверки. Более конкретное прямое указание в том же сообщении имеет приоритет.
+`без проверок` одновременно устанавливает `plan.review: false` и `plan.strict: false`. `plan.review` и `plan.strict` независимы.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Разбери тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+Текст рядом с вызовом скила в текущем сообщении — главный вход. Разбери тему, задачу, путь к файлу, режим, ограничения и прямые указания.
 
 Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
 
@@ -42,43 +42,38 @@ description: 'Создаёт подробный исполнимый план р
 
 Существенные решения: новые зависимости, БД/ORM/очереди/кэш/storage/search, миграции, схемы таблиц, API и внешние контракты, auth/permissions/payments/secrets/персональные данные, cloud/provider/cost/lock-in/SLA, архитектурные паттерны и публичные контракты.
 
-Если research содержит подтверждённый ответ пользователя, не спрашивай повторно. Если есть только рекомендация агента, спрашивай в `recommend_and_ask` и `ask_each_time`.
+Если research содержит подтверждённый ответ пользователя, не спрашивай повторно. Если задача меняет БД или API, проверь, подтверждены ли конкретные схемы таблиц и API-контракты; если конкретные схемы БД или API-контракты не подтверждены явно, получи подтверждение пользователя и не проектируй таблицы и маршруты молча внутри Plan Mode.
 
-Если задача меняет БД или API/внешний контракт, проверь, подтверждены ли конкретные схемы таблиц или API-контракты пользователем в текущем сообщении, правилах, архитектуре или research с подтверждённым ответом; если конкретные схемы БД или API-контракты не подтверждены явно, получи подтверждение пользователя и не проектируй таблицы и маршруты молча внутри Plan Mode.
-
-Когда инструкция говорит `AskUserQuestion`, это блокирующий вопрос:
-
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его; иначе задай один короткий вопрос в чат с вариантами 1–3 и остановись до ответа.
-- Codex exec / non-interactive: не читай stdin; если без ответа нельзя безопасно продолжать, заверши со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты.
-- Не запускай команды, которые ждут интерактивного ввода.
+Блокирующий вопрос: Claude Code — `AskUserQuestion`; Codex interactive — `request_user_input` или короткий вопрос с вариантами; Codex exec — не читай stdin, заверши со статусом `blocked: нужен ответ пользователя`.
 
 ## Обязательные правила
 
-1. Никаких правок кода, миграций, конфигов и зависимостей. Запись только в `docs/plans/`.
+1. Никаких правок кода, миграций, конфигов и зависимостей. Запись только в `docs/artifacts/plans/`.
 2. `docs/rules.md` и `docs/arch.md` — обязательная рамка планирования, а не справочный контекст. Прочитай их, выдели применимые правила и архитектурные ограничения, передай их в Plan Mode как обязательные требования.
-3. Сначала определи задачу и затронутое поведение. Если существует `docs/business.md`, по описаниям выбери только применимые карточки и прочитай их целиком; нерелевантные карточки не загружай. Business-карточки ограничивают только затронутое поведение и не расширяют задачу.
-4. Если существует `docs/references.md`, прочитай индекс, выбери только карточки для затронутых компонентов и прочитай их целиком. Их кодовые примеры задают ожидаемую форму реализации; нерелевантные карточки не загружай.
-5. Если запрос, research или черновик плана противоречит применимой business-карточке, не выбирай источник молча и не финализируй план. Покажи конфликт и через `AskUserQuestion` спроси: изменить задачу или сначала пересогласовать business-правило через `eda-business`. Конфликты с rules, architecture или references разрешай отдельным явным решением пользователя.
-6. Не переформулируй запрос пользователя перед Plan Mode: передавай оригинал, ответы на вопросы и найденную рамку.
-7. План сохраняется до любой включённой проверки, иначе ревьюерам нечего читать.
-8. Финальный план должен быть простым, исполнимым и без альтернатив вида «выбрать», «решить», «можно так или так», «предпочтительно».
-9. Если нужны пакеты, библиотеки, CLI, сервисы или другое ПО, а версия не указана в контексте или lock/config-файлах, найди последнюю стабильную версию через context7 или web search по официальным источникам. Не пиши `latest` без конкретной версии и источника.
-10. Если выбран `plan.size: short`, но задача не укладывается в ограничения, не сохраняй short-план: объясни причину, оцени нужный объём и спроси, продолжать в `normal` или сузить задачу.
-11. Каждой задаче в фазах присвой уникальный ID и укажи её прямые зависимости. Собери каждую фазу вокруг одной связной цели и объёма, который один исполнитель может реализовать и проверить за один проход; слишком крупную или несвязную фазу раздели.
+3. Сначала определи задачу и затронутое поведение. Если есть `docs/business.md`, прочитай целиком только применимые карточки. Карточка задаёт требования к тому поведению, которое задача уже затрагивает; работу, которую пользователь не просил, она в план не добавляет. Если карточка описывает больше сценариев, чем затронуто задачей, остальные в план не идут.
+4. Если нужный пункт в них отсутствует, описан не полностью или задача расширяет существующее business-правило, добавь до соответствующей реализации отдельную фазу или пункт `Дополнить бизнесовые правила: <конкретная тема и изменение>`. Чисто техническое изменение без изменения целевого поведения этого не требует.
+5. Если есть `docs/references.md`, прочитай применимые карточки затронутых компонентов. Их кодовые примеры задают форму реализации.
+6. Конфликт запроса, research или черновика плана с применимой business-карточкой не разрешай молча и не финализируй план: покажи конфликт и через `AskUserQuestion` спроси, менять задачу или сначала пересогласовать правило через `eda-business`.
+7. План не отклоняется от `docs/rules.md`, `docs/arch.md` и карточек. Если нужное решение им противоречит, план сначала меняет сам документ: добавь отдельный пункт `Обновить правила` или `Обновить архитектуру: <тема и изменение>` до зависимой реализации. Отклонения «с причиной в докблоке» не бывает — она разводит код и документацию.
+8. Не переформулируй запрос пользователя перед Plan Mode: передавай оригинал, ответы на вопросы и найденную рамку.
+9. План сохраняется до любой включённой проверки.
+10. План фиксирует решения, границы, контракты и критерии приёмки. Он не фиксирует реализацию: сигнатуры чужих методов, формулы, приведения типов, порядок строк внутри метода, форму классов. Если утверждение можно проверить только запуском кода, оно относится к code review, а не к плану.
+11. Не пересказывай прозой то, что уже лежит рядом: правила, архитектуру и кодовые примеры карточек. Ссылайся на них.
+12. Один факт — одно место. Поведение описано в `Целевом алгоритме`, контракты — в `Контрактах реализации`, фаза на них опирается и не повторяет их.
+13. План доводится до первой точки, где результат можно запустить и проверить целиком. Дальше планируй следующей вехой, на фактах.
+14. Если нужны пакеты, библиотеки, CLI или сервисы, а версия не указана в контексте или lock-файлах, найди последнюю стабильную версию через context7 или web search. Не пиши `latest` без конкретной версии и источника.
+15. Финальный план прост, исполним и без альтернатив вида «выбрать», «решить», «можно так или так», «предпочтительно».
 
 ## Этапы
 
 ### 1. Собрать контекст
 
-- Разбери текущий вход и настройки.
-- Прочитай `docs/rules.md`, `docs/arch.md`, если они есть; выпиши применимые команды проверки, требования к тестам, границы модулей, зависимости, API, миграции, безопасность, документацию и локальные запреты.
-- Если есть `docs/business.md`, сначала установи границы задачи, затем по описаниям выбери только карточки затронутого поведения и выпиши применимые требования, сценарии и критерии приёмки. Если подходящих карточек нет, продолжай без business-контекста.
-- Если есть `docs/references.md`, выбери по индексу применимые карточки, прочитай их и выпиши обязательные элементы кодовых примеров.
-- Research подтягивай без вопроса, если путь указан; если в сообщении есть описание задачи без research-файла — используй описание как контекст и не спрашивай research автоматически. Если пользователь явно просит research, но файл не указал, предложи последние файлы из `docs/researches/` и вариант «нет».
-- Проверь версии нужных пакетов/ПО, если они не зафиксированы в запросе, правилах, архитектуре, research или lock/config-файлах.
+- Разбери вход и настройки.
+- Прочитай `docs/rules.md` и `docs/arch.md`; выпиши применимые команды проверки, требования к тестам, границы модулей, зависимости, миграции, безопасность и локальные запреты.
+- Выбери и прочитай применимые карточки `docs/business.md` и `docs/references.md`. Нерелевантные не загружай.
+- Research подтягивай без вопроса, если путь указан; если в сообщении есть описание задачи без research-файла, используй описание как контекст и не спрашивай research автоматически. Если пользователь явно просит research, но файл не указал, предложи последние файлы из `docs/artifacts/researches/` и вариант «нет».
+- Проверь версии нужных пакетов, если они не зафиксированы.
 - Закрой существенные решения по `decision_mode`.
-- Для `short` оцени число фаз, файлов, строк diff и ревьюируемость за один проход.
 
 ### 2. Запустить Plan Mode
 
@@ -86,18 +81,18 @@ description: 'Создаёт подробный исполнимый план р
 
 1. Дословный запрос пользователя.
 2. `plan_size`, `decision_mode`, `test_strategy`, `logging_strategy`.
-3. Все подтверждённые существенные решения и пары «вопрос → ответ».
-4. Найденные версии пакетов/ПО и источники.
-5. Пути к `docs/rules.md`, `docs/arch.md`, применимым карточкам, research и выписку обязательных элементов рамки.
-6. Требование: план следует правилам, архитектуре и применимым эталонам с указанным приоритетом; при конфликте или необоснованном отклонении остановиться и спросить пользователя.
-7. Требование: финальный план нормализуется в структуру ниже, не смешивает исследование с исполнением и не добавляет неподтверждённые существенные решения.
-8. Требование: каждая задача получает уникальный ID и прямые зависимости, а каждая фаза образует связный объём работы для одного исполнителя.
+3. Подтверждённые существенные решения и пары «вопрос → ответ».
+4. Найденные версии пакетов и источники.
+5. Пути к `docs/rules.md`, `docs/arch.md`, применимым карточкам и research с выпиской обязательных требований рамки.
+6. Требование: план следует правилам, архитектуре и применимым эталонам. Если нужное решение им противоречит, план сначала меняет сам документ отдельным пунктом, а не отклоняется от него.
+7. Требование: план нормализуется в структуру ниже и делится на фазы, каждую из которых один агент выполняет и проверяет за один проход.
+8. Требование: конкретика не равна максимальной подробности. План описывает, что и зачем меняется, а не как это написать: не пересказывать запрос и существующий код, не повторять один контракт в нескольких разделах, не выдумывать пути, символы или API ради видимости конкретики. Реализацию задают `docs/rules.md`, `docs/arch.md` и карточки.
 
 Не выходи из Plan Mode, пока пользователь не подтвердил план.
 
 ### 3. Нормализовать и сохранить
 
-Сохрани подтверждённый план в `docs/plans/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Смысл решений не меняй без вопроса, но форму, порядок и ясность правь обязательно.
+Сохрани подтверждённый план в `docs/artifacts/plans/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Смысл решений не меняй без вопроса, форму и ясность правь обязательно.
 
 ```markdown
 ---
@@ -108,8 +103,8 @@ plan_size: <normal | short>
 decision_mode: <autonomous | recommend_and_ask | ask_each_time>
 status: <draft | meta-reviewed | reviewed>
 reviewer: <pending | none | claude | codex>
-plan_review: <docs/plan-reviews/... | none>
-plan_review_fix: <docs/plan-review-fixes/... | none>
+plan_review: <docs/artifacts/plan-reviews/... | none>
+plan_review_fix: <docs/artifacts/plan-review-fixes/... | none>
 test_strategy: <after_each_phase | tdd_each_phase | end_of_plan>
 logging_strategy: <debug_precise | standard>
 sources:
@@ -123,131 +118,117 @@ sources:
 # План реализации
 
 ## Задача
-Коротко: что нужно реализовать и какой результат считается готовым.
+Что нужно реализовать и какой результат считается готовым. Что в план не входит, если границу легко перепутать.
 
 ## Целевой алгоритм
-Сквозное поведение системы от входного события до финального состояния.
+Сквозное поведение системы от входного события до финального состояния. Единственное место, где описано поведение. Состояния и переходы — таблицей, проза только для связок.
 
 ## Контракты реализации
 
 ### Данные и БД
-Если БД не меняется: `Не затрагивается`. Если меняется, укажи таблицы, поля, типы, обязательность, default, связи, индексы, unique, миграции, совместимость со старыми данными, backfill и rollback при необходимости.
+Если БД не меняется: `Не затрагивается`. Иначе таблицы, поля, типы, обязательность, default, связи, индексы, unique, миграции, совместимость со старыми данными и rollback.
 
 ### API и внешние контракты
-Если API и внешние контракты не меняются: `Не затрагивается`. Если меняются, укажи метод и путь, auth/permissions, request/query/body, response, ошибки/status codes, webhooks/events/queues/внешние сервисы при наличии.
+Если не меняются: `Не затрагивается`. Иначе метод и путь, auth/permissions, request/query/body, response, ошибки и status codes, события, очереди и внешние сервисы.
 
 ## Фазы выполнения
 
 ### 1. <Название фазы>
-Цель: <зачем нужна фаза>.
+Цель: одно предложение — зачем нужна фаза.
 
-Что сделать:
-- `[1.1]` <конкретная задача>. Зависит от: `—`.
-- `[1.2]` <конкретная задача>. Зависит от: `[1.1]`.
-- `[1.3]` <конкретная задача>. Зависит от: `[1.2]`.
+Что сделать: несколько предложений — что появляется в системе и как части связаны между собой. Не как это писать.
 
-Результат: <готовое состояние>.
-
-Сценарии тестирования:
-- <сценарии>
+Результат: проверяемое состояние системы после фазы.
 
 Проверка:
-- <команда или критерий>
+- команда или критерий готовности.
 
 ## Тесты
-Стратегия: <как применён test_strategy>.
+Стратегия и сценарии по поведению — в одном месте, а не внутри каждой фазы.
 
 ## Логирование
-Стратегия: <как применён logging_strategy>.
+Стратегия, уровни, обязательные поля и что писать запрещено.
 
 ## Документация и эксплуатация
-Что обновить в env/docs/runbook и что важно для релиза.
-```
+Что обновить в env, docs, runbook и что важно для релиза.
 
 ## Принятые решения
-Выбранные архитектурные и продуктовые решения без вариантов. Для существенных решений укажи источник подтверждения: ответ пользователя, research с ответом пользователя или `decision_mode: autonomous` с причиной. Для `short` укажи ожидаемый объём.
+Выбранные решения без вариантов. Для существенных — источник подтверждения: ответ пользователя, research или `autonomous` с причиной.
+```
 
 Правила структуры:
 
-- Риски не выносятся в отдельный обязательный раздел; закрытые риски встраиваются в решения, фазы, сценарии тестирования, проверки, логирование или эксплуатацию.
-- Отдельный раздел порядка выполнения не нужен: основной поток задаётся номерами фаз, ID задач и их зависимостями.
-- ID задачи имеет формат `[<номер фазы>.<номер задачи>]` и уникален во всём плане. В `Зависит от` перечисляй только прямые зависимости; `—` означает, что задачу можно начинать независимо от других задач плана.
-- Одну фазу целиком выполняет один изолированный субагент `eda-plan-execute`. Задачи фазы должны относиться к общей цели, иметь согласованный scope и помещаться в один исполнительский проход вместе с точечными и фазовыми проверками.
-- В `Контракты реализации` попадают схемы данных, БД, API и внешние контракты; если область не затрагивается, напиши `Не затрагивается`.
-- В фазах нельзя ограничиваться общими формулировками вроде «обновить UI», «добавить сервис», «реализовать логику». Для UI опиши пользовательский сценарий, состояния успеха/ошибки и видимый результат; для внутренней логики — ответственность частей, поток данных, состояния и ошибки.
-- Если нужен раздел `Открытые вопросы`, оставь `status: draft`, сохрани файл и не запускай plan-review до ответа пользователя.
+- Задач с идентификаторами внутри фаз нет. Порядок фаз задаёт порядок работы.
+- Фаза — это цель, что сделать, результат и проверка. Ничего больше.
+- В `Что сделать` пиши связным текстом, а не перечнем файлов: должно быть видно, как части работают вместе. Каждое предложение говорит, что появится, как это связано с остальным или чем ограничено. Если её удаление ничего из этого не меняет, удали её из плана.
+- В фазах нельзя ограничиваться общими формулировками вроде «обновить UI», «добавить сервис», «реализовать логику». Для UI опиши пользовательский сценарий, состояния успеха и ошибки и видимый результат; для внутренней логики — ответственность частей, поток данных, состояния и ошибки.
+- Не описывай в фазе то, что уже зафиксировано в `Целевом алгоритме`, `Контрактах` или `Принятых решениях`: сошлись на них.
+- Риски и порядок выполнения отдельными разделами не выносятся: закрытые риски встраиваются в решения, фазы, тесты и проверки.
+- Раздела `Открытые вопросы` в плане нет. Незакрытая развилка — это блокирующий вопрос пользователю до сохранения, а не пункт в файле.
 
 Quality gate перед сохранением и после каждой включённой проверки:
 
-- есть `Целевой алгоритм` и `Контракты реализации` с подразделами `Данные и БД`, `API и внешние контракты`;
-- применимые business-карточки выбраны только после определения scope задачи, записаны в `sources.business` и отражены в поведении и критериях приёмки;
-- план строго следует `docs/rules.md` и `docs/arch.md`;
-- план следует применимым reference-карточкам или явно фиксирует подтверждённую причину отклонения;
-- нет конфликтов с правилами, архитектурой, границами модулей, API, миграциями, зависимостями и командами проверки;
-- БД/API изменения описаны конкретно, а не общими словами;
-- каждая фаза имеет цель, шаги, результат, сценарии тестирования и проверку;
-- каждая задача имеет уникальный ID и прямые зависимости, ссылки на ID существуют, а каждая фаза связна и выполнима одним агентом за один проход;
-- `test_strategy` и `logging_strategy` применены в фазах и отдельных разделах;
-- для `short` не больше 2 фаз и явно указан ожидаемый объём;
-- пакеты/ПО имеют конкретные версии или ссылку на существующий lock/config;
-- нет неподтверждённых существенных решений и неразрешённых альтернатив;
+- есть `Целевой алгоритм` и `Контракты реализации` с обоими подразделами;
+- применимые business-карточки выбраны после определения scope, записаны в `sources.business` и отражены в критериях приёмки;
+- каждый отсутствующий, неполный или расширяемый пункт целевого поведения покрыт отдельной задачей `Дополнить бизнесовые правила` до зависимой реализации; для чисто технических изменений такая задача не добавлена;
+- план строго следует `docs/rules.md` и `docs/arch.md`, а также применимым reference-карточкам; там, где нужно другое поведение, есть отдельный пункт на изменение самого документа до зависимой реализации;
+- каждая фаза имеет цель, что сделать, результат и проверку и выполнима одним агентом за один проход;
+- в фазах нет сигнатур, формул, приведений типов и пересказа карточек;
+- ни один факт не описан в двух разделах;
+- `test_strategy` и `logging_strategy` применены;
+- пакеты имеют конкретные версии или ссылку на существующий lock;
+- нет неподтверждённых существенных решений, неразрешённых альтернатив и открытых вопросов;
+- нет общих призывов, повторов и пояснений, удаление которых не меняет действия, контракты, проверки или принятые решения;
+- объём: `normal` — не больше 40 КБ, `short` — не больше 12 КБ и 2 фаз. Это стоп, а не цель: план настолько короткий, насколько позволяет однозначность. При превышении раздели план по вехам и предложи пользователю первую;
 - план можно передать в `eda-plan-execute` без нового исследования.
 
-### 4. Специализированный plan-review и один fix
-
-Если `plan.review: false`, пропусти этап, оставь `plan_review: none`, `plan_review_fix: none` и перейди к strict-этапу или финалу. Не запускай старое общее мета-ревью.
+### 4. Полировка плана
 
-Если `plan.review: true`, каждый вложенный скил запускай в отдельном изолированном субагенте с чистым контекстом. Основной планировщик не делает их работу. При недоступности нативных субагентов остановись; не используй CLI-fallback для этого этапа.
+Если `plan.review: false`, пропусти этап, оставь `plan_review: none`, `plan_review_fix: none` и перейди дальше.
 
-1. Запусти один `eda-plan-review`:
+Иначе запусти `eda-plan-polish` в отдельном изолированном субагенте с чистым контекстом. Основной планировщик не делает review или fix сам.
 
-   ```text
-   Используй eda-plan-review для <PLAN_FILE>.
-   Исходная задача и решения: <текущий запрос и ответы пользователя>.
-   Верни путь к review, status, score, threshold и required/optional ID.
-   ```
+1. Запусти один `eda-plan-polish`:
 
-2. Если review имеет `status: ready`, обнови front matter: `status: reviewed`, `plan_review: <REVIEW_FILE>`, `plan_review_fix: none`. Содержательных правок не делай.
-3. Если review имеет `status: changes-required`, запусти ровно один новый изолированный субагент:
-
-   ```text
-   Используй eda-plan-review-fix apply-optional для <REVIEW_FILE>.
-   Примени все required, самостоятельно разбери optional и сохрани waived с причинами.
-   Верни путь к fix, before_sha256, after_sha256, applied и waived ID.
-   ```
+```text
+Используй eda-plan-polish для <PLAN_FILE>.
+Исходная задача и решения: <текущий запрос и ответы пользователя>.
+Верни результат, последний review/fix, score, threshold и открытые ID.
+```
 
-4. Проверь связь SHA-256. После успешного fix установи `status: meta-reviewed`, `plan_review: <REVIEW_FILE>`, `plan_review_fix: <FIX_FILE>` и снова прогони локальный quality gate структуры плана. Не запускай второй review внутри `eda-plan`.
-5. При `blocked` передай один конкретный вопрос пользователю и продолжи тот же вложенный шаг после ответа.
+Проверь артефакты и снова прогони quality gate. При `ready` убедись, что front matter содержит `status: reviewed` и последние пути review/fix. Содержательных правок сам не делай. При limit, отсутствии прогресса или `blocked` не выдавай план за подтверждённый.
 
-`meta-reviewed` означает один review и один неперепроверенный fix и остаётся допустимым входом для `eda-plan-execute`. Подтверждённый gate после fix выполняет отдельный `eda-plan-polish`.
+При недоступности нативных субагентов остановись; не используй CLI-fallback для этого этапа.
 
-### 5. Strict: кросс-CLI и допил
+### 5. Strict: кросс-CLI
 
-`plan.strict` не зависит от `plan.review`. Обычный режим пропускает этот этап. В `strict` отдай файл соседнему CLI:
+`plan.strict` не зависит от `plan.review`. Обычный режим этап пропускает. В `strict` отдай файл соседнему CLI:
 
 ```bash
-codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, применимые карточки из sources.business и sources.references и связанное исследование из sources.research при наличии. Затем глубоко проверь план по релевантному коду: открой файлы, модули, API и тесты, которые следуют из плана, и оцени фактическую реализуемость. Критическое ревью на русском: пропущенные шаги, нарушения бизнес-требований, неучтённые зависимости, нарушения правил, архитектуры и эталонов, необоснованные отклонения, скрытые риски, недостающие тесты и шаги без критериев готовности. Список '- [тип] описание — что предлагаешь'." > "${PLAN_FILE%.md}_review.md"
+codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md и применимые карточки из sources. Проверь план по релевантному коду: открой файлы, модули и тесты, которые следуют из плана, и оцени фактическую реализуемость. Верни только конкретные ошибки, которые обязательно исправить: место, доказательство, риск и минимальную правку. Не предлагай расширение текста и стилистику. Список '- [тип] описание — что исправить'." > "${PLAN_FILE%.md}_review.md"
 ```
 
 Если ты в Codex — запускай `claude -p` с тем же заданием. Если соседней CLI нет, спроси, продолжать без ревью или прервать.
 
-Бесспорные замечания внеси в план, спорные вынеси через `AskUserQuestion`, отклонённые зафиксируй с причиной в `## Реакция на ревью`. Поменяй `status: draft` или `status: meta-reviewed` на `reviewed`, покажи дифф.
+Бесспорные замечания внеси в план, спорные вынеси через `AskUserQuestion`, отклонённые зафиксируй с причиной в `## Реакция на ревью`. Поставь `status: reviewed`, покажи дифф.
 
 ### 6. Финал
 
-Коротко сообщи режим, выполнялись ли plan-review/fix и strict, путь к плану, пути к plan-review/plan-review-fix и strict-review при наличии, итоговый status, 3–5 главных шагов и что дальше делает `eda-plan-execute`. Для `meta-reviewed` явно укажи, что подтверждающий gate выполняет `eda-plan-polish`.
+Коротко сообщи режим, выполнялись ли polish и strict, путь к плану, пути к последним артефактам проверок, итоговый статус, открытые вопросы, 3–5 главных шагов и что дальше делает `eda-plan-execute`.
 
 ## Чего НЕ делать
 
 - Править код, миграции, конфиги или зависимости.
 - Считать `docs/rules.md` и `docs/arch.md` просто контекстом для ознакомления.
-- Игнорировать применимую карточку или молча отклоняться от её примера.
-- Сохранять план, который противоречит правилам или архитектуре проекта.
-- Обходить правило или архитектурное ограничение без явного решения пользователя.
-- Задавать вопросы без блокировки и продолжать до ответа.
-- Переформулировать запрос пользователя своими словами перед Plan Mode.
+- Писать в план сигнатуры чужих методов, формулы, приведения типов и форму классов.
+- Пересказывать прозой правила, архитектуру и кодовые примеры карточек.
+- Отклоняться от правил и архитектуры «с причиной» вместо того, чтобы менять сам документ.
+- Разбивать фазы на задачи с идентификаторами и графом зависимостей.
+- Повторять один факт в нескольких разделах.
+- Планировать дальше первой проверяемой вехи и добивать план до потолка объёма.
+- Переформулировать запрос пользователя перед Plan Mode.
 - Сохранять сырой текст Plan Mode без нормализации.
-- Оставлять финальный план исследованием, списком наблюдений или журналом мета-ревью.
-- Смешивать альтернативы с принятыми решениями.
-- Выполнять plan-review или plan-review-fix основным агентом, запускать старые три общих ревьюера или делать второй review внутри `eda-plan`.
+- Оставлять план исследованием, списком наблюдений или журналом ревью.
+- Сохранять план с открытыми вопросами вместо того, чтобы задать их пользователю.
+- Выполнять plan-review, plan-review-fix или plan-polish основным агентом.
 - Пропускать кросс-CLI молча в `strict`: если CLI нет, спроси.