@gian-tiaga/eda 0.6.1 → 0.6.2

package/README.md

@@ -29,8 +29,8 @@ eda init
 |---|---|---|
 | `eda-roadmap` | Создаёт roadmap-файл: список будущих задач с короткими, понятными и недвусмысленными описаниями без деталей реализации, файлов, библиотек, API и пошагового плана | `docs/roadmaps/` |
 | `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки, риски внутри решений и короткий выбранный вариант решения без плана. В дефолтном режиме ведёт исследование как диалог: факты собирает сам, а значимые развилки выносит тебе с рекомендацией. Если нужны пакеты или ПО — проверяет актуальные стабильные версии через context7 или web search | `docs/researches/` |
-| `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. Подтягивает контекст из `docs/rules.md`, `docs/arch.md`, при желании — релевантное исследование. В плане явно фиксирует контракты БД/API, если задача их затрагивает. Затем три параллельных субагента/модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить | `docs/plans/` |
-| `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
+| `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. `docs/rules.md` и `docs/arch.md` использует как обязательную рамку, а не справочный контекст: план должен строго следовать правилам и архитектуре. В плане явно фиксирует контракты БД/API, если задача их затрагивает. Затем три параллельных субагента/модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить | `docs/plans/` |
+| `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Перед правками читает план, `docs/rules.md` и `docs/arch.md`; правила и архитектура обязательны к исполнению. Если шаг плана им противоречит, останавливается и спрашивает. Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
 | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или файлу плана. Перед правками читает правила и архитектуру, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/fixes/` |
 | `eda-review` | Делает код-ревью с оценкой 0–100 и сверкой с планом работ, но в файл пишет только проблемы: ошибки, недоделки, неточности, нарушения правил/архитектуры, риски и недостающие тесты. Не перечисляет выполненную работу. Затем параллельные специализированные агенты проверяют выполнение плана, архитектуру, правила и при включённой настройке качество кода. В строгом режиме — ещё и кросс-ревью между Claude и Codex | `docs/reviews/` |
 | `eda-fix-by-review` | Применяет замечания из ревью. Обязательные — сразу. Спорные — спрашивает. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "0.6.1",
+  "version": "0.6.2",
   "description": "Набор скилов eda-* для Claude Code и Codex CLI: roadmap, explore, plan, execute, fix, review, fix-by-review, send-review, commit, worktree, merge-worktree, docs, automate",
   "type": "module",
   "bin": {

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)
@@ -15,11 +15,11 @@ description: 'Исполняет план из docs/plans/ по пути или
 
 ## Главные правила
 
-1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Это рамка проекта. Файлов нет — продолжай молча. Один раз в начале, не перечитывать на каждом шаге.
+1. **`docs/rules.md` и `docs/arch.md` обязательны к исполнению.** Перед правками прочитай план, `docs/rules.md` и `docs/arch.md`, если они есть. Выполняй план только в той форме, которая строго следует правилам и архитектуре проекта. Если шаг плана противоречит `docs/rules.md` или `docs/arch.md`, не исполняй его молча и не выбирай обходной путь сам. Остановись и задай `AskUserQuestion`: адаптировать выполнение под правила/архитектуру, вернуться к `eda-plan` для исправления плана или изменить правила/архитектуру отдельной задачей.
 2. **Интерактивные вопросы** — по разделу ниже.
 3. **Не переформулируй план.** Шаг непонятен — спроси, не «доразрабатывай» молча.
 4. **Не коммитить, не пушить, не делать ревью.** Это другие скилы.
-5. **Идти целиком**, не делать паузы «для подтверждения». Останавливайся только если: тест упал, шаг противоречив, есть риск потерять данные, рискованная операция вне плана.
+5. **Идти целиком**, не делать паузы «для подтверждения». Останавливайся только если: тест упал, шаг противоречив, есть риск потерять данные, рискованная операция вне плана, шаг плана противоречит `docs/rules.md` или `docs/arch.md`.
 6. **Проверки нельзя подавлять.** Не отключай линтеры, тесты, typecheck, static analysis и другие проверки; не добавляй игноры, исключения из проверок, ослабление правил или изменение команд так, чтобы проверка перестала запускаться. Пиши и правь код так, чтобы проверки проходили по сути.
 7. **Простой язык** в сообщениях пользователю и вопросах. Термины — только если без них нельзя, и сразу с пояснением.
 8. **Таблицы для структурируемых данных** в журнале. Диаграммы — только если действительно есть что показать.
@@ -31,7 +31,7 @@ description: 'Исполняет план из docs/plans/ по пути или
 - Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
 - Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
 - Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-- Для выполнения кода это правило важнее требования идти целиком: не додумывай план, не делай рискованные операции и не правь чужие/несвязанные поломки вместо ответа пользователя.
+- Для выполнения кода это правило важнее требования идти целиком: не додумывай план, не исполняй шаги вопреки `docs/rules.md` или `docs/arch.md`, не делай рискованные операции и не правь чужие/несвязанные поломки вместо ответа пользователя.
 
 ## Этапы
 
@@ -73,7 +73,9 @@ cd ../<repo-name>-<slug>
 И **выйди из скила** — текущая сессия в эту папку не переедет, поэтому продолжать здесь нельзя. Сообщи пользователю, что ждёшь его в новой сессии.
 
 ### 3. Прочитать контекст
-План + `docs/rules.md` и `docs/arch.md` (если есть). Правилам и архитектуре строго следуй при каждой правке. Тест-фреймворк проекта определи сам по конфигам/существующим тестам.
+План + `docs/rules.md` и `docs/arch.md` (если есть). `docs/rules.md` и `docs/arch.md` обязательны к исполнению, а не просто к прочтению. Выполняй план только в той форме, которая строго следует правилам и архитектуре проекта. Тест-фреймворк проекта определи сам по конфигам/существующим тестам.
+
+Перед выполнением проверь, нет ли в плане шагов, зависимостей, API, миграций, границ модулей, команд проверки или решений, которые противоречат `docs/rules.md` или `docs/arch.md`. Если конфликт есть — остановись и задай `AskUserQuestion`: адаптировать выполнение под правила/архитектуру, вернуться к `eda-plan` для исправления плана или изменить правила/архитектуру отдельной задачей.
 
 ### 4. Инициализировать прогресс
 - Создай журнал `docs/executions/{YYYY-MM-DD}_{HH-MM}_{slug}.md` (slug — тот же, что у плана, или близкий).
@@ -106,11 +108,14 @@ cd ../<repo-name>-<slug>
 
 ### 5. Выполнить план
 Идёшь по шагам. На каждом:
-1. Сделай правки.
-2. Выполни проверки, если они прямо указаны в шаге.
-3. Поставь `[x]` в файле плана и допиши строку в таблицу журнала.
+1. Перед правкой сверяешь действие с `docs/rules.md` и `docs/arch.md`.
+2. Если правила или архитектура задают способ реализации, границы модулей, команды проверки, требования к тестам, миграциям, API, безопасности или документации — следуй им даже тогда, когда план описан менее строго.
+3. Если есть конфликт с правилами или архитектурой — не правь код, задай `AskUserQuestion`.
+4. Сделай правки.
+5. Выполни проверки, если они прямо указаны в шаге.
+6. Поставь `[x]` в файле плана и допиши строку в таблицу журнала.
 
-Останавливайся и спрашивай через `AskUserQuestion`, если: тесты к шагу упали и не правятся быстро / шаг противоречит коду / задевает рискованное вне плана. Архитектурное решение по ходу — записывай в «Изменения в docs», не блокируй.
+Останавливайся и спрашивай через `AskUserQuestion`, если: тесты к шагу упали и не правятся быстро / шаг противоречит коду / шаг противоречит `docs/rules.md` или `docs/arch.md` / задевает рискованное вне плана. Архитектурное решение по ходу — записывай в «Изменения в docs», но не меняй зафиксированную архитектуру молча.
 
 После последнего шага — `finished` и `status: done` в шапке журнала.
 
@@ -131,3 +136,6 @@ cd ../<repo-name>-<slug>
 - Пропускать обновление чекбоксов и журнала — иначе теряется состояние.
 - Делать рискованное (удаление файлов, миграции, секреты) без подтверждения, даже если упомянуто в плане.
 - Подавлять ошибки линтеров, тестов, typecheck или других проверок вместо исправления кода.
+- Считать `docs/rules.md` и `docs/arch.md` просто контекстом для ознакомления.
+- Исполнять план, который противоречит правилам или архитектуре проекта.
+- Обходить правило или архитектурное ограничение без явного решения пользователя.

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 подтягивает без вопроса, если он указан или явно нужен. Поддерживает `short` для небольших фич: 1–2 фазы и компактный ревьюируемый объём. В начале фиксирует режим принятия решений, стратегию тестов и логирования из docs/settings.yaml или уточняет их у пользователя. Существенные решения подтверждает по `defaults.decision_mode`. Нормализует результат в исполнимый план с алгоритмом, фазами, проверками и без неразрешённых альтернатив; сохраняет его в docs/plans/. Всегда проверяет план тремя субагентами/моделями на реалистичность, пропущенные шаги, нарушения правил и риски. Кросс-CLI включается флагом `strict` или настройкой `defaults.strict: true`. Вопросы задаёт только когда без ответа нельзя безопасно продолжать, настройки требуют спрашивать или существенное решение требует подтверждения.'
+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`.'
 ---
 
 # Скил: Планировщик (eda-plan)
@@ -107,15 +107,17 @@ description: 'Пишет план реализации по тексту ряд
 
 1. **Никаких правок кода.** Запись только в `docs/plans/`.
 2. **Интерактивные вопросы** — по разделу ниже.
-3. **Plan Mode — главный инструмент.** Он даёт содержательный черновик, но финальный файл обязан быть нормализован в формат этого скилла.
-4. **Не переформулируй запрос пользователя** перед Plan Mode. Уйдёт оригинал + ответы на уточнения. Своя цель/критерии разводят смысл.
-5. **План сохраняется в файл до любой верификации** — иначе ревьюеру нечего читать.
-6. **Максимально простой язык.** Пиши план так, чтобы его понял человек без глубокого погружения в код. Избегай жаргона, сокращений и внутренних названий без необходимости. Термины используй только когда без них нельзя точно донести смысл, и сразу объясняй их простыми словами.
-7. **Диаграммы — желательно, не любой ценой.** Линейный план — диаграмма не нужна.
-8. **Таблицы > сплошной текст** для структурируемых данных.
-9. **Финальный план — не исследование.** Исследовательские факты идут в контекст, выбранные подходы — в решения, исполнимые шаги — в фазы.
-10. **Не оставляй неоднозначности.** Если в плане остаётся «выбрать», «решить», «можно так или так», «предпочтительно» — задай вопрос до финализации или зафиксируй одно принятое решение. Существенные решения фиксируй только по правилам `decision_mode`.
-11. **Версии пакетов и ПО проверяй до планирования.** Если для задачи нужно устанавливать пакет, библиотеку, сервис, CLI или другое ПО, а версия не указана в контексте, используй `context7`, если он доступен, или веб-поиск, чтобы найти актуальную последнюю стабильную версию. Зафиксируй найденную версию и источник в контексте/решениях плана. Не оставляй в плане «установить latest» без конкретной версии.
+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» без конкретной версии.
 
 ## Размер плана
 
@@ -163,7 +165,9 @@ description: 'Пишет план реализации по тексту ряд
 - иначе возьми `defaults.decision_mode` из `docs/settings.yaml`;
 - если значение отсутствует или неизвестно — `recommend_and_ask`.
 
-Прочитай `docs/rules.md`, `docs/arch.md` (если есть) и строго следуй им при планировании.
+Прочитай `docs/rules.md`, `docs/arch.md` (если есть) и строго следуй им при планировании. Выдели применимые правила и архитектурные ограничения: команды проверки, требования к тестам, границы модулей, зависимости, API, миграции, безопасность, документацию и локальные запреты. Передай эту рамку в Plan Mode как обязательные требования, а не как справочный контекст.
+
+Если задача, research или очевидный подход конфликтует с `docs/rules.md` или `docs/arch.md`, остановись до Plan Mode и задай `AskUserQuestion`: изменить подход под правила/архитектуру, изменить сами правила/архитектуру отдельной задачей или прервать планирование.
 
 Research подтягивай так:
 - если в сообщении указан путь к `docs/researches/...` или другой research-файл — прочитай его без вопроса;
@@ -234,11 +238,13 @@ Research подтягивай так:
 5. Найденные версии пакетов/ПО и источники, если задача требует установки.
 6. Пары «вопрос → ответ» из этапа 3 и подтверждения существенных решений из research.
 7. Ссылки на `docs/rules.md`, `docs/arch.md`, исследование (без пересказа — Plan Mode прочитает сам) и явное требование строго следовать правилам и архитектуре.
-8. Инструкция: «все вопросы пользователю — только по разделу "Интерактивные вопросы", никаких догадок и продолжения без ответа».
-9. Инструкция: «финальный план должен быть нормализован в обязательную структуру из этапа 5 и не должен смешивать исследование с планом исполнения».
-10. Инструкция: «зафиксированные стратегии тестов и логирования должны быть применены в плане, а не просто записаны в YAML».
-11. Инструкция: «если `plan_size: short`, соблюдай ограничения короткого плана из раздела "Размер плана"».
-12. Инструкция: «не добавляй неподтверждённые существенные решения в финальный план; если они возникли внутри 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, остановись и спроси пользователя».
 
 Не выходи, пока пользователь не подтвердил план.
 
@@ -341,6 +347,10 @@ sources:
 Перед сохранением проверь quality gate:
 - есть `Целевой алгоритм`;
 - есть `Контракты реализации` с подразделами `Данные и БД` и `API и внешние контракты`;
+- план строго следует `docs/rules.md` и `docs/arch.md`;
+- применимые правила и архитектурные ограничения учтены в решениях, фазах, тестах и проверках;
+- нет шагов, зависимостей, API, миграций, границ модулей или команд, которые противоречат `docs/rules.md` или `docs/arch.md`;
+- если найден конфликт с правилами или архитектурой, план не финализирован до ответа пользователя;
 - если задача затрагивает БД, схема данных не пропущена и не заменена общими словами;
 - если задача затрагивает API или внешний контракт, маршруты/контракты не пропущены и не заменены общими словами;
 - фазы идут в реалистичном порядке реализации;
@@ -429,6 +439,9 @@ claude -p "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, связа
 
 ## Чего НЕ делать
 - Править код, запускать миграции.
+- Считать `docs/rules.md` и `docs/arch.md` просто контекстом для ознакомления.
+- Исполнять или сохранять план, который противоречит правилам или архитектуре проекта.
+- Обходить правило или архитектурное ограничение без явного решения пользователя.
 - Задавать вопросы без блокировки и продолжать работу до ответа.
 - Переформулировать запрос пользователя своими словами перед Plan Mode.
 - Пропускать сохранение файла плана.