@gian-tiaga/eda 3.14.0 → 4.0.0

package/skills/eda-orhestra/SKILL.md

@@ -53,7 +53,7 @@ orhestra:
 - `steps`: упорядоченный непустой список. Выполняй сверху вниз только элементы с `enabled: true`; отсутствующий `enabled` считай `true`.
 - `id`: уникальное непустое имя шага для ссылок из `on_failure.then`.
 - `skill`: имя установленного `eda-*`-скила. Не разрешай `eda-orhestra`, `eda-aim`, `eda-commit`, `eda-send-review`, `eda-worktree` и `eda-merge-worktree`.
-- `args`: строка, которую нужно дословно добавить к входу этого скилла. Отсутствующее значение считай пустой строкой. Для дефолтного `eda-plan` передавай `без проверок`, чтобы оба вида ревью выполнил следующий `eda-plan-polish`. Для `eda-polish` здесь же задавай штатный `limit N`; дефолт — `limit 5`.
+- `args`: строка, которую нужно дословно добавить к входу этого скилла. Отсутствующее значение считай пустой строкой. Для дефолтного `eda-plan` передавай `без проверок`, чтобы отключить кросс-CLI strict: проверку плана выполняет следующий `eda-plan-polish`. Для `eda-polish` здесь же задавай штатный `limit N`; дефолт — `limit 5`.
 - `on_failure`: опциональный обработчик `failed` у шага `eda-manual-test`. Если поля нет, сохрани failed-отчёт и остановись без исправлений.
 - `on_failure.skill` и `on_failure.args`: разрешённый установленный скил исправления и его аргументы; дефолты `eda-fix` и пустая строка. Для `skill` действуют те же запреты, что для `steps[].skill`.
 - `on_failure.then`: id шагов, которые после исправления нужно повторить в указанном порядке. Пропускай отключённые шаги. Список должен содержать id активного `eda-manual-test`, иначе исправление нельзя подтвердить.
@@ -100,9 +100,8 @@ orhestra:
 
 Когда нужен человек:
 
-- Claude Code: используй `AskUserQuestion`;
-- Codex interactive: используй `request_user_input`, если доступен; иначе задай один короткий вопрос с 1–3 вариантами и остановись;
-- Codex exec: не читай stdin; заверши `blocked: нужен ответ пользователя` и перечисли варианты.
+- интерактивный запуск: `AskUserQuestion`, затем остановись до ответа;
+- неинтерактивный запуск: не читай stdin; заверши `blocked: нужен ответ пользователя` и перечисли варианты.
 
 После ответа продолжай тот же шаг с его полным предыдущим результатом, а не запускай цепочку сначала.
 

package/skills/eda-plan/SKILL.md

@@ -5,119 +5,100 @@ description: 'Создаёт понятный исполнимый план ре
 
 # Скил: Планировщик (eda-plan)
 
-Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, приводишь план к формату скила до подтверждения пользователем и сохраняешь подтверждённый текст в `docs/artifacts/plans/`. Делишь работу на фазы, каждую из которых один агент выполняет и проверяет за один проход. По настройкам запускаешь `eda-plan-polish`, а в strict — независимую кросс-CLI проверку.
+Собираешь контекст, закрываешь решения с пользователем, показываешь полный план на подтверждение и сохраняешь подтверждённый текст в `docs/artifacts/plans/`. Полировку плана не запускаешь: её делает `eda-plan-polish` или этап `eda-orhestra`. В strict добавляешь кросс-CLI проверку.
 
-## Режим запуска
+План готов, когда исполнитель выполнит его фазу за фазой без нового исследования и вопросов, а всё, что он обязан соблюдать из правил, архитектуры, эталонов и бизнес-карточек, уже выписано в разделе `Рамка`.
 
-Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
+## Настройки
 
-Поддерживается только `version: 3`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолты: `plan.strict: false`, `plan.review: true`, `plan.size: normal`, `plan.decision_mode: recommend_and_ask`, `plan.test_strategy: ask_each_time`, `plan.logging_strategy: ask_each_time`.
+Прочитай `docs/settings.yaml`, если файл есть. Поддерживается только `version: 3`; при другой версии, отсутствующем разделе или неизвестном значении используй дефолт. Прямое указание в текущем сообщении важнее настроек. Дефолты: `plan.strict: false`, `plan.size: normal`, `plan.decision_mode: recommend_and_ask`, `plan.test_strategy: phase_tests_final_checks`, `plan.logging_strategy: standard`.
 
 | Настройка | Значения | Аргументы в сообщении |
 |---|---|---|
 | `plan.strict` | `true`, `false` | `strict`; выключение: `normal`, `без strict`, `без строгого режима` |
-| `plan.review` | `true`, `false` | включение: `с ревью плана`, `с plan-review`; выключение: `без ревью плана`, `без plan-review` |
 | `plan.size` | `normal`, `short`, `ask_each_time` | `short`; обычный: `обычный план`, `не short` |
-| `plan.decision_mode` | `autonomous`, `recommend_and_ask`, `ask_each_time` | `autonomous`, `recommend_and_ask`, `ask_each_time`, «сам выбирай», «рекомендуй и спрашивай», «спрашивай всё» |
-| `plan.test_strategy` | `after_each_phase`, `phase_tests_final_checks`, `tdd_each_phase`, `end_of_plan`, `ask_each_time` | явное указание стратегии тестов и проверок |
-| `plan.logging_strategy` | `debug_precise`, `standard`, `ask_each_time` | явное указание стратегии логирования |
+| `plan.decision_mode` | `recommend_and_ask`, `autonomous`, `ask_each_time` | `autonomous`, `recommend_and_ask`, `ask_each_time`, «сам выбирай», «рекомендуй и спрашивай», «спрашивай всё» |
+| `plan.test_strategy` | `phase_tests_final_checks`, `tdd_each_phase`, `after_each_phase`, `end_of_plan`, `ask_each_time` | явное указание стратегии тестов и проверок |
+| `plan.logging_strategy` | `standard`, `debug_precise`, `ask_each_time` | явное указание стратегии логирования |
 
-Если итоговое значение `plan.size`, `plan.test_strategy` или `plan.logging_strategy` равно `ask_each_time`, задай блокирующий вопрос, кроме случая, когда пользователь уже выбрал значение в текущем сообщении.
+Значение `ask_each_time` у размера, тестов или логирования — блокирующий вопрос, если пользователь не выбрал значение в сообщении. Варианты: размер — `normal` / `short`; тесты — `phase_tests_final_checks` / `tdd_each_phase` / `after_each_phase` / `end_of_plan`; логирование — `standard` / `debug_precise`. `без проверок` устанавливает `plan.strict: false`.
 
-Варианты вопросов: размер плана — `normal` / `short`; тесты и проверки — `after_each_phase` / `phase_tests_final_checks` / `tdd_each_phase` / `end_of_plan`; логирование — `debug_precise` / `standard`.
+Имя `test_strategy` сохраняется для совместимости, но настройка управляет и написанием тестов, и моментом запуска автоматических проверок:
 
-Имя `test_strategy` сохраняется для совместимости, но настройка управляет и написанием тестов, и моментом запуска автоматических проверок. Она обязана менять план:
+- `phase_tests_final_checks` — тесты пишутся в фазе реализации; `Проверка` фазы запускает только добавленные или изменённые в ней тесты, полный набор тестов, линтеры, typecheck и остальные обязательные проверки — в финальной проверке плана;
+- `tdd_each_phase` — фаза начинается с тестов, после реализации запускаются они и все применимые проверки фазы;
+- `after_each_phase` — после реализации фаза добавляет тесты и запускает их вместе со всеми применимыми проверками фазы;
+- `end_of_plan` — тесты и первый запуск автоматических проверок в отдельной финальной фазе; предыдущие фазы подтверждаются неавтоматическими критериями.
 
-- `tdd_each_phase` начинает каждую фазу с тестов, затем выполняет реализацию и запускает написанные тесты вместе со всеми применимыми проверками фазы;
-- `after_each_phase` сначала выполняет реализацию, затем добавляет тесты и запускает их вместе со всеми применимыми проверками фазы;
-- `phase_tests_final_checks` добавляет тесты в ту же фазу, что и реализацию; в `Проверке` фазы оставляет только точечный запуск добавленных или изменённых в ней тестов, а полный набор тестов, линтеры, typecheck, static analysis и остальные обязательные проверки переносит в финальную проверку всего плана;
-- `end_of_plan` выносит написание тестов и первый запуск всех автоматических проверок в отдельную финальную фазу; предыдущие фазы подтверждаются только указанными неавтоматическими критериями готовности.
-
-`logging_strategy` обязан отражаться в алгоритме, фазах и разделе `Логирование`.
-
-`без проверок` одновременно устанавливает `plan.review: false` и `plan.strict: false`. `plan.review` и `plan.strict` независимы.
+`logging_strategy` отражается в алгоритме, фазах и разделе `Логирование`.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скила в текущем сообщении — главный вход. Разбери тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+Текст рядом с вызовом — главный вход: тема, задача, путь к research, режим, ограничения и прямые указания. Старое обсуждение входом не считай, если пользователь не связал его с вызовом. Если входа нет, он противоречив или подходят несколько равных вариантов — спроси.
 
-Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+## Правила
 
-## Вопросы и решения
+1. **Только план.** Не меняй код, миграции, конфиги и зависимости. Запись — только в `docs/artifacts/plans/`.
+2. **Рамка проекта обязательна.** Прочитай `docs/rules.md` и `docs/arch.md` полностью и по их таблицам карточек выбери карточки областей задачи. После определения scope выбери по `docs/business.md` только карточки затронутого поведения, по `docs/references.md` — только карточки затронутых компонентов. Применимые инструкции `AGENTS.md` тоже входят в рамку. Выбранные файлы читай полностью; большой файл — частями до последней строки. Обрезанный вывод не считается прочитанным файлом. Нерелевантные карточки не загружай. Всё, что задача обязана соблюдать, выпиши в `Рамку`.
+3. **Конфликт с рамкой не обходи.** Если нужное решение противоречит правилу, архитектуре или эталону, план до зависимой реализации меняет сам документ отдельной фазой `Обновить правила`, `Обновить архитектуру` или `Обновить эталон: <тема и изменение>`. Документ правится в разделе-владельце на месте, по его структуре и лимиту, без датированных дополнений. Отклонения «с причиной в докблоке» не бывает. Конфликт запроса с business-карточкой покажи пользователю и спроси: менять задачу или сначала пересогласовать правило через `eda-business`.
+4. **Недостающее бизнес-правило — до реализации.** Если нужного пункта нет в business-карточках, он описан не полностью или задача расширяет существующее business-правило, добавь до соответствующей реализации отдельную фазу или пункт `Дополнить бизнесовые правила: <конкретная тема и изменение>`. Чисто техническое изменение без изменения целевого поведения этого не требует. Карточка задаёт требования только к затронутому поведению и не добавляет в план работу, которую не просили.
+5. **Решения закрываются до показа плана.** `autonomous` — выбирай сам и записывай причину; `recommend_and_ask` — рекомендуй и спрашивай по существенным решениям; `ask_each_time` — спрашивай по каждой значимой развилке. Существенные решения: новые зависимости, БД/ORM/очереди/кэш/storage/search, миграции и схемы таблиц, API и внешние контракты, auth/permissions/payments/secrets/персональные данные, cloud/provider/cost/lock-in/SLA, архитектурные паттерны и публичные контракты. Схемы таблиц и API-контракты подтверждай явно, если их не подтвердил research. Подтверждённое в research повторно не спрашивай.
+6. **Каждый ответ пользователя — в `Принятых решениях`.** Ответ записывается так, как его дал пользователь, отдельным пунктом. Если ответ противоречит черновику, переделай черновик, а не формулировку ответа.
+7. **Без самодеятельности.** План не добавляет механизмов, которых нет в запросе, рамке или подтверждённых решениях: шифрование, повторные проверки уже типизированных ответов, новые обёртки, сервисы, классы-посредники, скрипты, контейнеры, повторы, кэши и ожидания. Если механизм кажется нужным — это вопрос пользователю.
+8. **Что, а не как.** План фиксирует поведение, границы, контракты и критерии приёмки. Формула или компактный псевдокод допустимы, если точнее прозы задают правило, контракт, инвариант или критерий приёмки, например `retryAt = now + 5 minutes`. Не фиксируй сигнатуры чужих методов, приведения типов, форму классов и внутренние вычисления без наблюдаемого смысла. Форму кода задают эталоны из `Рамки`. Конкретика не равна подробности: не пересказывай запрос и существующий код и не выдумывай пути, символы или API ради видимости конкретики.
+9. **Один факт — одно место, одно имя — одна сущность.** Требования документов — в `Рамке`, поведение — в `Целевом алгоритме`, контракты — в `Контрактах реализации`, выбор — в `Принятых решениях`. Фаза ссылается на них и не повторяет. Поле, статус, endpoint, команда и событие называются одинаково во всех разделах; всё, на что ссылаются алгоритм и фазы, определено в контрактах или уже есть в проекте.
+10. **Конкретные версии.** Версию пакета, CLI или сервиса без lock-файла найди через context7 или web search; `latest` без версии и источника не пиши. Новый проект разворачивается точной командой официального generator/scaffold CLI (`composer create-project`, `npm create`, `npx`, `cargo new` или реальный аналог); файлы, которые он создаёт, вручную не планируй.
+11. **Инфраструктура, публичные страницы, частый ввод-вывод.** Если задача их затрагивает, закрой решения, которые иначе примет исполнитель, и примени к ним правила проекта: новые переменные окружения и где они задаются во всех окружениях, порт, healthcheck, команда запуска, образ, прокси и CI — в `Документации и эксплуатации`; адреса, 301 со старых адресов, canonical, индексация, sitemap, title и description — в `API и внешних контрактах`; допустимое число запросов к БД и внешних вызовов на операцию и способ проверки — в `Тестах и проверках`.
+12. **Граница и объём.** План доводится до первой точки, где результат можно запустить и проверить целиком; дальше — следующая веха. Объём: `normal` — не больше 40 КБ, `short` — не больше 12 КБ и 2 фаз. Это потолок, а не цель. Размер проверяй командой (`wc -c`); при превышении раздели работу по вехам и предложи первую.
+13. **Без альтернатив и открытых вопросов.** В плане нет «выбрать», «можно так или так», «предпочтительно», «разумный», «TBD», «уточнить позже», качества без меры вроде «быстро», «удобно», «надёжно» и раздела `Открытые вопросы`. Незакрытая развилка — вопрос пользователю до показа плана.
+14. **Удаление — тоже изменение.** Если задача удаляет или переименовывает поведение, поле, endpoint, страницу или команду, план называет, что становится со старыми данными, адресами и клиентами, и проверку, что старого поведения больше нет, а при переименовании — что оно сохранилось.
 
-`decision_mode`: `autonomous` — выбирай сам и записывай причину; `recommend_and_ask` — рекомендуй вариант и спрашивай по существенным решениям; `ask_each_time` — спрашивай по каждой значимой развилке.
+Блокирующий вопрос — `AskUserQuestion`: задав его, остановись до ответа. В неинтерактивном запуске не читай stdin и заверши `blocked: нужен ответ пользователя`.
 
-Существенные решения: новые зависимости, БД/ORM/очереди/кэш/storage/search, миграции, схемы таблиц, API и внешние контракты, auth/permissions/payments/secrets/персональные данные, cloud/provider/cost/lock-in/SLA, архитектурные паттерны и публичные контракты.
+<!-- include: skills/_shared/questions.md -->
 
-Если research содержит подтверждённый ответ пользователя, не спрашивай повторно. Если задача меняет БД или API, проверь, подтверждены ли конкретные схемы таблиц и API-контракты; если конкретные схемы БД или API-контракты не подтверждены явно, получи подтверждение пользователя и не проектируй таблицы и маршруты молча внутри Plan Mode.
+## Этапы
 
-Блокирующий вопрос: Claude Code — `AskUserQuestion`; Codex interactive — `request_user_input` или короткий вопрос с вариантами; Codex exec — не читай stdin, заверши со статусом `blocked: нужен ответ пользователя`.
+### 1. Собрать контекст
 
-## Обязательные правила
+Разбери вход и настройки, прочитай рамку по правилу 2 и код затронутых мест. Research подтягивай без вопроса, если путь указан. Описание задачи без research-файла — достаточный вход: не спрашивай research автоматически. Если пользователь просит research без пути, предложи последние файлы из `docs/artifacts/researches/` и вариант «нет». Проверь версии нужных пакетов.
 
-1. Никаких правок кода, миграций, конфигов и зависимостей. Запись только в `docs/artifacts/plans/`.
-2. `docs/rules.md` и `docs/arch.md` — обязательная рамка планирования, а не справочный контекст. Прочитай их, выдели применимые правила и архитектурные ограничения, передай их в Plan Mode как обязательные требования.
-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. План фиксирует решения, границы, контракты и критерии приёмки. Формулы и компактный псевдокод допустимы, когда они точнее прозы задают бизнес-правило, контракт, инвариант или критерий приёмки, например `retryAt = now + 5 minutes`. Сам формульный синтаксис не превращает контракт в деталь реализации. Не фиксируй сигнатуры чужих методов, приведения типов, порядок строк внутри метода, форму классов и внутренние вычисления, которые не задают наблюдаемое поведение. Если утверждение можно проверить только по конкретному коду, оно относится к code review, а не к плану.
-11. Не пересказывай прозой то, что уже лежит рядом: правила, архитектуру и кодовые примеры карточек. Ссылайся на них.
-12. Один факт — одно место. Поведение описано в `Целевом алгоритме`, контракты — в `Контрактах реализации`, фаза на них опирается и не повторяет их.
-13. План доводится до первой точки, где результат можно запустить и проверить целиком. Дальше планируй следующей вехой, на фактах.
-14. Если нужны пакеты, библиотеки, CLI или сервисы, а версия не указана в контексте или lock-файлах, найди последнюю стабильную версию через context7 или web search. Не пиши `latest` без конкретной версии и источника.
-15. Если план разворачивает новый проект и у выбранного стека есть официальный generator/scaffold CLI, план обязан использовать точную команду этого CLI или package manager (`composer create-project`, `npm create`, `npx`, `cargo new` или реальный аналог). Не планируй ручное создание файлов, которые штатно генерирует этот инструмент; последующие целевые изменения поверх результата CLI допустимы.
-16. Финальный план прост, исполним и без альтернатив вида «выбрать», «решить», «можно так или так», «предпочтительно».
+### 2. Закрыть решения
 
-## Технические остановки субагентов
+Собери существенные решения и развилки. Какие из них выносить на вопрос, задаёт `decision_mode`; задавай их раундами по разделу «Как задавать вопросы» и дождись ответов. Ответы запиши по правилу 6.
 
-Техническую ошибку инструмента субагентов не смешивай со статусами `failed` и `blocked` содержательного контракта. Сохрани полный исходный текст ошибки и обработай её по причине:
+### 3. Показать полный план
 
-- лимит параллельности или отсутствие свободного слота — дождись уже запущенного этим workflow агента, при необходимости закрой завершённые потоки и повтори тот же запуск; если управляемых активных агентов нет, заверши `blocked: заняты слоты субагентов`;
-- лимит глубины вложения — не повторяй запуск и не выполняй этап сам; заверши `blocked: достигнут лимит глубины субагентов`, указав наблюдаемую и требуемую глубину;
-- исчерпана usage-квота — не делай автоматических повторов; заверши `blocked: исчерпана квота`, сохрани время reset или условие продолжения, если хост его сообщил;
-- не хватает разрешения — запроси одно конкретное разрешение по правилам текущей среды и после ответа продолжи того же агента; в неинтерактивной среде заверши `blocked: нужно разрешение пользователя`;
-- временная API-, server-, overload- или network-ошибка — один раз продолжи того же агента; если resume недоступен, один раз запусти ту же роль с исходным входом, полным частичным результатом и требованием сначала сверить текущее состояние; повторный такой сбой заверши как `blocked` с исходной ошибкой;
-- неизвестная техническая ошибка — не угадывай причину и не зацикливай retry; заверши `blocked: техническая ошибка субагента` с полным исходным текстом.
+Составь план по шаблону ниже и проверь его по разделу «Проверка перед показом». Покажи полный текст плана — front matter, все разделы по порядку, фазы со всеми полями. Резюме, список шагов или ссылка на файл не заменяют план.
 
-Ожидание слота и один технический retry не расходуют лимиты содержательных итераций.
+- Claude Code — в Plan Mode; выйди из него с полным текстом плана и дождись подтверждения.
+- Codex, OpenCode и другие среды — полным текстом в чате; остановись до подтверждения.
 
-## Этапы
+После правок пользователя покажи план снова целиком. Без подтверждения план не сохраняй.
 
-### 1. Собрать контекст
+### 4. Сохранить
 
-- Разбери вход и настройки.
-- Прочитай `docs/rules.md` и `docs/arch.md`; выпиши применимые команды проверки, требования к тестам, границы модулей, зависимости, миграции, безопасность и локальные запреты.
-- Выбери и прочитай применимые карточки `docs/business.md` и `docs/references.md`. Нерелевантные не загружай.
-- Research подтягивай без вопроса, если путь указан; если в сообщении есть описание задачи без research-файла, используй описание как контекст и не спрашивай research автоматически. Если пользователь явно просит research, но файл не указал, предложи последние файлы из `docs/artifacts/researches/` и вариант «нет».
-- Проверь версии нужных пакетов, если они не зафиксированы.
-- Закрой существенные решения по `decision_mode`.
+Сохрани подтверждённый текст без изменений в `docs/artifacts/plans/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
 
-### 2. Запустить Plan Mode
+### 5. Strict: кросс-CLI
 
-Передай в Plan Mode:
+Обычный режим этап пропускает. В `strict` отдай файл соседнему CLI:
 
-1. Дословный запрос пользователя.
-2. `plan_size`, `decision_mode`, `test_strategy`, `logging_strategy`.
-3. Подтверждённые существенные решения и пары «вопрос → ответ».
-4. Найденные версии пакетов и источники.
-5. Пути к `docs/rules.md`, `docs/arch.md`, применимым карточкам и research с выпиской обязательных требований рамки.
-6. Требование: план следует правилам, архитектуре и применимым эталонам. Если нужное решение им противоречит, план сначала меняет сам документ отдельным пунктом, а не отклоняется от него.
-7. Требование: уже на подтверждение пользователь получает полный план по шаблону этапа 3, включая YAML front matter, все разделы в заданном порядке и фазы с полями «Цель», «Что сделать», «Результат», «Проверка». Это формат и показа в Plan Mode, и сохраняемого файла.
-8. Требование: конкретика не равна максимальной подробности. План описывает, что и зачем меняется, а не как это написать: не пересказывать запрос и существующий код, не повторять один контракт в нескольких разделах, не выдумывать пути, символы или API ради видимости конкретики. Реализацию задают `docs/rules.md`, `docs/arch.md` и карточки.
+```bash
+codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md и все файлы из sources. Проверь план по релевантному коду: открой файлы, модули и тесты, которые следуют из плана, и оцени фактическую реализуемость. Верни только конкретные ошибки, которые обязательно исправить: место, доказательство, риск и минимальную правку. Не предлагай расширение текста и стилистику. Список '- [тип] описание — что исправить'." > "${PLAN_FILE%.md}_review.md"
+```
 
-До запроса подтверждения нормализуй план и прогони quality gate из этапа 3. Покажи полный текст плана в формате скила; краткое резюме, список главных шагов или ссылка на файл не заменяют план на подтверждение. При правках пользователя обнови план и снова предъяви его целиком в том же формате. Не выходи из Plan Mode, пока пользователь не подтвердил план.
+Если ты в Codex — запускай `claude -p` с тем же заданием. Если соседней CLI нет, спроси, продолжать без ревью или прервать. Бесспорные замечания внеси, спорные вынеси вопросом, отклонённые зафиксируй с причиной в `## Реакция на ревью`. Поставь `status: reviewed` и покажи дифф.
 
-### 3. Сохранить подтверждённый план
+### 6. Финал
 
-Сохрани подтверждённый план в `docs/artifacts/plans/{YYYY-MM-DD}_{HH-MM}_{slug}.md` с теми же содержанием и структурой, которые показал пользователю. Нормализация формы и ясности должна быть завершена до подтверждения.
+Сообщи режим, выполнялся ли strict, путь к плану, итоговый статус, 3–5 главных шагов и что дальше: `eda-plan-polish` или `eda-plan-execute`.
 
-Единый шаблон для показа на подтверждение и сохранения:
+## Шаблон
 
-```markdown
+Единый для показа и сохранения. Разделы идут в этом порядке; пустой контракт — строка `Не затрагивается`.
+
+````markdown
 ---
 title: <заголовок>
 date: <YYYY-MM-DD HH:MM>
@@ -131,8 +112,8 @@ plan_review_fix: <docs/artifacts/plan-review-fixes/... | none>
 test_strategy: <after_each_phase | phase_tests_final_checks | tdd_each_phase | end_of_plan>
 logging_strategy: <debug_precise | standard>
 sources:
-  rules: <путь или —>
-  arch: <путь или —>
+  rules: [docs/rules.md, <применимые карточки docs/rules/ или пусто>]
+  arch: [docs/arch.md, <применимые карточки docs/arch/ или пусто>]
   business: [<пути к применимым карточкам или пусто>]
   references: [<пути к применимым карточкам или пусто>]
   research: <путь или —>
@@ -141,44 +122,63 @@ sources:
 # План реализации
 
 ## Задача
-Что нужно реализовать и какой результат считается готовым. Что в план не входит, если границу легко перепутать.
+Что нужно сделать и какой результат считается готовым. Что не входит, если границу легко перепутать.
+
+## Рамка
+Только то, что эта задача обязана соблюдать. Одна строка на пункт: источник и раздел → что это значит для задачи.
+- `docs/rules.md` «<раздел>» → <требование в применении к задаче>.
+- `docs/arch/<область>.md` «<раздел>» → <граница или поток, который задача не нарушает>.
+- `docs/references/<компонент>.md` → <какой компонент пишется по этому эталону>.
+- `docs/business/<тема>.md` «<раздел>» → <правило затронутого поведения>.
 
 ## Целевой алгоритм
-Сквозное поведение системы от входного события до финального состояния. Единственное место, где описано поведение. Состояния и переходы — таблицей, проза только для связок.
+Сценарии в том порядке, в котором они происходят: сначала то, что должно существовать или выполниться заранее (данные, синхронизация, фоновые процессы), затем действия пользователя и ответ системы.
+
+### <Сценарий>
+1. <Кто> <делает что> → <что видит или получает>.
+2. Система <проверяет / сохраняет / отправляет / показывает> <что именно>.
+   - Если <условие> — <что происходит>.
+3. ...
+
+Ошибки: <шаг> — <что видит пользователь, в каком состоянии остаются данные и как продолжить>.
 
 ## Контракты реализации
 
 ### Данные и БД
-Если БД не меняется: `Не затрагивается`. Иначе таблицы, поля, типы, обязательность, default, связи, индексы, unique, миграции, совместимость со старыми данными и rollback.
+Для каждой новой или изменяемой таблицы:
+
+#### `<таблица>` — <новая | изменяется>
+| Поле | Тип | Null | По умолчанию | Назначение |
+|---|---|---|---|---|
+
+Индексы и ограничения, связи, миграция существующих данных и откат — коротко под таблицей.
 
 ### API и внешние контракты
-Если не меняются: `Не затрагивается`. Иначе метод и путь, auth/permissions, request/query/body, response, ошибки и status codes, события, очереди и внешние сервисы.
+Метод и путь, auth/permissions, запрос, ответ, ошибки и коды, события, очереди и внешние сервисы.
 
 ### Интерфейс и дизайн
-Если интерфейс не меняется: `Не затрагивается`. Иначе опиши состав и организацию затронутых страниц или экранов: основные области и элементы, их расположение, назначение и взаимосвязи. Используй заданные макеты или референсы; если их нет — текущий дизайн проекта. Формат выбирай по содержанию: свободный текст или таблица `Страница | Описание дизайна`.
-
-Не повторяй здесь целевой алгоритм и содержание фаз. Поведение упоминай только тогда, когда без него нельзя понять состав или организацию интерфейса.
+Состав и организация затронутых экранов: области и элементы, их расположение и связи; макеты или референсы, иначе текущий дизайн проекта. Поведение здесь не повторяется.
 
 ### Консольные команды
-Если команды не меняются: `Не затрагивается`. Иначе перечисли точки входа и команды в таблице:
-
 | Команда | Аргументы и опции | Назначение |
 |---|---|---|
 
 ## Фазы выполнения
 
 ### 1. <Название фазы>
-Цель: одно предложение — зачем нужна фаза.
+Цель: одно предложение — зачем фаза.
 
-Что сделать: несколько предложений — что появляется в системе и как части связаны между собой. Не как это писать.
+Что сделать: связным текстом — что появляется в системе и как части связаны. Не перечень файлов и не «как писать».
+
+Согласование: <только если пользователь просил согласовать промежуточный результат: что показать и чего ждать>.
 
 Результат: проверяемое состояние системы после фазы.
 
 Проверка:
-- команда или критерий готовности.
+- команда с ожидаемым результатом или наблюдаемое состояние системы по `test_strategy`.
 
 ## Тесты и проверки
-Стратегия, сценарии по поведению, фазовые и финальные команды — в одном месте, а не дублируются внутри каждой фазы. В поле `Проверка` фазы остаётся только применимый к ней запуск или критерий согласно `test_strategy`.
+Стратегия, сценарии по поведению — включая каждую ветку «Если …» и каждую ошибку алгоритма, — фазовые и финальные команды в одном месте.
 
 ## Логирование
 Стратегия, уровни, обязательные поля и что писать запрещено.
@@ -187,86 +187,44 @@ sources:
 Что обновить в env, docs, runbook и что важно для релиза.
 
 ## Принятые решения
-Выбранные решения без вариантов. Для существенных — источник подтверждения: ответ пользователя, research или `autonomous` с причиной.
-```
+- <решение> — источник: ответ пользователя «<ответ>» | research <путь> | `autonomous`: <причина>.
+````
 
-Правила структуры:
+Формат `Целевого алгоритма`:
 
-- Задач с идентификаторами внутри фаз нет. Порядок фаз задаёт порядок работы.
-- Фаза — это цель, что сделать, результат и проверка. Ничего больше.
-- В `Что сделать` пиши связным текстом, а не перечнем файлов: должно быть видно, как части работают вместе. Каждое предложение говорит, что появится, как это связано с остальным или чем ограничено. Если её удаление ничего из этого не меняет, удали её из плана.
-- В фазах нельзя ограничиваться общими формулировками вроде «обновить UI», «добавить сервис», «реализовать логику». Для UI опиши пользовательский сценарий, состояния успеха и ошибки и видимый результат; для внутренней логики — ответственность частей, поток данных, состояния и ошибки.
-- Не описывай в фазе то, что уже зафиксировано в `Целевом алгоритме`, `Контрактах` или `Принятых решениях`: сошлись на них.
-- Риски и порядок выполнения отдельными разделами не выносятся: закрытые риски встраиваются в решения, фазы, тесты и проверки.
-- Раздела `Открытые вопросы` в плане нет. Незакрытая развилка — это блокирующий вопрос пользователю до сохранения, а не пункт в файле.
+- шаг — одно действие и его наблюдаемый результат простым языком; сущности, поля, команды и экраны называй своими именами, внутренние классы и методы — нет;
+- ветки — подпунктами «Если …», ошибки — после шагов сценария; у шага с внешним вызовом или изменением данных ошибка обязательна: что видит пользователь, что с данными и как продолжить после сбоя посередине;
+- таблица допустима только для матрицы статусов (статус → разрешённые действия) и формул расчёта.
 
-Quality gate перед показом на подтверждение, перед сохранением и после каждой включённой проверки:
-
-- есть `Целевой алгоритм` и `Контракты реализации` с подразделами `Данные и БД`, `API и внешние контракты`, `Интерфейс и дизайн` и `Консольные команды`;
-- применимые business-карточки выбраны после определения scope, записаны в `sources.business` и отражены в критериях приёмки;
-- каждый отсутствующий, неполный или расширяемый пункт целевого поведения покрыт отдельной задачей `Дополнить бизнесовые правила` до зависимой реализации; для чисто технических изменений такая задача не добавлена;
-- план строго следует `docs/rules.md` и `docs/arch.md`, а также применимым reference-карточкам; там, где нужно другое поведение, есть отдельный пункт на изменение самого документа до зависимой реализации;
-- каждая фаза имеет цель, что сделать, результат и проверку и выполнима одним агентом за один проход;
-- в плане нет сигнатур, приведений типов, формы классов, внутренних вычислений без контрактного смысла и пересказа карточек; формулы, задающие обязательное поведение, не удалены только из-за формы записи;
-- ни один факт не описан в двух разделах;
-- `test_strategy` и `logging_strategy` применены;
-- пакеты имеют конкретные версии или ссылку на существующий lock;
-- bootstrap нового проекта использует существующий официальный CLI выбранного стека, а не ручное воспроизведение scaffold;
-- нет неподтверждённых существенных решений, неразрешённых альтернатив и открытых вопросов;
-- нет общих призывов, повторов и пояснений, удаление которых не меняет действия, контракты, проверки или принятые решения;
-- объём: `normal` — не больше 40 КБ, `short` — не больше 12 КБ и 2 фаз. Это стоп, а не цель: план настолько короткий, насколько позволяет однозначность. При превышении раздели план по вехам и предложи пользователю первую;
-- план можно передать в `eda-plan-execute` без нового исследования.
-
-### 4. Полировка плана
-
-Если `plan.review: false`, пропусти этап, оставь `plan_review: none`, `plan_review_fix: none` и перейди дальше.
-
-Иначе запусти `eda-plan-polish` в отдельном изолированном субагенте с чистым контекстом. Основной планировщик не делает review или fix сам.
-
-Прогоняется ровно одна итерация полировки — `limit 1`: одна проверка и одно исправление. Второй круг здесь не нужен: план уже прошёл quality gate, и лишние итерации чаще раздувают текст, чем улучшают его. Плата за это — исправление остаётся неперепроверенным, поэтому `status: reviewed` появится только если ревью сразу вернуло `ready`.
-
-1. Запусти один `eda-plan-polish`:
-
-```text
-Используй eda-plan-polish для <PLAN_FILE> с limit 1.
-Прогони ровно одну итерацию полировки: проверка и исправление. Дальше не иди.
-Исходная задача и решения: <текущий запрос и ответы пользователя>.
-Верни результат, последний review/fix, score, threshold и открытые ID.
-```
-
-Проверь артефакты и снова прогони quality gate. При `ready` убедись, что front matter содержит `status: reviewed` и последние пути review/fix. Содержательных правок сам не делай. При limit, отсутствии прогресса или `blocked` не выдавай план за подтверждённый.
-
-При недоступности нативных субагентов остановись; не используй CLI-fallback для этого этапа.
-
-### 5. Strict: кросс-CLI
-
-`plan.strict` не зависит от `plan.review`. Обычный режим этап пропускает. В `strict` отдай файл соседнему CLI:
-
-```bash
-codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md и применимые карточки из sources. Проверь план по релевантному коду: открой файлы, модули и тесты, которые следуют из плана, и оцени фактическую реализуемость. Верни только конкретные ошибки, которые обязательно исправить: место, доказательство, риск и минимальную правку. Не предлагай расширение текста и стилистику. Список '- [тип] описание — что исправить'." > "${PLAN_FILE%.md}_review.md"
+```markdown
+### Регистрация
+1. Пользователь отправляет `/start` в личном чате.
+2. Бот показывает кнопку «Поделиться контактом».
+3. Пользователь делится контактом.
+4. Система проверяет, что контакт его собственный, и ищет клиента в CRM по телефону.
+   - Если найден один — привязывает его к пользователю.
+   - Если не найден — создаёт клиента с именем из Telegram.
+5. Бот показывает главное меню.
+
+Ошибки: CRM недоступна на шаге 4 — бот сообщает об этом, регистрация не завершается, повторный `/start` продолжает с шага 2.
 ```
 
-Если ты в Codex — запускай `claude -p` с тем же заданием. Если соседней CLI нет, спроси, продолжать без ревью или прервать.
-
-Бесспорные замечания внеси в план, спорные вынеси через `AskUserQuestion`, отклонённые зафиксируй с причиной в `## Реакция на ревью`. Поставь `status: reviewed`, покажи дифф.
-
-### 6. Финал
-
-Коротко сообщи режим, выполнялись ли polish и strict, путь к плану, пути к последним артефактам проверок, итоговый статус, открытые вопросы, 3–5 главных шагов и что дальше делает `eda-plan-execute`. Если требуется повторное подтверждение плана, предъяви полный актуальный текст по шаблону этапа 3.
-
-## Чего НЕ делать
-
-- Править код, миграции, конфиги или зависимости.
-- Считать `docs/rules.md` и `docs/arch.md` просто контекстом для ознакомления.
-- Писать в план сигнатуры чужих методов, приведения типов, форму классов и формулы внутренних вычислений, которые не задают бизнес-правило, контракт, инвариант или критерий приёмки.
-- Пересказывать прозой правила, архитектуру и кодовые примеры карточек.
-- Отклоняться от правил и архитектуры «с причиной» вместо того, чтобы менять сам документ.
-- Разбивать фазы на задачи с идентификаторами и графом зависимостей.
-- Повторять один факт в нескольких разделах.
-- Планировать дальше первой проверяемой вехи и добивать план до потолка объёма.
-- Переформулировать запрос пользователя перед Plan Mode.
-- Сохранять сырой текст Plan Mode без нормализации.
-- Оставлять план исследованием, списком наблюдений или журналом ревью.
-- Сохранять план с открытыми вопросами вместо того, чтобы задать их пользователю.
-- Выполнять plan-review, plan-review-fix или plan-polish основным агентом.
-- Пропускать кросс-CLI молча в `strict`: если CLI нет, спроси.
+Фаза — только цель, что сделать, необязательное согласование, результат и проверка; задач с идентификаторами и графа зависимостей нет. В `Что сделать` не пиши общих слов вроде «обновить UI», «добавить сервис»: для UI — сценарий, состояния успеха и ошибки и видимый результат; для логики — ответственность частей, поток данных и ошибки. Каждая фаза выполнима одним агентом за один проход вместе с проверкой. Риски и порядок не выносятся в отдельные разделы: закрытый риск становится решением, шагом алгоритма или проверкой.
+
+## Проверка перед показом и сохранением
+
+- разделы шаблона на месте и в порядке, front matter заполнен;
+- `Рамка` содержит каждое применимое требование правил, архитектуры, эталонов, бизнес-карточек и `AGENTS.md` с источником и разделом, и ничего неприменимого;
+- `sources` перечисляет все файлы, на которые ссылается `Рамка`;
+- недостающие бизнес-правила и изменения рамки — отдельные фазы до зависимой реализации;
+- алгоритм — сценарии из нумерованных шагов в порядке выполнения, без таблиц событий; у шагов с внешними вызовами и изменением данных есть ошибки и способ продолжить;
+- каждая ветка и ошибка алгоритма есть в `Тестах и проверках`; каждый сценарий и контракт реализует какая-то фаза;
+- каждое поле, статус, endpoint и команда названы одинаково во всех разделах;
+- удаляемое и переименованное поведение описано по правилу 14;
+- каждая изменяемая таблица БД описана своей таблицей колонок;
+- каждый ответ пользователя записан в `Принятых решениях`, и план ему не противоречит;
+- в плане нет механизмов вне запроса, рамки и решений;
+- у каждой фазы есть цель, что сделать, результат и проверка — команда с ожидаемым результатом или наблюдаемое состояние; `test_strategy` и `logging_strategy` применены;
+- нет повторов фактов между разделами, альтернатив, открытых вопросов, общих призывов и пояснений, удаление которых ничего не меняет;
+- пакеты с версиями, bootstrap — через официальный CLI, решения правила 11 записаны;
+- размер в пределах потолка.