@gian-tiaga/eda 0.4.4 → 0.4.5

package/README.md

@@ -27,7 +27,7 @@ eda init
 
 | Скил | Что делает | Куда складывает |
 |---|---|---|
-| `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки и риски, короткий выбранный вариант решения без плана. Если нужны пакеты или ПО — проверяет актуальные стабильные версии через context7 или web search | `docs/researches/` |
+| `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки, риски внутри решений и короткий выбранный вариант решения без плана. Если нужны пакеты или ПО — проверяет актуальные стабильные версии через context7 или web search | `docs/researches/` |
 | `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. Подтягивает контекст из `docs/rules.md`, `docs/arch.md`, при желании — релевантное исследование. Затем три параллельных модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить | `docs/plans/` |
 | `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
 | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или файлу плана. Перед правками читает правила и архитектуру, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/fixes/` |

package/package.json

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

package/skills/eda-explore.md

@@ -1,11 +1,11 @@
 ---
 name: eda-explore
-description: 'Исследует тему или задачу до конкретного результата: проясняет проблему, архитектуру, развилки, риски и короткий выбранный вариант решения без плана реализации. Работает read-only, задаёт блокирующие вопросы, когда без ответа нельзя выбрать решение, а существенные решения подтверждает по `defaults.decision_mode` из `docs/settings.yaml`. Если исследование касается пакетов, библиотек, CLI, сервисов или другого ПО, проверяет актуальные стабильные версии через context7, если он доступен, или через web search по официальным источникам. Итог сохраняет в docs/researches/. Кросс-ревью соседним агентом (Claude ↔ Codex) включается флагом `strict` или настройкой `defaults.strict: true` в `docs/settings.yaml`.'
+description: 'Исследует тему или задачу до конкретного результата: проясняет проблему, архитектуру, развилки, связанные риски и короткий выбранный вариант решения без плана реализации. Работает read-only, задаёт блокирующие вопросы, когда без ответа нельзя выбрать решение, а существенные решения подтверждает по `defaults.decision_mode` из `docs/settings.yaml`. Если исследование касается пакетов, библиотек, CLI, сервисов или другого ПО, проверяет актуальные стабильные версии через context7, если он доступен, или через web search по официальным источникам. Итог сохраняет в docs/researches/. Кросс-ревью соседним агентом (Claude ↔ Codex) включается флагом `strict` или настройкой `defaults.strict: true` в `docs/settings.yaml`.'
 ---
 
 # Скил: Исследователь решений (eda-explore)
 
-Проводишь исследование так, чтобы на выходе была не подборка рассуждений, а конкретная рамка для следующего шага: что за проблема, как устроена релевантная архитектура, какие решения приняты, какие риски закрыты и какой вариант решения выбран.
+Проводишь исследование так, чтобы на выходе была не подборка рассуждений, а конкретная рамка для следующего шага: что за проблема, как устроена релевантная архитектура, какие решения приняты, какие риски учтены в этих решениях и какой вариант решения выбран.
 
 ## Режимы вызова
 
@@ -55,12 +55,12 @@ description: 'Исследует тему или задачу до конкре
 1. **Никаких правок кода.** Запись только в `docs/researches/`.
 2. **Итог — конкретика.** Нельзя заканчивать абстрактными описаниями, списком возможностей или «можно выбрать один из вариантов».
 3. **Развилки закрывай по `decision_mode`.** Обычные локальные развилки можно выбрать по коду, правилам, архитектуре, источникам и рискам. Существенные решения в `recommend_and_ask` и `ask_each_time` подтверждай у пользователя до финализации. Если выбор зависит только от пользователя — задай блокирующий вопрос в любом режиме.
-4. **Риски закрывай.** Для каждого риска зафиксируй решение: mitigation, acceptance или out of scope. Нельзя оставлять риск просто перечисленным.
+4. **Риски вплетай в исследование.** Не создавай отдельный обязательный раздел или этап рисков. Если риск влияет на выбор, источник, ограничение или будущую проверку, фиксируй его рядом с соответствующим решением: что может пойти не так и как это учитывается — снимаем, принимаем или выносим за рамки.
 5. **Версии проверяй.** Если речь о пакетах, библиотеках, CLI, сервисах или другом ПО, а версия не задана контекстом, проверь последнюю стабильную версию через context7, если он доступен, или через web search по официальным источникам.
 6. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и используй их как рамку.
 7. **Каждое фактическое утверждение — со ссылкой** (`file.ext:42`, URL, коммит). Без ссылки — помечай как «гипотеза» и не делай её основанием выбранного решения.
 8. **Простой язык.** Термины — только когда без них нельзя, сразу с пояснением.
-9. **Таблицы > сплошной текст** для фактов, развилок, рисков и решений.
+9. **Таблицы > сплошной текст** для фактов, развилок, сравнений, версий и источников.
 
 ## Интерактивные вопросы
 
@@ -100,6 +100,7 @@ description: 'Исследует тему или задачу до конкре
 - перечисли варианты;
 - выбери один вариант или подготовь рекомендацию;
 - запиши источник и причину выбора;
+- если у варианта есть важный риск, опиши его здесь же и сразу зафиксируй, как он влияет на выбранное решение;
 - если развилка существенная и `decision_mode: recommend_and_ask` — задай `AskUserQuestion`: 2–3 варианта, первым рекомендованный, короткая причина рекомендации, вариант «свой вариант», фраза «Я продолжу только после ответа.»;
 - если развилка значимая и `decision_mode: ask_each_time` — задай `AskUserQuestion` даже при сильной рекомендации;
 - если `decision_mode: autonomous` и выбор можно обосновать кодом, правилами, архитектурой, источниками и рисками — выбери сам и запиши почему;
@@ -107,21 +108,13 @@ description: 'Исследует тему или задачу до конкре
 
 Не прячь существенный выбор внутри текста. Например, если нужен пакет для базы данных, сначала сравни 2–3 подходящих варианта, затем в `recommend_and_ask` спроси подтверждение выбора пакета/БД до записи финального решения.
 
-### 4. Закрыть риски
+Если по ходу исследования находится высокий риск без понятного решения, это блокер: задай `AskUserQuestion` или заверши со статусом `blocked`. Не выноси риски в отдельную секцию ради формы; они должны естественно лежать в `Решении`, причинах выбора, ограничениях, проверках версий или итоговом выводе.
 
-Для каждого риска зафиксируй:
-- что может пойти не так;
-- почему это важно;
-- выбранное решение: как снимаем, принимаем или выносим за рамки;
-- что это значит для будущего плана.
-
-Высокий риск без решения — блокер. Задай вопрос или заверши со статусом `blocked`.
-
-### 5. Собрать отчёт
+### 4. Собрать отчёт
 
 Сохрани отчёт в `docs/researches/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
 
-Формат отчёта должен быть компактным и универсальным: три основных раздела, без обязательного раздувания под каждый тип исследования. Таблицы, ASCII-диаграммы и дополнительные подпункты добавляй внутри этих разделов только когда они действительно помогают ясности.
+Формат отчёта должен быть компактным и универсальным: четыре основных раздела, без обязательного раздувания под каждый тип исследования. Таблицы, ASCII-диаграммы и дополнительные подпункты добавляй внутри этих разделов только когда они действительно помогают ясности.
 
 ```markdown
 ---
@@ -145,7 +138,8 @@ sources:
 Описание выбранного решения. Внутри этого раздела, если нужно, добавь:
 - описание релевантной архитектуры;
 - ASCII-диаграммы;
-- таблицы фактов, развилок, рисков, версий пакетов/ПО и источников;
+- таблицы фактов, развилок, версий пакетов/ПО и источников;
+- риски рядом с теми решениями, ограничениями или проверками, на которые они влияют;
 - объяснение, почему выбран этот вариант, а не альтернативы.
 
 ## Ответы на вопросы
@@ -163,13 +157,14 @@ Quality gate перед сохранением:
 - в `Ответы на вопросы` записаны все вопросы, заданные пользователю в процессе исследования, и ответы на них, чтобы `eda-plan` не задавал их повторно;
 - в `Итог` есть короткая конкретика, что делать дальше на уровне подхода, без пошагового плана;
 - нет незакрытых развилок;
-- нет рисков без решения;
+- нет рисков, которые перечислены отдельно от решения и никак не влияют на выбор, ограничения или будущие проверки;
+- нет высокого риска без понятного решения;
 - версии пакетов/ПО проверены или объяснено, почему это не требуется;
 - ключевые утверждения имеют источники.
 
-### 6. Кросс-ревью — только в `strict`
+### 5. Кросс-ревью — только в `strict`
 
-Обычный режим — пропусти этапы 6–7, иди на финал. `reviewer: none`, `status: draft`.
+Обычный режим — пропусти этапы 5–6, иди на финал. `reviewer: none`, `status: draft`.
 
 В `strict`: отдай файл соседнему агенту через `Bash` и сформулируй задание как глубокую проверку конкретности, фактов, развилок и рисков.
 
@@ -187,11 +182,11 @@ claude -p "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md при
 
 CLI нет — `AskUserQuestion`: продолжать без ревью или прервать.
 
-### 7. Допилить по ревью — только в `strict`
+### 6. Допилить по ревью — только в `strict`
 
 Бесспорные замечания → правь. Спорные → `AskUserQuestion`. Отклонённые → оставь с причиной. В конец отчёта добавь раздел `## Реакция на ревью` (Принято / Отклонено / Спорное). `status: reviewed`. Покажи дифф.
 
-### 8. Финал
+### 7. Финал
 
 Короткое сообщение: режим, путь к отчёту, путь к ревью (если `strict`), 3–5 конкретных выводов, выбранный вариант решения одной строкой. Не предлагай «исследовать дальше», если нет блокера.
 

package/skills/eda-plan.md

@@ -302,21 +302,17 @@ sources:
 
 ## Документация и эксплуатация
 Что обновить в env/docs/runbook и что важно для релиза.
-
-## Риски
-Риски и конкретное снижение каждого риска.
-
-## Порядок выполнения
-Краткий линейный список действий для исполнителя.
 ```
 
 Правила структуры:
 - В `Контекст` попадают исследовательские наблюдения и ограничения.
 - В `Принятые решения` попадают только выбранные решения, без альтернатив.
+- Риски не выносятся в отдельный обязательный раздел. Закрытые риски из research, контекста и мета-ревью должны быть встроены туда, где они исполняются: в `Принятые решения`, фазы, сценарии тестирования, проверки, логирование или эксплуатационные шаги.
 - Существенные решения в `Принятых решениях` имеют источник подтверждения или явное обоснование автономного выбора.
 - В `Целевой алгоритм` попадает сквозная картина процесса.
 - В `Фазы выполнения` попадают только исполнимые шаги.
 - Каждая фаза обязана иметь `Цель`, `Что сделать`, `Результат`, `Сценарии тестирования`, `Проверка`.
+- Отдельный раздел порядка выполнения не нужен: линейный порядок задаётся номерами фаз и шагами внутри фаз.
 - `test_strategy` обязан менять структуру фаз: TDD — тесты в начале фаз, after_each_phase — тесты после каждой фазы, end_of_plan — отдельная финальная фаза тестов.
 - `logging_strategy` обязан быть отражён в целевом алгоритме, фазах и отдельном разделе `Логирование`.
 - Для `plan_size: short` фаз должно быть не больше 2, а ожидаемый объём должен быть явно указан в `Принятых решениях`.
@@ -332,7 +328,7 @@ sources:
 - мета-уровень не смешан с шагами исполнения;
 - стратегия тестов зафиксирована в разделе `Тесты` и последовательно применена в фазах, сценариях тестирования и проверках;
 - стратегия логирования зафиксирована и последовательно применена в алгоритме, фазах и разделе `Логирование`;
-- тесты связаны с ключевыми сценариями и рисками;
+- тесты связаны с ключевыми сценариями и закрытыми рисками из research/контекста, если такие риски есть;
 - если `plan_size: short`, фаз не больше 2, ожидаемый объём укладывается в ориентиры short или исключение явно объяснено;
 - все пакеты/ПО, которые нужно установить, имеют конкретные версии или явное объяснение, почему версия берётся из существующего lock/config-файла;
 - нет неподтверждённых существенных решений при `decision_mode: recommend_and_ask` или `decision_mode: ask_each_time`;
@@ -362,7 +358,7 @@ sources:
 
 Базовый формат ответа для всех: `+ N | − N | ~ N: причина`, без воды. Для мощной модели добавь явную инструкцию: «Если план ссылается на модуль, API, тесты или сценарий, открой соответствующие файлы и проверь фактическую структуру проекта.»
 
-Когда все три ответили — прочитай ответы, **сам реши**, что применять (не вставляй чужие пункты механически). Принятые замечания сначала интегрируй в основные разделы плана: решения, алгоритм, фазы, тесты, риски. Не оставляй важные требования только в changelog.
+Когда все три ответили — прочитай ответы, **сам реши**, что применять (не вставляй чужие пункты механически). Принятые замечания сначала интегрируй в основные разделы плана: решения, алгоритм, фазы, тесты, логирование, документацию и эксплуатацию. Не оставляй важные требования только в changelog.
 
 После интеграции снова прогони quality gate из этапа 5. Затем допиши в конец короткий раздел: