@gian-tiaga/eda 0.6.2 → 0.7.0

package/skills/eda-plan.md

@@ -1,257 +1,94 @@
 ---
 name: eda-plan
-description: 'Пишет план реализации по тексту рядом с вызовом или указанному research-файлу через стандартный Plan Mode (Claude Code / Codex). Перед планированием читает docs/rules.md и docs/arch.md как обязательную рамку: выделяет применимые правила и архитектурные ограничения, передаёт их в Plan Mode и не финализирует план при конфликте без ответа пользователя. Research подтягивает без вопроса, если он указан или явно нужен. Поддерживает `short` для небольших фич: 1–2 фазы и компактный ревьюируемый объём. Фиксирует режим принятия решений, стратегию тестов и логирования из docs/settings.yaml или уточняет их у пользователя. Нормализует результат в исполнимый план с алгоритмом, фазами, проверками и без неразрешённых альтернатив; сохраняет его в docs/plans/. Всегда проверяет план тремя субагентами/моделями. Кросс-CLI включается флагом `strict` или настройкой `defaults.strict: true`.'
+description: 'Пишет исполнимый план реализации через стандартный Plan Mode Claude Code / Codex и сохраняет его в docs/plans/. Перед планированием читает docs/rules.md и docs/arch.md как обязательную рамку, подтягивает указанный research, фиксирует strict/short, decision_mode, test_strategy и logging_strategy из docs/settings.yaml или текущего запроса. Не оставляет неподтверждённых существенных решений, явно описывает БД/API-контракты, проверяет версии пакетов и ПО по актуальным источникам. После сохранения всегда запускает три параллельных мета-ревьюера; strict добавляет кросс-CLI.'
 ---
 
 # Скил: Планировщик (eda-plan)
 
-Собираешь контекст, прогоняешь задачу через **стандартный Plan Mode** хост-агента, нормализуешь результат в исполнимый план и сохраняешь его в файл. Затем три параллельных субагента/модели проверяют план на реалистичность — главный планировщик сам решает, что применить из их предложений. При `strict` — ещё и кросс-CLI на втором круге.
+Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/plans/`, затем проверяешь план тремя параллельными субагентами/моделями. В `strict` добавляешь кросс-CLI проверку.
 
-## Режимы вызова
+## Режим запуска
 
-| Режим | Запуск | Что делает |
+Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
+
+Дефолты: `defaults.strict: false`, `defaults.plan_size: normal`, `defaults.decision_mode: recommend_and_ask`, `defaults.test_strategy: ask_each_time`, `defaults.logging_strategy: ask_each_time`.
+
+| Настройка | Значения | Аргументы в сообщении |
 |---|---|---|
-| Обычный | `eda-plan <тема>` | Этапы 1–6 + финал. Кросс-CLI не запускается. |
-| Строгий | `eda-plan strict <тема>` | + кросс-CLI соседним агентом + допил. |
-| Короткий | `eda-plan short <тема>` | План для небольшой фичи: 1–2 фазы и компактный ревьюируемый объём. |
-| Короткий строгий | `eda-plan strict short <тема>` | `short`-план + кросс-CLI соседним агентом + допил. |
+| `defaults.strict` | `true`, `false` | `strict`; выключение: `normal`, `без strict`, `без строгого режима` |
+| `defaults.plan_size` | `normal`, `short`, `ask_each_time` | `short`; обычный: `обычный план`, `не short` |
+| `defaults.decision_mode` | `autonomous`, `recommend_and_ask`, `ask_each_time` | `autonomous`, `recommend_and_ask`, `ask_each_time`, «сам выбирай», «рекомендуй и спрашивай», «спрашивай всё» |
+| `defaults.test_strategy` | `after_each_phase`, `tdd_each_phase`, `end_of_plan`, `ask_each_time` | явное указание стратегии тестов |
+| `defaults.logging_strategy` | `debug_precise`, `standard`, `ask_each_time` | явное указание стратегии логирования |
 
-Если в `docs/settings.yaml` указано `defaults.strict: true`, строгий режим включён по умолчанию. Явное указание пользователя в текущем сообщении важнее настройки: `strict` включает строгий режим, `normal` / `без strict` / `без строгого режима` выключает его для текущего запуска.
+Если значение из настроек неизвестно, используй дефолт. Если итоговое значение `plan_size`, `test_strategy` или `logging_strategy` равно `ask_each_time`, задай блокирующий вопрос, кроме случая, когда пользователь уже выбрал значение в текущем сообщении.
 
-Размер плана берётся из явного указания пользователя или `defaults.plan_size` в `docs/settings.yaml`. Явное `short` включает `plan_size: short`; явное `normal` / `обычный план` включает `plan_size: normal`.
+Варианты вопросов: размер плана — `normal` / `short`; тесты — `after_each_phase` / `tdd_each_phase` / `end_of_plan`; логирование — `debug_precise` / `standard`.
+
+`test_strategy` обязан менять план: `tdd_each_phase` начинает каждую фазу с тестов, `after_each_phase` добавляет тесты после реализации каждой фазы, `end_of_plan` выносит тесты в отдельную финальную фазу. `logging_strategy` обязан отражаться в алгоритме, фазах и разделе `Логирование`.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Разбери тему, задачу, путь к файлу, режим, ограничения и прямые указания.
 
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
 
-## Настройки проекта
+## Вопросы и решения
 
-Перед выбором режима прочитай `docs/settings.yaml`, если файл есть.
+`decision_mode`: `autonomous` — выбирай сам и записывай причину; `recommend_and_ask` — рекомендуй вариант и спрашивай по существенным решениям; `ask_each_time` — спрашивай по каждой значимой развилке.
 
-Если файла нет — используй значение по умолчанию:
-- `defaults.strict: false`
-- `defaults.plan_size: normal`
-- `defaults.decision_mode: recommend_and_ask`
-- `defaults.test_strategy: ask_each_time`
-- `defaults.logging_strategy: ask_each_time`
+Существенные решения: новые зависимости, БД/ORM/очереди/кэш/storage/search, миграции, схемы таблиц, API и внешние контракты, auth/permissions/payments/secrets/персональные данные, cloud/provider/cost/lock-in/SLA, архитектурные паттерны и публичные контракты.
 
-Прямое указание пользователя в текущем сообщении важнее `docs/settings.yaml`.
+Если research содержит подтверждённый ответ пользователя, не спрашивай повторно. Если есть только рекомендация агента, спрашивай в `recommend_and_ask` и `ask_each_time`.
 
-Поддерживаемые настройки:
+Если задача меняет БД или API/внешний контракт, проверь, подтверждены ли конкретные схемы таблиц или API-контракты пользователем в текущем сообщении, правилах, архитектуре или research с подтверждённым ответом; если конкретные схемы БД или API-контракты не подтверждены явно, получи подтверждение пользователя и не проектируй таблицы и маршруты молча внутри Plan Mode.
+
+Когда инструкция говорит `AskUserQuestion`, это блокирующий вопрос:
 
-| Ключ | Значения | Что значит |
-|---|---|---|
-| `defaults.strict` | `true`, `false` | Включает или выключает строгий режим по умолчанию. |
-| `defaults.plan_size` | `normal`, `short`, `ask_each_time` | Размер плана по умолчанию для `eda-plan`: обычный, короткий или спрашивать каждый раз. |
-| `defaults.decision_mode` | `autonomous`, `recommend_and_ask`, `ask_each_time` | Как `eda-explore` и `eda-plan` закрывают существенные решения: сами, через рекомендацию с подтверждением или через вопрос по каждой значимой развилке. |
-| `defaults.test_strategy` | `after_each_phase` | Тесты пишутся и запускаются после каждой фазы плана. |
-| `defaults.test_strategy` | `tdd_each_phase` | В начале каждой фазы сначала пишутся тесты, затем код под них. |
-| `defaults.test_strategy` | `end_of_plan` | Тесты пишутся в конце плана отдельной финальной фазой. |
-| `defaults.test_strategy` | `ask_each_time` | В начале каждого планирования задай пользователю вопрос о стратегии тестов. |
-| `defaults.logging_strategy` | `debug_precise` | Дебаг-логирование на каждом важном шаге для точной отладки. |
-| `defaults.logging_strategy` | `standard` | Стандартные `info`, `warning`, `error` там, где это нужно для эксплуатации и диагностики. |
-| `defaults.logging_strategy` | `ask_each_time` | В начале каждого планирования задай пользователю вопрос о стратегии логирования. |
-
-Если `defaults.plan_size` отсутствует или неизвестен, считай его `normal`. Если настройка равна `ask_each_time`, в начале каждого планирования задай пользователю вопрос о размере плана.
-
-Если `defaults.decision_mode` отсутствует или неизвестен, считай его `recommend_and_ask`.
-
-Если `defaults.test_strategy` или `defaults.logging_strategy` отсутствует или неизвестен, считай его `ask_each_time`.
-
-В самом начале составления плана, после чтения текущего сообщения и `docs/settings.yaml`, но до Plan Mode и до содержательного планирования, зафиксируй:
-- размер плана;
-- режим принятия решений;
-- стратегию тестов;
-- стратегию логирования.
-
-Если в `defaults.plan_size`, `defaults.test_strategy` или `defaults.logging_strategy` стоит `ask_each_time`, задай блокирующий `AskUserQuestion` с вариантами для этой настройки. Если пользователь уже явно выбрал размер плана или стратегию в текущем сообщении, используй её без дополнительного вопроса.
-
-Варианты вопроса про размер плана:
-1. `normal` — обычный план без искусственного ограничения по количеству фаз.
-2. `short` — короткий план на 1–2 фазы для локальной правки.
-
-Варианты вопроса про тесты:
-1. `after_each_phase` — писать и запускать тесты после каждой фазы.
-2. `tdd_each_phase` — начинать каждую фазу с тестов, затем писать код.
-3. `end_of_plan` — писать тесты в конце плана отдельной фазой.
-
-Варианты вопроса про логирование:
-1. `debug_precise` — дебаг-логи в каждом важном шаге для точной отладки.
-2. `standard` — `info`, `warning`, `error` там, где это нужно.
-
-Выбранные значения передай в Plan Mode и обязательно зафиксируй в финальном плане в YAML-шапке, `Принятых решениях`, `Фазах выполнения`, `Тестах` и `Логировании`.
-
-## Режим принятия решений
-
-`decision_mode: autonomous` — агент сам выбирает по коду, правилам, архитектуре, источникам и рискам, затем записывает причину.
-
-`decision_mode: recommend_and_ask` — дефолт. Агент исследует варианты, рекомендует один, но по существенным решениям задаёт блокирующий вопрос до Plan Mode или до финализации.
-
-`decision_mode: ask_each_time` — агент спрашивает по каждой значимой развилке, даже если есть сильная рекомендация.
-
-Существенные решения — это решения, которые меняют архитектуру, зависимости, стоимость, безопасность, эксплуатацию или будущую миграцию проекта. Всегда считай существенными:
-- выбор нового пакета, библиотеки, фреймворка, SDK, CLI или сервиса;
-- выбор базы данных, ORM/query builder, очереди, кэша, storage, search, background jobs;
-- миграции данных, изменение схемы, формат хранения или стратегия совместимости;
-- новые или изменённые схемы таблиц: поля, типы, связи, индексы, уникальные ограничения;
-- новые или изменённые API/внешние контракты: маршруты, auth/permissions, request/query/body, response, ошибки и статус-коды;
-- auth, permissions, payments, crypto, secrets, персональные данные и другие security-sensitive решения;
-- cloud/provider choices, managed services, лицензии, cost/lock-in и SLA;
-- архитектурные паттерны, затрагивающие несколько модулей или публичные контракты.
-
-Если research уже содержит вопрос и ответ пользователя по конкретному существенному решению, используй этот ответ без повторного вопроса. Если research содержит только рекомендацию или выбор агента без ответа пользователя, в `recommend_and_ask` и `ask_each_time` спроси подтверждение до Plan Mode.
-
-## Главные правила
-
-1. **Никаких правок кода.** Запись только в `docs/plans/`.
-2. **Интерактивные вопросы** — по разделу ниже.
-3. **`docs/rules.md` и `docs/arch.md` — обязательная рамка планирования, а не справочный контекст.** Перед Plan Mode прочитай оба файла, если они есть, выдели применимые к задаче правила и архитектурные ограничения и передай их в Plan Mode как обязательные требования. Финальный план должен строго следовать этим правилам и архитектуре.
-4. **Конфликт с рамкой проекта блокирует финализацию.** Если запрос пользователя, research, черновик Plan Mode или отдельное решение противоречит `docs/rules.md` или `docs/arch.md`, не скрывай конфликт и не сохраняй план как готовый. Остановись и задай `AskUserQuestion`: изменить подход под правила/архитектуру, изменить сами правила/архитектуру отдельной задачей или прервать планирование.
-5. **Plan Mode — главный инструмент.** Он даёт содержательный черновик, но финальный файл обязан быть нормализован в формат этого скилла.
-6. **Не переформулируй запрос пользователя** перед Plan Mode. Уйдёт оригинал + ответы на уточнения. Своя цель/критерии разводят смысл.
-7. **План сохраняется в файл до любой верификации** — иначе ревьюеру нечего читать.
-8. **Максимально простой язык.** Пиши план так, чтобы его понял человек без глубокого погружения в код. Избегай жаргона, сокращений и внутренних названий без необходимости. Термины используй только когда без них нельзя точно донести смысл, и сразу объясняй их простыми словами.
-9. **Диаграммы — желательно, не любой ценой.** Линейный план — диаграмма не нужна.
-10. **Таблицы > сплошной текст** для структурируемых данных.
-11. **Финальный план — не исследование.** Исследовательские факты идут в контекст, выбранные подходы — в решения, исполнимые шаги — в фазы.
-12. **Не оставляй неоднозначности.** Если в плане остаётся «выбрать», «решить», «можно так или так», «предпочтительно» — задай вопрос до финализации или зафиксируй одно принятое решение. Существенные решения фиксируй только по правилам `decision_mode`.
-13. **Версии пакетов и ПО проверяй до планирования.** Если для задачи нужно устанавливать пакет, библиотеку, сервис, CLI или другое ПО, а версия не указана в контексте, используй `context7`, если он доступен, или веб-поиск, чтобы найти актуальную последнюю стабильную версию. Зафиксируй найденную версию и источник в контексте/решениях плана. Не оставляй в плане «установить latest» без конкретной версии.
-
-## Размер плана
-
-`plan_size: normal` — обычный план без искусственного ограничения по количеству фаз.
-
-`plan_size: short` — план для небольшой фичи или локальной правки, которую можно легко отревьюить за один проход.
-
-Ограничения `short`:
-- 1–2 фазы максимум;
-- ориентир: до 5–10 затронутых файлов;
-- ориентир: до 400 строк осмысленного diff;
-- изменения должны быть локальными и понятными для ревью за один проход;
-- если файлов больше 10, но изменения однотипные и маленькие, `short` допустим только если это явно объяснено в плане;
-- сгенерированные файлы, lock-файлы, форматирование и механические snapshot-обновления не считаются как основной объём, но должны быть отдельно перечислены.
-
-Если по контексту видно, что задача не укладывается в `short`:
-- не составляй и не сохраняй `short`-план;
-- коротко объясни, почему `short` не подходит;
-- напиши примерную оценку: сколько фаз и какой крупный объём нужен;
-- задай блокирующий вопрос: продолжать в `normal` или сузить задачу до `short`;
-- жди ответа пользователя.
-
-## Интерактивные вопросы
-
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
 - Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
+- Codex interactive: если доступен `request_user_input`, используй его; иначе задай один короткий вопрос в чат с вариантами 1–3 и остановись до ответа.
+- Codex exec / non-interactive: не читай stdin; если без ответа нельзя безопасно продолжать, заверши со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты.
+- Не запускай команды, которые ждут интерактивного ввода.
+
+## Обязательные правила
+
+1. Никаких правок кода, миграций, конфигов и зависимостей. Запись только в `docs/plans/`.
+2. `docs/rules.md` и `docs/arch.md` — обязательная рамка планирования, а не справочный контекст. Прочитай их, выдели применимые правила и архитектурные ограничения, передай их в Plan Mode как обязательные требования.
+3. Если запрос, research, черновик Plan Mode или шаг плана конфликтует с `docs/rules.md` или `docs/arch.md`, не финализируй план. Спроси: адаптировать подход под правила/архитектуру, изменить правила/архитектуру отдельной задачей или прервать планирование.
+4. Не переформулируй запрос пользователя перед Plan Mode: передавай оригинал, ответы на вопросы и найденную рамку.
+5. План сохраняется до мета-ревью, иначе ревьюерам нечего читать.
+6. Финальный план должен быть простым, исполнимым и без альтернатив вида «выбрать», «решить», «можно так или так», «предпочтительно».
+7. Если нужны пакеты, библиотеки, CLI, сервисы или другое ПО, а версия не указана в контексте или lock/config-файлах, найди последнюю стабильную версию через context7 или web search по официальным источникам. Не пиши `latest` без конкретной версии и источника.
+8. Если `plan_size: short` не укладывается в ограничения, не сохраняй short-план: объясни причину, оцени нужный объём и спроси, продолжать в `normal` или сузить задачу.
 
 ## Этапы
 
-### 1. Подтянуть контекст
-Разбери текст текущего сообщения рядом с вызовом скилла и сохрани его как исходный запрос для Plan Mode.
-
-Определи `plan_size`:
-- если пользователь указал `short` в текущем сообщении — `short`;
-- если пользователь указал `normal`, `обычный план` или `не short` в текущем сообщении — `normal`;
-- иначе возьми `defaults.plan_size` из `docs/settings.yaml`;
-- если значение равно `ask_each_time` — задай `AskUserQuestion` с двумя вариантами: `normal`, `short`;
-- если значение отсутствует или неизвестно — `normal`.
-
-Определи `decision_mode`:
-- если пользователь явно указал `autonomous`, `recommend_and_ask`, `ask_each_time`, «сам выбирай», «рекомендуй и спрашивай» или «спрашивай всё» в текущем сообщении — используй это;
-- иначе возьми `defaults.decision_mode` из `docs/settings.yaml`;
-- если значение отсутствует или неизвестно — `recommend_and_ask`.
-
-Прочитай `docs/rules.md`, `docs/arch.md` (если есть) и строго следуй им при планировании. Выдели применимые правила и архитектурные ограничения: команды проверки, требования к тестам, границы модулей, зависимости, API, миграции, безопасность, документацию и локальные запреты. Передай эту рамку в Plan Mode как обязательные требования, а не как справочный контекст.
-
-Если задача, research или очевидный подход конфликтует с `docs/rules.md` или `docs/arch.md`, остановись до Plan Mode и задай `AskUserQuestion`: изменить подход под правила/архитектуру, изменить сами правила/архитектуру отдельной задачей или прервать планирование.
-
-Research подтягивай так:
-- если в сообщении указан путь к `docs/researches/...` или другой research-файл — прочитай его без вопроса;
-- если в сообщении есть описание задачи без research-файла — используй описание как контекст и не спрашивай research автоматически;
-- если пользователь явно просит использовать research, но файл не указал — через `AskUserQuestion` выбери из последних файлов `docs/researches/` + опция «нет»;
-- если `docs/researches/` отсутствует или пуста, а research явно нужен — сообщи об этом и продолжай без research, если задачи достаточно; если без research нельзя безопасно планировать, задай один блокирующий вопрос;
-- если текста задачи нет совсем — спроси через `AskUserQuestion`, что нужно планировать.
-
-Если из задачи следует установка пакетов или ПО:
-- проверь, указана ли версия в сообщении пользователя, правилах, архитектуре, research или существующих lock/config-файлах;
-- если версия не указана, используй `context7`, если он доступен, или веб-поиск по официальным источникам, чтобы найти последнюю стабильную версию;
-- сохрани название, выбранную версию и источник — это пойдёт в Plan Mode и финальный план;
-- если источники противоречат друг другу или последняя версия нестабильна/preview, задай блокирующий вопрос.
-
-До Plan Mode закрой существенные решения:
-- выпиши существенные развилки, которые следуют из задачи и контекста;
-- если research содержит подтверждённый ответ пользователя по развилке — используй его и запиши как подтверждённое решение;
-- если задача меняет БД или API/внешний контракт, проверь, подтверждены ли конкретные схемы таблиц или API-контракты пользователем в текущем сообщении, правилах, архитектуре или research с подтверждённым ответом пользователя;
-- если конкретные схемы БД или API-контракты не подтверждены явно, до Plan Mode задай блокирующий вопрос и получи подтверждение пользователя; не проектируй таблицы и маршруты молча внутри Plan Mode;
-- если `decision_mode: autonomous` и выбор можно обосновать кодом, правилами, архитектурой, источниками и рисками — выбери сам и запиши почему;
-- если `decision_mode: recommend_and_ask` — задай `AskUserQuestion`: 2–3 варианта, первым рекомендованный, короткая причина рекомендации, вариант «свой вариант», фраза «Я продолжу только после ответа.»;
-- если `decision_mode: ask_each_time` — задай `AskUserQuestion` по каждой значимой развилке, даже при сильной рекомендации;
-- если выбор зависит только от пользователя — задай `AskUserQuestion` в любом режиме.
-
-Не запускай Plan Mode, пока в `recommend_and_ask` или `ask_each_time` есть неподтверждённое существенное решение. Например, если нужен пакет для базы данных, сначала сравни 2–3 варианта и получи подтверждение выбора БД/пакета.
-
-Если `plan_size: short`, до Plan Mode оцени задачу по найденному контексту:
-- можно ли уложиться в 1–2 фазы;
-- ожидается ли не больше 5–10 затронутых файлов или есть понятное объяснение для большего числа маленьких однотипных правок;
-- ожидается ли не больше 400 строк осмысленного diff;
-- можно ли будет отревьюить изменения за один проход.
-
-Если ответ «нет» хотя бы по одному пункту, остановись по правилам раздела `Размер плана`.
-
-### 2. Зафиксировать стратегии тестов и логирования
-Это обязательный ранний шаг. Выполни его до содержательных уточнений и до Plan Mode.
-
-Определи `test_strategy`:
-- если пользователь явно указал стратегию тестов в текущем сообщении — используй её;
-- иначе возьми `defaults.test_strategy` из `docs/settings.yaml`;
-- если значение равно `ask_each_time`, отсутствует или неизвестно — задай `AskUserQuestion` с тремя вариантами: `after_each_phase`, `tdd_each_phase`, `end_of_plan`.
-
-Определи `logging_strategy`:
-- если пользователь явно указал стратегию логирования в текущем сообщении — используй её;
-- иначе возьми `defaults.logging_strategy` из `docs/settings.yaml`;
-- если значение равно `ask_each_time`, отсутствует или неизвестно — задай `AskUserQuestion` с двумя вариантами: `debug_precise`, `standard`.
-
-Сохрани итоговые значения как обязательные входные данные Plan Mode.
-
-Как отражать `test_strategy` в плане:
-- `after_each_phase` — в каждой фазе есть шаги написания/обновления тестов после реализации и проверка запуском этих тестов;
-- `tdd_each_phase` — каждая фаза начинается с тестов, затем идут изменения кода, затем запуск тестов;
-- `end_of_plan` — в фазах реализации не планируй написание тестов, кроме технически неизбежных; добавь отдельную финальную фазу написания и запуска тестов по всем ключевым сценариям.
-
-Как отражать `logging_strategy` в плане:
-- `debug_precise` — запланируй дебаг-логи на каждом важном шаге целевого алгоритма, с идентификаторами операций и без секретов/персональных данных;
-- `standard` — запланируй только необходимые `info`, `warning`, `error` для эксплуатации, ошибок и важных переходов состояния, без лишнего debug-шума.
-
-### 3. Уточнить, если есть неясность
-Не переформулируй запрос. Если есть конкретная неясность, без которой планировать нельзя — задай 1–4 точечных вопроса через `AskUserQuestion`. Не задавай «на всякий случай». Пары «вопрос → ответ» сохрани — они идут в Plan Mode.
-
-### 4. Спланировать через Plan Mode
-Войди в Plan Mode хост-агента (`EnterPlanMode` в Claude Code, встроенный план-режим в Codex). На вход:
+### 1. Собрать контекст
+
+- Разбери текущий вход и настройки.
+- Прочитай `docs/rules.md`, `docs/arch.md`, если они есть; выпиши применимые команды проверки, требования к тестам, границы модулей, зависимости, API, миграции, безопасность, документацию и локальные запреты.
+- Research подтягивай без вопроса, если путь указан; если в сообщении есть описание задачи без research-файла — используй описание как контекст и не спрашивай research автоматически. Если пользователь явно просит research, но файл не указал, предложи последние файлы из `docs/researches/` и вариант «нет».
+- Проверь версии нужных пакетов/ПО, если они не зафиксированы в запросе, правилах, архитектуре, research или lock/config-файлах.
+- Закрой существенные решения по `decision_mode`.
+- Для `short` оцени число фаз, файлов, строк diff и ревьюируемость за один проход.
+
+### 2. Запустить Plan Mode
+
+Передай в Plan Mode:
+
 1. Дословный запрос пользователя.
-2. Зафиксированный `plan_size`.
-3. Зафиксированный `decision_mode` и все подтверждённые пользователем существенные решения.
-4. Зафиксированные `test_strategy` и `logging_strategy`.
-5. Найденные версии пакетов/ПО и источники, если задача требует установки.
-6. Пары «вопрос → ответ» из этапа 3 и подтверждения существенных решений из research.
-7. Ссылки на `docs/rules.md`, `docs/arch.md`, исследование (без пересказа — Plan Mode прочитает сам) и явное требование строго следовать правилам и архитектуре.
-8. Выписку применимых правил и архитектурных ограничений из `docs/rules.md` и `docs/arch.md` как обязательную рамку планирования.
-9. Инструкция: «если запрос, research, решение или шаг плана противоречит `docs/rules.md` или `docs/arch.md`, не финализируй план; остановись и спроси пользователя».
-10. Инструкция: «все вопросы пользователю — только по разделу "Интерактивные вопросы", никаких догадок и продолжения без ответа».
-11. Инструкция: «финальный план должен быть нормализован в обязательную структуру из этапа 5 и не должен смешивать исследование с планом исполнения».
-12. Инструкция: «зафиксированные стратегии тестов и логирования должны быть применены в плане, а не просто записаны в YAML».
-13. Инструкция: «если `plan_size: short`, соблюдай ограничения короткого плана из раздела "Размер плана"».
-14. Инструкция: «не добавляй неподтверждённые существенные решения в финальный план; если они возникли внутри Plan Mode, остановись и спроси пользователя».
-
-Не выходи, пока пользователь не подтвердил план.
-
-### 5. Сохранить файл
-Перед сохранением нормализуй подтверждённый черновик Plan Mode в обязательную структуру. Смысл решений не меняй без вопроса пользователю, но форму, порядок и ясность правь обязательно.
-
-Финальный план должен быть пригоден для `eda-execute` без дополнительного исследования. Структура файла `docs/plans/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
+2. `plan_size`, `decision_mode`, `test_strategy`, `logging_strategy`.
+3. Все подтверждённые существенные решения и пары «вопрос → ответ».
+4. Найденные версии пакетов/ПО и источники.
+5. Пути к `docs/rules.md`, `docs/arch.md`, research и выписку применимых правил.
+6. Требование: план строго следует `docs/rules.md` и `docs/arch.md`; при конфликте остановиться и спросить пользователя.
+7. Требование: финальный план нормализуется в структуру ниже, не смешивает исследование с исполнением и не добавляет неподтверждённые существенные решения.
+
+Не выходи из Plan Mode, пока пользователь не подтвердил план.
+
+### 3. Нормализовать и сохранить
+
+Сохрани подтверждённый план в `docs/plans/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Смысл решений не меняй без вопроса, но форму, порядок и ясность правь обязательно.
 
 ```markdown
 ---
@@ -280,175 +117,120 @@ sources:
 Факты из кода, правил, архитектуры и исследований. Здесь можно объяснять причины, но не хранить исполнимые шаги.
 
 ## Принятые решения
-Список зафиксированных архитектурных и продуктовых решений. Без вариантов «или». Для существенных решений укажи источник подтверждения: ответ пользователя, research с ответом пользователя или `decision_mode: autonomous` с причиной.
-
-Если `plan_size: short`, добавь решение про ожидаемый объём: сколько фаз, сколько примерно файлов и строк осмысленного diff.
+Выбранные архитектурные и продуктовые решения без вариантов. Для существенных решений укажи источник подтверждения: ответ пользователя, research с ответом пользователя или `decision_mode: autonomous` с причиной. Для `short` укажи ожидаемый объём.
 
 ## Целевой алгоритм
-Пошаговое описание целевого поведения системы от входного события до финального состояния. Это обзор всей картины, не список файлов.
+Сквозное поведение системы от входного события до финального состояния.
 
 ## Контракты реализации
 
 ### Данные и БД
-Если БД не меняется: `Не затрагивается`.
-
-Если меняется, явно укажи таблицы, поля, типы, обязательность, default, связи, индексы, уникальные ограничения, миграции и совместимость со старыми данными. Backfill и rollback укажи, если они нужны.
+Если БД не меняется: `Не затрагивается`. Если меняется, укажи таблицы, поля, типы, обязательность, default, связи, индексы, unique, миграции, совместимость со старыми данными, backfill и rollback при необходимости.
 
 ### API и внешние контракты
-Если API и внешние контракты не меняются: `Не затрагивается`.
-
-Если меняются, явно укажи метод и путь, auth/permissions, request/query/body, response, ошибки и статус-коды. Webhooks, events, queues и внешние сервисы укажи, если они есть.
+Если API и внешние контракты не меняются: `Не затрагивается`. Если меняются, укажи метод и путь, auth/permissions, request/query/body, response, ошибки/status codes, webhooks/events/queues/внешние сервисы при наличии.
 
 ## Фазы выполнения
 
 ### 1. <Название фазы>
-Цель: зачем нужна эта фаза.
+Цель: <зачем нужна фаза>.
 
 Что сделать:
-- ...
+- <конкретные шаги>
 
-Результат: какое состояние системы должно получиться.
+Результат: <готовое состояние>.
 
 Сценарии тестирования:
-- сценарии, которые нужно покрыть в этой фазе.
+- <сценарии>
 
 Проверка:
-- тест, команда или критерий готовности.
+- <команда или критерий>
 
 ## Тесты
-Стратегия: <когда и как писать тесты согласно test_strategy>.
+Стратегия: <как применён test_strategy>.
 
 ## Логирование
-Стратегия: <уровень подробности согласно logging_strategy>.
+Стратегия: <как применён logging_strategy>.
 
 ## Документация и эксплуатация
 Что обновить в env/docs/runbook и что важно для релиза.
 ```
 
 Правила структуры:
-- В `Контекст` попадают исследовательские наблюдения и ограничения.
-- В `Принятые решения` попадают только выбранные решения, без альтернатив.
-- Риски не выносятся в отдельный обязательный раздел. Закрытые риски из research, контекста и мета-ревью должны быть встроены туда, где они исполняются: в `Принятые решения`, фазы, сценарии тестирования, проверки, логирование или эксплуатационные шаги.
-- Существенные решения в `Принятых решениях` имеют источник подтверждения или явное обоснование автономного выбора.
-- В `Целевой алгоритм` попадает сквозная картина процесса.
-- В `Контракты реализации` попадают схемы данных, БД, API и внешние контракты. Если область не затрагивается, напиши `Не затрагивается`.
-- Если план меняет БД, `Данные и БД` обязаны явно описывать таблицы, поля, типы, обязательность/default, связи, индексы/unique, миграции и совместимость со старыми данными.
-- Если план меняет API или внешний контракт, `API и внешние контракты` обязаны явно описывать method/path, auth/permissions, request/query/body, response, ошибки/status codes и внешние каналы при наличии.
-- В `Фазы выполнения` попадают только исполнимые шаги.
-- Каждая фаза обязана иметь `Цель`, `Что сделать`, `Результат`, `Сценарии тестирования`, `Проверка`.
-- В фазах нельзя ограничиваться общими формулировками вроде «обновить UI», «добавить сервис», «реализовать логику». Если фаза затрагивает UI, опиши пользовательский сценарий, состояния успеха/ошибки и видимый результат. Если фаза затрагивает внутреннюю логику, опиши ответственность изменяемых частей, поток данных, новые состояния/ошибки и существующие места, которые нужно адаптировать.
+
+- Риски не выносятся в отдельный обязательный раздел; закрытые риски встраиваются в решения, фазы, сценарии тестирования, проверки, логирование или эксплуатацию.
 - Отдельный раздел порядка выполнения не нужен: линейный порядок задаётся номерами фаз и шагами внутри фаз.
-- `test_strategy` обязан менять структуру фаз: TDD — тесты в начале фаз, after_each_phase — тесты после каждой фазы, end_of_plan — отдельная финальная фаза тестов.
-- `logging_strategy` обязан быть отражён в целевом алгоритме, фазах и отдельном разделе `Логирование`.
-- Для `plan_size: short` фаз должно быть не больше 2, а ожидаемый объём должен быть явно указан в `Принятых решениях`.
-- Если план включает установку пакетов или ПО, версии должны быть конкретными и подкреплёнными источником, если они не были заданы контекстом.
-- Если нужен раздел `Открытые вопросы`, план остаётся `draft`; после сохранения остановись и не запускай мета-ревью до ответа пользователя.
-
-Перед сохранением проверь quality gate:
-- есть `Целевой алгоритм`;
-- есть `Контракты реализации` с подразделами `Данные и БД` и `API и внешние контракты`;
+- В `Контракты реализации` попадают схемы данных, БД, API и внешние контракты; если область не затрагивается, напиши `Не затрагивается`.
+- В фазах нельзя ограничиваться общими формулировками вроде «обновить UI», «добавить сервис», «реализовать логику». Для UI опиши пользовательский сценарий, состояния успеха/ошибки и видимый результат; для внутренней логики — ответственность частей, поток данных, состояния и ошибки.
+- Если нужен раздел `Открытые вопросы`, оставь `status: draft`, сохрани файл и не запускай мета-ревью до ответа пользователя.
+
+Quality gate перед сохранением и после мета-ревью:
+
+- есть `Целевой алгоритм` и `Контракты реализации` с подразделами `Данные и БД`, `API и внешние контракты`;
 - план строго следует `docs/rules.md` и `docs/arch.md`;
-- применимые правила и архитектурные ограничения учтены в решениях, фазах, тестах и проверках;
-- нет шагов, зависимостей, API, миграций, границ модулей или команд, которые противоречат `docs/rules.md` или `docs/arch.md`;
-- если найден конфликт с правилами или архитектурой, план не финализирован до ответа пользователя;
-- если задача затрагивает БД, схема данных не пропущена и не заменена общими словами;
-- если задача затрагивает API или внешний контракт, маршруты/контракты не пропущены и не заменены общими словами;
-- фазы идут в реалистичном порядке реализации;
-- у каждой фазы есть цель, результат, сценарии тестирования и проверка;
-- UI и внутренняя логика в фазах описаны через конкретное поведение, поток данных, состояния и ошибки, если задача их затрагивает;
-- нет неразрешённых формулировок «выбрать», «решить», «можно так или так», «предпочтительно», «при необходимости»;
-- текст написан простым языком: без лишнего жаргона, непояснённых сокращений и тяжёлых терминов;
-- мета-уровень не смешан с шагами исполнения;
-- стратегия тестов зафиксирована в разделе `Тесты` и последовательно применена в фазах, сценариях тестирования и проверках;
-- стратегия логирования зафиксирована и последовательно применена в алгоритме, фазах и разделе `Логирование`;
-- тесты связаны с ключевыми сценариями и закрытыми рисками из research/контекста, если такие риски есть;
-- если `plan_size: short`, фаз не больше 2, ожидаемый объём укладывается в ориентиры short или исключение явно объяснено;
-- все пакеты/ПО, которые нужно установить, имеют конкретные версии или явное объяснение, почему версия берётся из существующего lock/config-файла;
-- нет неподтверждённых существенных решений при `decision_mode: recommend_and_ask` или `decision_mode: ask_each_time`;
+- нет конфликтов с правилами, архитектурой, границами модулей, API, миграциями, зависимостями и командами проверки;
+- БД/API изменения описаны конкретно, а не общими словами;
+- каждая фаза имеет цель, шаги, результат, сценарии тестирования и проверку;
+- `test_strategy` и `logging_strategy` применены в фазах и отдельных разделах;
+- для `short` не больше 2 фаз и явно указан ожидаемый объём;
+- пакеты/ПО имеют конкретные версии или ссылку на существующий lock/config;
+- нет неподтверждённых существенных решений и неразрешённых альтернатив;
 - план можно передать в `eda-execute` без нового исследования.
 
-Сохрани файл и покажи путь.
+### 4. Мета-ревью тремя субагентами/моделями
 
-### 6. Мета-ревью плана тремя субагентами/моделями (параллельно)
-Запусти **в одном сообщении и одним batch** трёх агентов на трёх разных моделях — слабая, средняя, мощная. В интерактивном Codex это означает субагентов, а не отдельные процессы `codex exec`. Не запускай сначала одного-двух, не жди их ответы и не запускай третьего позже: все три проверки должны стартовать до чтения любого результата.
+Запусти три проверки параллельно, в одном batch, до чтения любого результата. Главный планировщик сам решает, что применять; предложения не вставляются механически.
 
-| Среда | Слабая (быстрая) | Средняя (код) | Мощная (флагман) |
+| Среда | Быстрая | Кодовая | Флагман |
 |---|---|---|---|
-| Claude Code (`Agent` tool) | `model: "haiku"` | `model: "sonnet"` | `model: "opus"` |
+| Claude Code (`Agent` tool) | `haiku` | `sonnet` | `opus` |
 | Codex interactive (`spawn_agent`) | `gpt-5.4-mini` | `gpt-5.3-codex` | `gpt-5.5` |
-| Codex exec / non-interactive fallback (`codex exec --model …`) | `gpt-5.4-mini` | `gpt-5.3-codex` | `gpt-5.5` |
-
-В Claude Code запускай три параллельных `Agent` tool в одном ответе/tool-use batch с моделями из таблицы и передавай им промпты нужной глубины из таблицы ниже.
-
-В интерактивном Codex, если доступен инструмент субагентов (`spawn_agent` или аналог), запускай три параллельных субагента через него. Не используй отдельные `codex exec` для обычного мета-ревью, когда субагенты доступны.
-
-В `codex exec`, другом неинтерактивном режиме или Codex без инструмента субагентов используй fallback: три параллельных `codex exec --model <id>` одной Bash-командой с `&` и общим `wait`.
-
-Если `gpt-5.5` недоступен (ограничение account/auth) — возьми `gpt-5.4` как мощную. Если какой-либо идентификатор отсутствует у тебя — возьми ближайший аналог того же тира из доступных в твоей версии Codex.
+| Codex exec / non-interactive fallback | `gpt-5.4-mini` | `gpt-5.3-codex` | `gpt-5.5` |
 
-Каждому передай путь к файлу плана, `docs/rules.md`, `docs/arch.md` (если есть), исследование из `sources.research` (если есть). Формулируй задание как содержательную проверку с глубиной чтения, указанной для тира модели ниже.
+В интерактивном Codex, если доступен инструмент субагентов (`spawn_agent` или аналог), используй его. Не используй отдельные `codex exec` для обычного мета-ревью, когда субагенты доступны. В неинтерактивном fallback запускай три `codex exec --model <id>` параллельно одной Bash-командой с `&` и общим `wait`.
 
-Глубина проверки зависит от модели:
+Промпт всем: прочитать план, `docs/rules.md`, `docs/arch.md`, research из `sources.research` при наличии и релевантный код по глубине модели. Найти пропущенные шаги, нарушения правил/архитектуры, скрытые риски, риски для смежного кода, недостающие тесты и шаги без критериев готовности. Формат ответа: `+ N | − N | ~ N: причина`; флагману явно скажи открывать файлы модулей, API, тестов и сценариев, на которые ссылается план.
 
-| Модель | Что просить |
-|---|---|
-| Слабая | Быстро проверить план, правила, архитектуру и исследование; код смотреть только точечно, если без этого нельзя оценить риск. |
-| Средняя | Проверить план по исследованию и прочитать релевантные файлы/контракты, которые прямо следуют из плана; найти пропущенные шаги, зависимости и тесты. |
-| Мощная | Провести глубокую проверку: прочитать план, правила, архитектуру, исследование и релевантный код настолько глубоко, чтобы подтвердить реализуемость шагов, совместимость со смежным кодом, нужные тесты и отсутствие скрытых архитектурных рисков. |
-
-Базовый формат ответа для всех: `+ N | − N | ~ N: причина`, без воды. Для мощной модели добавь явную инструкцию: «Если план ссылается на модуль, API, тесты или сценарий, открой соответствующие файлы и проверь фактическую структуру проекта.»
-
-Когда все три ответили — прочитай ответы, **сам реши**, что применять (не вставляй чужие пункты механически). Принятые замечания сначала интегрируй в основные разделы плана: решения, алгоритм, фазы, тесты, логирование, документацию и эксплуатацию. Не оставляй важные требования только в changelog.
-
-После интеграции снова прогони quality gate из этапа 5. Затем допиши в конец короткий раздел:
+После ответов интегрируй принятые замечания в основные разделы плана, снова прогони quality gate и добавь:
 
 ```markdown
 ## Изменения после мета-ревью
 
 ### После моделей
-- **+ Добавлено:** 3–7 главных принятых изменений.
-- **~ Изменено:** 1–5 существенных уточнений структуры или решений.
-- **− Убрано:** если что-то удалено.
-- **Отклонено:** если отклонялись существенные предложения, коротко почему.
+- **+ Добавлено:** <3–7 главных изменений>
+- **~ Изменено:** <1–5 уточнений>
+- **− Убрано:** <если удалено>
+- **Отклонено:** <существенные отклонённые предложения и причина>
 ```
 
-В YAML-шапке: `status: draft` → `meta-reviewed`, в `meta_reviewers` — имена/идентификаторы моделей.
+В YAML поменяй `status: draft` на `meta-reviewed`, в `meta_reviewers` запиши модели.
 
-### 7. Кросс-CLI — только в `strict`
-Обычный режим — пропусти этапы 7–8, иди на финал.
+### 5. Strict: кросс-CLI и допил
 
-В `strict`: отдай файл соседнему агенту через `Bash`. Если ты в Claude Code — запускай Codex CLI:
+Обычный режим пропускает этот этап. В `strict` отдай файл соседнему CLI:
 
 ```bash
 codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, связанное исследование из sources.research при наличии. Затем глубоко проверь план по релевантному коду: открой файлы, модули, API и тесты, которые следуют из плана, и оцени фактическую реализуемость. Критическое ревью на русском: пропущенные шаги, неучтённые зависимости, нарушения правил и архитектуры, скрытые риски, риски для смежного кода, недостающие тесты, шаги без критериев готовности. Список '- [тип] описание — что предлагаешь'." > "${PLAN_FILE%.md}_review.md"
 ```
 
-Если ты в Codex — запускай Claude CLI с теми же требованиями глубины:
+Если ты в Codex — запускай `claude -p` с тем же заданием. Если соседней CLI нет, спроси, продолжать без ревью или прервать.
 
-```bash
-claude -p "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, связанное исследование из sources.research при наличии. Затем глубоко проверь план по релевантному коду: открой файлы, модули, API и тесты, которые следуют из плана, и оцени фактическую реализуемость. Критическое ревью на русском: пропущенные шаги, неучтённые зависимости, нарушения правил и архитектуры, скрытые риски, риски для смежного кода, недостающие тесты, шаги без критериев готовности. Список '- [тип] описание — что предлагаешь'." > "${PLAN_FILE%.md}_review.md"
-```
-
-Соседней CLI нет — `AskUserQuestion`: продолжать без ревью или прервать.
+Бесспорные замечания внеси в план, спорные вынеси через `AskUserQuestion`, отклонённые зафиксируй с причиной в `## Реакция на ревью`. Поменяй `status: meta-reviewed` на `reviewed`, покажи дифф.
 
-### 8. Допилить по ревью — только в `strict`
-Бесспорные замечания → правишь сразу. Спорные → `AskUserQuestion`. Отклонённые → оставляешь, причина в журнал. В конец файла добавь раздел `## Реакция на ревью` (Принято / Отклонено / Спорное). Поменяй `status: meta-reviewed` → `reviewed`. Покажи дифф.
+### 6. Финал
 
-### 9. Финал
-Короткое сообщение: режим, путь к плану, путь к ревью (если был `strict`), 3–5 главных шагов простыми словами, что предлагаешь дальше (но не делай — это `eda-execute`).
+Коротко сообщи режим, путь к плану, путь к review-файлу в `strict`, 3–5 главных шагов простыми словами и что дальше делает `eda-execute`.
 
 ## Чего НЕ делать
-- Править код, запускать миграции.
+
+- Править код, миграции, конфиги или зависимости.
 - Считать `docs/rules.md` и `docs/arch.md` просто контекстом для ознакомления.
-- Исполнять или сохранять план, который противоречит правилам или архитектуре проекта.
+- Сохранять план, который противоречит правилам или архитектуре проекта.
 - Обходить правило или архитектурное ограничение без явного решения пользователя.
-- Задавать вопросы без блокировки и продолжать работу до ответа.
+- Задавать вопросы без блокировки и продолжать до ответа.
 - Переформулировать запрос пользователя своими словами перед Plan Mode.
-- Пропускать сохранение файла плана.
-- Сохранять сырой текст Plan Mode без нормализации в обязательный формат.
-- Оставлять финальный план в виде исследования, списка наблюдений или журнала мета-ревью.
-- Смешивать альтернативы с принятыми решениями: если выбор нужен — спроси пользователя до финализации.
-- Пропускать мета-ревью тремя моделями — это часть обычного режима, не под флагом.
-- Запускать мета-ревьюеров частями: сначала 1–2 агента, потом третьего. Все три стартуют сразу.
-- Вставлять предложения мета-ревьюеров механически — каждое решение принимаешь ты.
-- Пропускать кросс-CLI молча в `strict` (если CLI нет — спроси).
+- Сохранять сырой текст Plan Mode без нормализации.
+- Оставлять финальный план исследованием, списком наблюдений или журналом мета-ревью.
+- Смешивать альтернативы с принятыми решениями.
+- Пропускать мета-ревью тремя моделями или запускать ревьюеров частями.
+- Пропускать кросс-CLI молча в `strict`: если CLI нет, спроси.