@gian-tiaga/eda 0.3.4 → 0.4.0

package/skills/eda-execute.md

@@ -1,6 +1,6 @@
 ---
 name: eda-execute
-description: 'Исполняет план из docs/plans/ по пути или описанию рядом с вызовом. Перед правками читает `docs/rules.md` и `docs/arch.md` и строго следует им, правит код, пишет тесты к изменениям внутри каждого шага, в конце прогоняет полный сьют тестов и линтеры. Прогресс — чекбоксы в файле плана + журнал в `docs/executions/`; в конец плана дописывается ссылка на журнал. Не коммитит (это `eda-commit`), не делает ревью (это `eda-review`). Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
+description: 'Исполняет план из docs/plans/ по пути или описанию рядом с вызовом. Перед правками читает `docs/rules.md` и `docs/arch.md` и строго следует им, правит код, в конце прогоняет полный сьют тестов и линтеры. Прогресс — чекбоксы в файле плана + журнал в `docs/executions/`; в конец плана дописывается ссылка на журнал. Не коммитит (это `eda-commit`), не делает ревью (это `eda-review`). Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
 ---
 
 # Скил: Исполнитель (eda-execute)
@@ -20,10 +20,9 @@ description: 'Исполняет план из docs/plans/ по пути или
 3. **Не переформулируй план.** Шаг непонятен — спроси, не «доразрабатывай» молча.
 4. **Не коммитить, не пушить, не делать ревью.** Это другие скилы.
 5. **Идти целиком**, не делать паузы «для подтверждения». Останавливайся только если: тест упал, шаг противоречив, есть риск потерять данные, рискованная операция вне плана.
-6. **Тесты — внутри шага.** Меняешь поведение → пишешь тесты к этому изменению в том же шаге, точечно прогоняешь только их. Полный сьют и линтеры — один раз в конце (этап 7), не на каждом шаге.
-7. **Проверки нельзя подавлять.** Не отключай линтеры, тесты, typecheck, static analysis и другие проверки; не добавляй игноры, исключения из проверок, ослабление правил или изменение команд так, чтобы проверка перестала запускаться. Пиши и правь код так, чтобы проверки проходили по сути.
-8. **Простой язык** в сообщениях пользователю и вопросах. Термины — только если без них нельзя, и сразу с пояснением.
-9. **Таблицы для структурируемых данных** в журнале. Диаграммы — только если действительно есть что показать.
+6. **Проверки нельзя подавлять.** Не отключай линтеры, тесты, typecheck, static analysis и другие проверки; не добавляй игноры, исключения из проверок, ослабление правил или изменение команд так, чтобы проверка перестала запускаться. Пиши и правь код так, чтобы проверки проходили по сути.
+7. **Простой язык** в сообщениях пользователю и вопросах. Термины — только если без них нельзя, и сразу с пояснением.
+8. **Таблицы для структурируемых данных** в журнале. Диаграммы — только если действительно есть что показать.
 
 ## Интерактивные вопросы
 
@@ -74,7 +73,7 @@ cd ../<repo-name>-<slug>
 И **выйди из скила** — текущая сессия в эту папку не переедет, поэтому продолжать здесь нельзя. Сообщи пользователю, что ждёшь его в новой сессии.
 
 ### 3. Прочитать контекст
-План + `docs/rules.md` и `docs/arch.md` (если есть). Правилам и архитектуре строго следуй при каждой правке. Тест-фреймворк проекта определи сам по конфигам/существующим тестам — этого хватит, чтобы писать тесты в нужном стиле.
+План + `docs/rules.md` и `docs/arch.md` (если есть). Правилам и архитектуре строго следуй при каждой правке. Тест-фреймворк проекта определи сам по конфигам/существующим тестам.
 
 ### 4. Инициализировать прогресс
 - Создай журнал `docs/executions/{YYYY-MM-DD}_{HH-MM}_{slug}.md` (slug — тот же, что у плана, или близкий).
@@ -108,7 +107,7 @@ cd ../<repo-name>-<slug>
 ### 5. Выполнить план
 Идёшь по шагам. На каждом:
 1. Сделай правки.
-2. Если шаг меняет поведение — добавь тесты в этом же шаге, точечно прогони.
+2. Выполни проверки, если они прямо указаны в шаге.
 3. Поставь `[x]` в файле плана и допиши строку в таблицу журнала.
 
 Останавливайся и спрашивай через `AskUserQuestion`, если: тесты к шагу упали и не правятся быстро / шаг противоречит коду / задевает рискованное вне плана. Архитектурное решение по ходу — записывай в «Изменения в docs», не блокируй.

package/skills/eda-explore.md

@@ -0,0 +1,181 @@
+---
+name: eda-explore
+description: 'Исследует тему или задачу до конкретного результата: проясняет проблему, архитектуру, развилки, риски и короткий выбранный вариант решения без плана реализации. Работает read-only, задаёт блокирующие вопросы, когда без ответа нельзя выбрать решение, и не оставляет неразрешённых альтернатив. Если исследование касается пакетов, библиотек, CLI, сервисов или другого ПО, проверяет актуальные стабильные версии через context7, если он доступен, или через web search по официальным источникам. Итог сохраняет в docs/researches/. Кросс-ревью соседним агентом (Claude ↔ Codex) включается флагом `strict` или настройкой `defaults.strict: true` в `docs/settings.yaml`.'
+---
+
+# Скил: Исследователь решений (eda-explore)
+
+Проводишь исследование так, чтобы на выходе была не подборка рассуждений, а конкретная рамка для следующего шага: что за проблема, как устроена релевантная архитектура, какие решения приняты, какие риски закрыты и какой вариант решения выбран.
+
+## Режимы вызова
+
+| Режим | Запуск | Что делает |
+|---|---|---|
+| Обычный | `eda-explore <тема>` | Исследование + вопросы + конкретный итоговый отчёт. |
+| Строгий | `eda-explore strict <тема>` | Обычный режим + кросс-ревью соседним агентом + допил отчёта. |
+
+Если в `docs/settings.yaml` указано `defaults.strict: true`, строгий режим включён по умолчанию. Явное указание пользователя в текущем сообщении важнее настройки: `strict` включает строгий режим, `normal` / `без strict` / `без строгого режима` выключает его для текущего запуска.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+
+Если входа достаточно, продолжай без подтверждения. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск исследовать не то. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Настройки проекта
+
+Перед выбором режима прочитай `docs/settings.yaml`, если файл есть.
+
+Если файла нет — используй значение по умолчанию:
+- `defaults.strict: false`
+
+Прямое указание пользователя в текущем сообщении важнее `docs/settings.yaml`.
+
+## Главные правила
+
+1. **Никаких правок кода.** Запись только в `docs/researches/`.
+2. **Итог — конкретика.** Нельзя заканчивать абстрактными описаниями, списком возможностей или «можно выбрать один из вариантов».
+3. **Развилки решай.** Если можно выбрать по коду, правилам, архитектуре, источникам и рискам — выбери сам и запиши почему. Если выбор зависит только от пользователя — задай блокирующий вопрос.
+4. **Риски закрывай.** Для каждого риска зафиксируй решение: mitigation, acceptance или out of scope. Нельзя оставлять риск просто перечисленным.
+5. **Версии проверяй.** Если речь о пакетах, библиотеках, CLI, сервисах или другом ПО, а версия не задана контекстом, проверь последнюю стабильную версию через context7, если он доступен, или через web search по официальным источникам.
+6. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и используй их как рамку.
+7. **Каждое фактическое утверждение — со ссылкой** (`file.ext:42`, URL, коммит). Без ссылки — помечай как «гипотеза» и не делай её основанием выбранного решения.
+8. **Простой язык.** Термины — только когда без них нельзя, сразу с пояснением.
+9. **Таблицы > сплошной текст** для фактов, развилок, рисков и решений.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале.
+
+## Этапы
+
+### 1. Понять тему и критерий готовности
+
+Сформулируй:
+- какую проблему исследуешь;
+- какой результат нужен пользователю;
+- какие вопросы должны быть закрыты, чтобы можно было переходить к плану или реализации.
+
+Если тема неоднозначна или критерий готовности нельзя вывести из запроса — задай `AskUserQuestion` и остановись до ответа.
+
+### 2. Собрать контекст
+
+Работай read-only: читай код, документы, конфиги, тесты, историю и внешние источники. Прочитай `docs/rules.md` и `docs/arch.md`, если они есть.
+
+Если исследование касается пакетов или ПО:
+- сначала проверь, не зафиксирована ли версия в запросе, lock-файле, package/config-файле, `docs/rules.md`, `docs/arch.md` или связанном документе;
+- если версия не зафиксирована, используй context7, если он доступен;
+- если context7 недоступен или не даёт ответа, используй web search по официальной документации, registry, release notes или репозиторию проекта;
+- выбирай последнюю стабильную версию, не preview/beta/rc, если пользователь явно не попросил иначе;
+- запиши источник, дату проверки и причину выбора.
+
+### 3. Закрыть развилки
+
+Собери все существенные развилки: архитектурные, продуктовые, технические, миграционные, по зависимостям и совместимости.
+
+Для каждой развилки:
+- перечисли варианты;
+- выбери один вариант;
+- запиши источник и причину выбора;
+- если выбрать нельзя без пользовательского решения — задай `AskUserQuestion` и не продолжай финализацию.
+
+### 4. Закрыть риски
+
+Для каждого риска зафиксируй:
+- что может пойти не так;
+- почему это важно;
+- выбранное решение: как снимаем, принимаем или выносим за рамки;
+- что это значит для будущего плана.
+
+Высокий риск без решения — блокер. Задай вопрос или заверши со статусом `blocked`.
+
+### 5. Собрать отчёт
+
+Сохрани отчёт в `docs/researches/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
+
+Формат отчёта должен быть компактным и универсальным: три основных раздела, без обязательного раздувания под каждый тип исследования. Таблицы, ASCII-диаграммы и дополнительные подпункты добавляй внутри этих разделов только когда они действительно помогают ясности.
+
+```markdown
+---
+title: <заголовок>
+date: <YYYY-MM-DD HH:MM>
+mode: <normal | strict>
+status: <draft | reviewed | blocked>
+reviewer: <pending | none | claude | codex>
+sources:
+  rules: <путь или —>
+  arch: <путь или —>
+---
+
+# <Заголовок>
+
+## Суть
+Что исследовали и какая проблема решается.
+
+## Решение
+Описание выбранного решения. Внутри этого раздела, если нужно, добавь:
+- описание релевантной архитектуры;
+- ASCII-диаграммы;
+- таблицы фактов, развилок, рисков, версий пакетов/ПО и источников;
+- объяснение, почему выбран этот вариант, а не альтернативы.
+
+## Ответы на вопросы
+Вопросы, которые были заданы в процессе исследования, и ответы пользователя. Если вопросов не было — «Не требовались.»
+
+## Итог
+Короткая конкретика: что делать дальше на уровне подхода, без плана реализации.
+```
+
+Quality gate перед сохранением:
+- есть разделы `Суть`, `Решение`, `Ответы на вопросы`, `Итог`;
+- в `Суть` чётко описано, что исследовали и какая проблема решается;
+- в `Решение` есть выбранный вариант решения, а не набор равных альтернатив;
+- в `Решение` есть описание архитектуры или явно сказано, почему архитектурный слой не затронут;
+- в `Ответы на вопросы` записаны все вопросы, заданные пользователю в процессе исследования, и ответы на них, чтобы `eda-plan` не задавал их повторно;
+- в `Итог` есть короткая конкретика, что делать дальше на уровне подхода, без пошагового плана;
+- нет незакрытых развилок;
+- нет рисков без решения;
+- версии пакетов/ПО проверены или объяснено, почему это не требуется;
+- ключевые утверждения имеют источники.
+
+### 6. Кросс-ревью — только в `strict`
+
+Обычный режим — пропусти этапы 6–7, иди на финал. `reviewer: none`, `status: draft`.
+
+В `strict`: отдай файл соседнему агенту через `Bash` и сформулируй задание как глубокую проверку конкретности, фактов, развилок и рисков.
+
+Если ты в Claude Code — запускай Codex CLI:
+
+```bash
+codex exec "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md при наличии и все источники, на которые ссылается исследование. Проверь, что проблема описана конкретно, архитектура не выдумана, все развилки решены, риски закрыты, версии пакетов/ПО проверены по актуальным источникам, а вариант решения не является планом или абстрактным рассуждением. Критическое ревью на русском: фактические ошибки, пропущенные развилки, незакрытые риски, слабые источники, неверные версии, неконкретный итог. Формат: '- [тип] описание — что исправить'." > "${RESEARCH_FILE%.md}_review.md"
+```
+
+Если ты в Codex — запускай Claude CLI с теми же требованиями:
+
+```bash
+claude -p "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md при наличии и все источники, на которые ссылается исследование. Проверь, что проблема описана конкретно, архитектура не выдумана, все развилки решены, риски закрыты, версии пакетов/ПО проверены по актуальным источникам, а вариант решения не является планом или абстрактным рассуждением. Критическое ревью на русском: фактические ошибки, пропущенные развилки, незакрытые риски, слабые источники, неверные версии, неконкретный итог. Формат: '- [тип] описание — что исправить'." > "${RESEARCH_FILE%.md}_review.md"
+```
+
+CLI нет — `AskUserQuestion`: продолжать без ревью или прервать.
+
+### 7. Допилить по ревью — только в `strict`
+
+Бесспорные замечания → правь. Спорные → `AskUserQuestion`. Отклонённые → оставь с причиной. В конец отчёта добавь раздел `## Реакция на ревью` (Принято / Отклонено / Спорное). `status: reviewed`. Покажи дифф.
+
+### 8. Финал
+
+Короткое сообщение: режим, путь к отчёту, путь к ревью (если `strict`), 3–5 конкретных выводов, выбранный вариант решения одной строкой. Не предлагай «исследовать дальше», если нет блокера.
+
+## Чего НЕ делать
+
+- Править код, миграции, конфиги или зависимости.
+- Оставлять несколько равных вариантов «на выбор» в итоговом отчёте.
+- Писать общий обзор вместо конкретного описания проблемы, архитектуры и решения.
+- Перечислять риски без выбранного закрытия.
+- Планировать реализацию по шагам — это работа `eda-plan`.
+- Указывать `latest` без конкретной проверенной версии и источника.
+- Сохранять отчёт куда-либо кроме `docs/researches/`.

package/skills/eda-plan.md

@@ -1,6 +1,6 @@
 ---
 name: eda-plan
-description: 'Пишет план реализации по тексту рядом с вызовом или указанному research-файлу через стандартный Plan Mode (Claude Code / Codex). Перед планированием читает docs/rules.md, docs/arch.md и строго следует им; research подтягивает без вопроса, если он указан или явно нужен. Нормализует результат в исполнимый план с целевым алгоритмом, фазами, проверками и без неразрешённых альтернатив. Согласованный план сохраняется в docs/plans/. Всегда проверяет план тремя параллельными моделями (слабая, средняя, мощная) на реалистичность, пропущенные шаги, нарушения правил и риски. В `strict` — ещё и кросс-CLI (Claude ↔ Codex). Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
+description: 'Пишет план реализации по тексту рядом с вызовом или указанному research-файлу через стандартный Plan Mode (Claude Code / Codex). Перед планированием читает docs/rules.md, docs/arch.md и строго следует им; research подтягивает без вопроса, если он указан или явно нужен. Поддерживает параметр `short` для небольших фич: 1–2 фазы и компактный ревьюируемый объём. В самом начале фиксирует стратегию тестов и логирования из docs/settings.yaml или уточняет их у пользователя. Нормализует результат в исполнимый план с целевым алгоритмом, фазами, проверками и без неразрешённых альтернатив. Согласованный план сохраняется в docs/plans/. Всегда проверяет план тремя параллельными моделями (слабая, средняя, мощная) на реалистичность, пропущенные шаги, нарушения правил и риски. Кросс-CLI (Claude ↔ Codex) включается флагом `strict` или настройкой `defaults.strict: true` в `docs/settings.yaml`. Вопросы задаёт только когда без ответа нельзя безопасно продолжать или когда настройки требуют спрашивать каждый раз.'
 ---
 
 # Скил: Планировщик (eda-plan)
@@ -13,6 +13,12 @@ description: 'Пишет план реализации по тексту ряд
 |---|---|---|
 | Обычный | `eda-plan <тема>` | Этапы 1–6 + финал. Кросс-CLI не запускается. |
 | Строгий | `eda-plan strict <тема>` | + кросс-CLI соседним агентом + допил. |
+| Короткий | `eda-plan short <тема>` | План для небольшой фичи: 1–2 фазы и компактный ревьюируемый объём. |
+| Короткий строгий | `eda-plan strict short <тема>` | `short`-план + кросс-CLI соседним агентом + допил. |
+
+Если в `docs/settings.yaml` указано `defaults.strict: true`, строгий режим включён по умолчанию. Явное указание пользователя в текущем сообщении важнее настройки: `strict` включает строгий режим, `normal` / `без strict` / `без строгого режима` выключает его для текущего запуска.
+
+Размер плана берётся из явного указания пользователя или `defaults.plan_size` в `docs/settings.yaml`. Явное `short` включает `plan_size: short`; явное `normal` / `обычный план` включает `plan_size: normal`.
 
 ## Вход из сообщения пользователя
 
@@ -20,6 +26,58 @@ description: 'Пишет план реализации по тексту ряд
 
 Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
 
+## Настройки проекта
+
+Перед выбором режима прочитай `docs/settings.yaml`, если файл есть.
+
+Если файла нет — используй значение по умолчанию:
+- `defaults.strict: false`
+- `defaults.plan_size: normal`
+- `defaults.test_strategy: ask_each_time`
+- `defaults.logging_strategy: ask_each_time`
+
+Прямое указание пользователя в текущем сообщении важнее `docs/settings.yaml`.
+
+Поддерживаемые настройки:
+
+| Ключ | Значения | Что значит |
+|---|---|---|
+| `defaults.strict` | `true`, `false` | Включает или выключает строгий режим по умолчанию. |
+| `defaults.plan_size` | `normal`, `short`, `ask_each_time` | Размер плана по умолчанию для `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.test_strategy` или `defaults.logging_strategy` отсутствует или неизвестен, считай его `ask_each_time`.
+
+В самом начале составления плана, после чтения текущего сообщения и `docs/settings.yaml`, но до Plan Mode и до содержательного планирования, зафиксируй:
+- размер плана;
+- стратегию тестов;
+- стратегию логирования.
+
+Если в настройках стоит `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-шапке, `Принятых решениях`, `Фазах выполнения`, `Тестах` и `Логировании`.
+
 ## Главные правила
 
 1. **Никаких правок кода.** Запись только в `docs/plans/`.
@@ -32,6 +90,28 @@ description: 'Пишет план реализации по тексту ряд
 8. **Таблицы > сплошной текст** для структурируемых данных.
 9. **Финальный план — не исследование.** Исследовательские факты идут в контекст, выбранные подходы — в решения, исполнимые шаги — в фазы.
 10. **Не оставляй неоднозначности.** Если в плане остаётся «выбрать», «решить», «можно так или так», «предпочтительно» — задай вопрос до финализации или зафиксируй одно принятое решение.
+11. **Версии пакетов и ПО проверяй до планирования.** Если для задачи нужно устанавливать пакет, библиотеку, сервис, 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`;
+- жди ответа пользователя.
 
 ## Интерактивные вопросы
 
@@ -46,6 +126,13 @@ description: 'Пишет план реализации по тексту ряд
 ### 1. Подтянуть контекст
 Разбери текст текущего сообщения рядом с вызовом скилла и сохрани его как исходный запрос для Plan Mode.
 
+Определи `plan_size`:
+- если пользователь указал `short` в текущем сообщении — `short`;
+- если пользователь указал `normal`, `обычный план` или `не short` в текущем сообщении — `normal`;
+- иначе возьми `defaults.plan_size` из `docs/settings.yaml`;
+- если значение равно `ask_each_time` — задай `AskUserQuestion` с двумя вариантами: `normal`, `short`;
+- если значение отсутствует или неизвестно — `normal`.
+
 Прочитай `docs/rules.md`, `docs/arch.md` (если есть) и строго следуй им при планировании.
 
 Research подтягивай так:
@@ -55,20 +142,64 @@ Research подтягивай так:
 - если `docs/researches/` отсутствует или пуста, а research явно нужен — сообщи об этом и продолжай без research, если задачи достаточно; если без research нельзя безопасно планировать, задай один блокирующий вопрос;
 - если текста задачи нет совсем — спроси через `AskUserQuestion`, что нужно планировать.
 
-### 2. Уточнить, если есть неясность
+Если из задачи следует установка пакетов или ПО:
+- проверь, указана ли версия в сообщении пользователя, правилах, архитектуре, research или существующих lock/config-файлах;
+- если версия не указана, используй `context7`, если он доступен, или веб-поиск по официальным источникам, чтобы найти последнюю стабильную версию;
+- сохрани название, выбранную версию и источник — это пойдёт в Plan Mode и финальный план;
+- если источники противоречат друг другу или последняя версия нестабильна/preview, задай блокирующий вопрос.
+
+Если `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.
 
-### 3. Спланировать через Plan Mode
+### 4. Спланировать через Plan Mode
 Войди в Plan Mode хост-агента (`EnterPlanMode` в Claude Code, встроенный план-режим в Codex). На вход:
 1. Дословный запрос пользователя.
-2. Пары «вопрос → ответ» из этапа 2.
-3. Ссылки на `docs/rules.md`, `docs/arch.md`, исследование (без пересказа — Plan Mode прочитает сам) и явное требование строго следовать правилам и архитектуре.
-4. Инструкция: «все вопросы пользователю — только по разделу "Интерактивные вопросы", никаких догадок и продолжения без ответа».
-5. Инструкция: «финальный план должен иметь раздел "Целевой алгоритм", фазы с целью/результатом/проверкой и не должен смешивать исследование с планом исполнения».
+2. Зафиксированный `plan_size`.
+3. Зафиксированные `test_strategy` и `logging_strategy`.
+4. Найденные версии пакетов/ПО и источники, если задача требует установки.
+5. Пары «вопрос → ответ» из этапа 3.
+6. Ссылки на `docs/rules.md`, `docs/arch.md`, исследование (без пересказа — Plan Mode прочитает сам) и явное требование строго следовать правилам и архитектуре.
+7. Инструкция: «все вопросы пользователю — только по разделу "Интерактивные вопросы", никаких догадок и продолжения без ответа».
+8. Инструкция: «финальный план должен иметь раздел "Целевой алгоритм", фазы с целью/результатом/проверкой и не должен смешивать исследование с планом исполнения».
+9. Инструкция: «стратегии тестов и логирования обязательны: они должны быть отражены в решениях, фазах, проверках, разделах "Тесты" и "Логирование"».
+10. Инструкция: «если `plan_size: short`, план обязан уложиться в 1–2 фазы, компактный ревьюируемый объём и объяснение ожидаемого объёма изменений».
+11. Инструкция: «если нужны пакеты или ПО, используй только конкретные версии; если версия не задана контекстом, она должна быть проверена через context7 или поиск и указана с источником».
 
 Не выходи, пока пользователь не подтвердил план.
 
-### 4. Сохранить файл
+### 5. Сохранить файл
 Перед сохранением нормализуй подтверждённый черновик Plan Mode в обязательную структуру. Смысл решений не меняй без вопроса пользователю, но форму, порядок и ясность правь обязательно.
 
 Финальный план должен быть пригоден для `eda-execute` без дополнительного исследования. Структура файла `docs/plans/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
@@ -78,9 +209,12 @@ Research подтягивай так:
 title: <заголовок>
 date: <YYYY-MM-DD HH:MM>
 mode: <normal | strict>
+plan_size: <normal | short>
 status: <draft | meta-reviewed | reviewed>
 reviewer: <pending | none | claude | codex>
 meta_reviewers: []
+test_strategy: <after_each_phase | tdd_each_phase | end_of_plan>
+logging_strategy: <debug_precise | standard>
 sources:
   rules: <путь или —>
   arch: <путь или —>
@@ -98,6 +232,8 @@ sources:
 ## Принятые решения
 Список зафиксированных архитектурных и продуктовых решений. Без вариантов «или».
 
+Если `plan_size: short`, добавь решение про ожидаемый объём: сколько фаз, сколько примерно файлов и строк осмысленного diff.
+
 ## Целевой алгоритм
 Пошаговое описание целевого поведения системы от входного события до финального состояния. Это обзор всей картины, не список файлов.
 
@@ -111,11 +247,17 @@ sources:
 
 Результат: какое состояние системы должно получиться.
 
+Сценарии тестирования:
+- сценарии, которые нужно покрыть в этой фазе.
+
 Проверка:
 - тест, команда или критерий готовности.
 
 ## Тесты
-Сценарии, которые нужно покрыть, сгруппированные по поведению или фазам.
+Стратегия: <когда и как писать тесты согласно test_strategy>.
+
+## Логирование
+Стратегия: <уровень подробности согласно logging_strategy>.
 
 ## Документация и эксплуатация
 Что обновить в env/docs/runbook и что важно для релиза.
@@ -132,22 +274,30 @@ sources:
 - В `Принятые решения` попадают только выбранные решения, без альтернатив.
 - В `Целевой алгоритм` попадает сквозная картина процесса.
 - В `Фазы выполнения` попадают только исполнимые шаги.
-- Каждая фаза обязана иметь `Цель`, `Что сделать`, `Результат`, `Проверка`.
+- Каждая фаза обязана иметь `Цель`, `Что сделать`, `Результат`, `Сценарии тестирования`, `Проверка`.
+- `test_strategy` обязан менять структуру фаз: TDD — тесты в начале фаз, after_each_phase — тесты после каждой фазы, end_of_plan — отдельная финальная фаза тестов.
+- `logging_strategy` обязан быть отражён в целевом алгоритме, фазах и отдельном разделе `Логирование`.
+- Для `plan_size: short` фаз должно быть не больше 2, а ожидаемый объём должен быть явно указан в `Принятых решениях`.
+- Если план включает установку пакетов или ПО, версии должны быть конкретными и подкреплёнными источником, если они не были заданы контекстом.
 - Если нужен раздел `Открытые вопросы`, план остаётся `draft`; после сохранения остановись и не запускай мета-ревью до ответа пользователя.
 
 Перед сохранением проверь quality gate:
 - есть `Целевой алгоритм`;
 - фазы идут в реалистичном порядке реализации;
-- у каждой фазы есть цель, результат и проверка;
+- у каждой фазы есть цель, результат, сценарии тестирования и проверка;
 - нет неразрешённых формулировок «выбрать», «решить», «можно так или так», «предпочтительно», «при необходимости»;
 - текст написан простым языком: без лишнего жаргона, непояснённых сокращений и тяжёлых терминов;
 - мета-уровень не смешан с шагами исполнения;
+- стратегия тестов зафиксирована в разделе `Тесты` и последовательно применена в фазах, сценариях тестирования и проверках;
+- стратегия логирования зафиксирована и последовательно применена в алгоритме, фазах и разделе `Логирование`;
 - тесты связаны с ключевыми сценариями и рисками;
+- если `plan_size: short`, фаз не больше 2, ожидаемый объём укладывается в ориентиры short или исключение явно объяснено;
+- все пакеты/ПО, которые нужно установить, имеют конкретные версии или явное объяснение, почему версия берётся из существующего lock/config-файла;
 - план можно передать в `eda-execute` без нового исследования.
 
 Сохрани файл и покажи путь.
 
-### 5. Мета-ревью плана тремя моделями (параллельно)
+### 6. Мета-ревью плана тремя моделями (параллельно)
 Запусти **в одном сообщении и одним batch** трёх агентов на трёх разных моделях — слабая, средняя, мощная. Не запускай сначала одного-двух, не жди их ответы и не запускай третьего позже: все три проверки должны стартовать до чтения любого результата.
 
 | Среда | Слабая (быстрая) | Средняя (код) | Мощная (флагман) |
@@ -171,7 +321,7 @@ sources:
 
 Когда все три ответили — прочитай ответы, **сам реши**, что применять (не вставляй чужие пункты механически). Принятые замечания сначала интегрируй в основные разделы плана: решения, алгоритм, фазы, тесты, риски. Не оставляй важные требования только в changelog.
 
-После интеграции снова прогони quality gate из этапа 4. Затем допиши в конец короткий раздел:
+После интеграции снова прогони quality gate из этапа 5. Затем допиши в конец короткий раздел:
 
 ```markdown
 ## Изменения после мета-ревью
@@ -185,8 +335,8 @@ sources:
 
 В YAML-шапке: `status: draft` → `meta-reviewed`, в `meta_reviewers` — имена/идентификаторы моделей.
 
-### 6. Кросс-CLI — только в `strict`
-Обычный режим — пропусти этапы 6–7, иди на финал.
+### 7. Кросс-CLI — только в `strict`
+Обычный режим — пропусти этапы 7–8, иди на финал.
 
 В `strict`: отдай файл соседнему агенту через `Bash`. Если ты в Claude Code — запускай Codex CLI:
 
@@ -202,10 +352,10 @@ claude -p "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, связа
 
 Соседней CLI нет — `AskUserQuestion`: продолжать без ревью или прервать.
 
-### 7. Допилить по ревью — только в `strict`
+### 8. Допилить по ревью — только в `strict`
 Бесспорные замечания → правишь сразу. Спорные → `AskUserQuestion`. Отклонённые → оставляешь, причина в журнал. В конец файла добавь раздел `## Реакция на ревью` (Принято / Отклонено / Спорное). Поменяй `status: meta-reviewed` → `reviewed`. Покажи дифф.
 
-### 8. Финал
+### 9. Финал
 Короткое сообщение: режим, путь к плану, путь к ревью (если был `strict`), 3–5 главных шагов простыми словами, что предлагаешь дальше (но не делай — это `eda-execute`).
 
 ## Чего НЕ делать