@gian-tiaga/eda 0.4.4 → 0.4.6

package/README.md

@@ -27,11 +27,11 @@ 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/` |
-| `eda-review` | Делает код-ревью с оценкой 0–100 и сверкой с планом работ. Замечания пишет блоками: сначала контекст и риск, потом конкретные файлы/строки и шаги исправления. Затем параллельные специализированные агенты проверяют выполнение плана, архитектуру, правила и при включённой настройке качество кода. В строгом режиме — ещё и кросс-ревью между Claude и Codex | `docs/reviews/` |
+| `eda-review` | Делает код-ревью с оценкой 0–100 и сверкой с планом работ, но в файл пишет только проблемы: ошибки, недоделки, неточности, нарушения правил/архитектуры, риски и недостающие тесты. Не перечисляет выполненную работу. Затем параллельные специализированные агенты проверяют выполнение плана, архитектуру, правила и при включённой настройке качество кода. В строгом режиме — ещё и кросс-ревью между Claude и Codex | `docs/reviews/` |
 | `eda-fix-by-review` | Применяет замечания из ревью. Обязательные — сразу. Спорные — спрашивает. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |
 | `eda-send-review` | Отправляет ревью на GitHub PR через `gh` — как комментарий, review, approve или request-changes. Сам определяет PR по текущей ветке | (комментарий в PR) |
 | `eda-commit` | Делает один аккуратный коммит в стиле проекта. В конце спрашивает: push, merge в main + удалить ветку, или ничего | (git) |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "0.4.4",
+  "version": "0.4.6",
   "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. Затем допиши в конец короткий раздел:
 

package/skills/eda-review.md

@@ -1,11 +1,11 @@
 ---
 name: eda-review
-description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл) с обязательной сверкой с планом работ из `docs/plans/`. Если план не указан и его нельзя однозначно определить, спрашивает путь к плану до ревью. Перед ревью читает `docs/rules.md` и `docs/arch.md`. Формирует ревью по Markdown-шаблону из этапа 2: с блоками «контекст», «риск», «где», «детали», «как исправить» и пустой строкой между каждым блоком. Сохраняет в docs/reviews/. Всегда запускает параллельные специализированные проверки: выполнение плана, следование архитектуре, следование правилам; проверка качества кода включается настройкой `review.include_code_quality: true` в `docs/settings.yaml`. Кросс-CLI (Claude ↔ Codex) включается флагом `strict` или настройкой `defaults.strict: true`. Не правит код — это `eda-fix-by-review`.'
+description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл) с обязательной сверкой с планом работ из `docs/plans/`. Если план не указан и его нельзя однозначно определить, спрашивает путь к плану до ревью. Перед ревью читает `docs/rules.md` и `docs/arch.md`. Формирует ревью только по проблемам: ошибки, недоделки, неточности, нарушения правил/архитектуры, риски и недостающие тесты. Не перечисляет выполненную работу. Сохраняет в docs/reviews/. Всегда запускает параллельные специализированные проверки: выполнение плана, следование архитектуре, следование правилам; проверка качества кода включается настройкой `review.include_code_quality: true` в `docs/settings.yaml`. Кросс-CLI (Claude ↔ Codex) включается флагом `strict` или настройкой `defaults.strict: true`. Не правит код — это `eda-fix-by-review`.'
 ---
 
 # Скил: Ревьюер (eda-review)
 
-Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь замечания, ставишь оценку, сохраняешь файл. Затем проверяешь ревью параллельными специализированными агентами; в `strict` — ещё и через соседний CLI. После каждой проверки **сам корректируешь** своё ревью: что-то добавляешь, что-то убираешь, что-то переформулируешь.
+Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь только найденные проблемы, ставишь оценку, сохраняешь файл. Не перечисляешь, что выполнено хорошо или без замечаний. Затем проверяешь ревью параллельными специализированными агентами; в `strict` — ещё и через соседний CLI. После каждой проверки **сам корректируешь** своё ревью: что-то добавляешь, что-то убираешь, что-то переформулируешь.
 
 ## Режимы вызова
 
@@ -39,8 +39,9 @@ description: 'Ревью изменений (незакоммиченный diff
 5. **Мета-ревью специализированными агентами — обязательно**, без флага: проверка выполнения плана, проверка архитектуры, проверка правил. Если включена проверка качества кода — добавь `quality-check` тем же batch. Кросс-CLI — только в `strict`.
 6. **Главный ревьюер — ты.** Мета-ревьюеры дают подсказки; решение — добавить, убрать или оставить пункт — за тобой. Не вставляй чужие пункты механически.
 7. **Простой язык** в формулировках замечаний и рекомендаций. Технические термины — только если без них нельзя, и сразу с пояснением.
-8. **Формат файла ревью — Markdown-блоки по шаблону из этапа 2.** Сверку с планом, каждое замечание и рекомендации пиши отдельными блоками с подзаголовками. Между заголовком блока, статусом/типом, контекстом, риском, локациями, деталями и исправлением всегда оставляй одну пустую строку.
-9. **В каждом замечании сначала объясняй контекст без привязки к коду**, чтобы читатель понял проблему и риск. Только после этого давай конкретные файлы/строки. Исправление оформляй так же: сначала общий подход, затем конкретные шаги по коду.
+8. **Ревью содержит только проблемы.** Не пиши отчёт о выполненной работе, список успешно сделанных пунктов, похвалу или нейтральное перечисление изменений. В файл попадают только ошибки, недоделки, неточности, спорные решения, нарушения правил/архитектуры, риски и недостающие проверки. Если проблем нет, напиши коротко: «Явных проблем не найдено», без пересказа diff.
+9. **Формат файла ревью — Markdown-блоки по шаблону из этапа 2.** Проблемы сверки с планом, каждое замечание и рекомендации пиши отдельными блоками с подзаголовками. Между заголовком блока, статусом/типом, контекстом, риском, локациями, деталями и исправлением всегда оставляй одну пустую строку.
+10. **В каждом замечании сначала объясняй контекст без привязки к коду**, чтобы читатель понял проблему и риск. Только после этого давай конкретные файлы/строки. Исправление оформляй так же: сначала общий подход, затем конкретные шаги по коду.
 
 ## Интерактивные вопросы
 
@@ -75,11 +76,11 @@ description: 'Ревью изменений (незакоммиченный diff
 Если в diff видно отсылки к исследованию из `docs/researches/` — прочитай его тоже.
 
 ### 2. Сделать первичное ревью и сохранить
-Пройдись по изменениям. Сначала проверь, выполнен ли `$PLAN_FILE`: что сделано, что сделано частично, что не сделано, какие отклонения создают риск. Затем проверь нарушения правил, архитектуры, баги, тестовые пробелы, безопасность, производительность и документацию. Если `review.include_code_quality: true` или пользователь явно попросил качество кода, отдельно проверь качество реализации: читаемость, сложность, дублирование, имена, границы ответственности, связность модулей, поддерживаемость и соответствие стилю уже существующего кода.
+Пройдись по изменениям. Сначала проверь, выполнен ли `$PLAN_FILE`, но в ревью выноси только проблемы: что сделано частично, что не сделано, какие отклонения создают риск, какие проверки отсутствуют. Не перечисляй выполненные пункты плана. Затем проверь нарушения правил, архитектуры, баги, тестовые пробелы, безопасность, производительность и документацию. Если `review.include_code_quality: true` или пользователь явно попросил качество кода, отдельно проверь качество реализации: читаемость, сложность, дублирование, имена, границы ответственности, связность модулей, поддерживаемость и соответствие стилю уже существующего кода.
 
 Каждое замечание должно быть самостоятельным блоком:
 - заголовок с номером и коротким смыслом;
-- тип и рекомендация: `править обязательно`, `на усмотрение автора` или `не править`;
+- тип и рекомендация: `править обязательно` или `на усмотрение автора`;
 - контекст: объяснение проблемы без привязки к конкретному коду;
 - риск: почему это важно для поведения, сопровождения, денег, безопасности или эксплуатации;
 - где: конкретные файлы/строки;
@@ -108,24 +109,31 @@ meta_reviewers: []
 
 **<N>/100.** <одно-два предложения почему>
 
-## Сверка с планом
+## Проблемы сверки с планом
 
-### 1. <пункт или этап плана>
+<Если проблем по плану нет: «Явных проблем по плану не найдено.»>
 
-Статус: <выполнено | частично | не выполнено | не проверялось>
+### 1. <недоделка, отклонение или непроверенный пункт>
+
+Статус: <частично | не выполнено | не проверялось | отклонение>
 
 Контекст:
 <что требовал план простыми словами, без привязки к коду>
 
-Итог:
-<что фактически сделано или не сделано>
+Проблема:
+<что не сделано, сделано неточно или не подтверждено>
 
-Конкретика:
+Риск:
+<почему это важно>
 
-- `<path/file.ts:42>` — <короткое подтверждение>
+Где:
+
+- `<path/file.ts:42>` — <что смотреть>
 
 ## Замечания
 
+<Если замечаний нет: «Явных проблем в коде не найдено.»>
+
 ### 1. <короткий заголовок проблемы>
 
 Тип: `bug`
@@ -157,7 +165,6 @@ meta_reviewers: []
 
 - **Править обязательно:** <номера>
 - **На усмотрение автора:** <номера>
-- **Не править:** <номера или —>
 
 ## Изменения после мета-ревью
 
@@ -183,14 +190,14 @@ meta_reviewers: []
 Каждому дай путь к файлу ревью, `$TARGET`, `$PLAN_FILE`, `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml`, связанный research при наличии. Каждый агент должен читать не только ревью, но и фактический diff/код, достаточный для проверки своей роли.
 
 Формат ответа агентов:
-- `+` что добавить в ревью;
+- `+` какую проблему добавить в ревью;
 - `−` что убрать как неверное или недоказанное;
 - `~` что переформулировать;
 - `?` что невозможно проверить и почему.
 
 Для `plan-check` добавь явную инструкцию: «Если `$PLAN_FILE` не передан или файл не найден, верни только `? план не проверен: нужен путь к файлу`; не пытайся угадывать план.»
 
-Когда все агенты ответили: прочитай ответы, **сам реши**, что применять. Внеси правки в файл ревью. В разделе `## Изменения после мета-ревью` запиши:
+Когда все агенты ответили: прочитай ответы, **сам реши**, что применять. Добавляй только подтверждённые проблемы; предложения вида «добавить, что пункт выполнен» отклоняй как неформат ревью. Внеси правки в файл ревью. В разделе `## Изменения после мета-ревью` запиши:
 
 ```markdown
 ### После plan-check / architecture-check / rules-check / quality-check
@@ -208,13 +215,13 @@ meta_reviewers: []
 В `strict`: отдай файл соседнему агенту через `Bash`. Если ты в Claude Code — запускай Codex CLI:
 
 ```bash
-codex exec "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, docs/arch.md, связанный research при наличии. Затем глубоко проверь ревью по плану, правилам, архитектуре и релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: что добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Формат: '+', '−', '~', '?'." > "${REVIEW_FILE%.md}_cli_meta.md"
+codex exec "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, docs/arch.md, связанный research при наличии. Затем глубоко проверь ревью по плану, правилам, архитектуре и релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: какие проблемы добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Не предлагай перечислять выполненную работу. Формат: '+', '−', '~', '?'." > "${REVIEW_FILE%.md}_cli_meta.md"
 ```
 
 Если ты в Codex — запускай Claude CLI с теми же требованиями глубины:
 
 ```bash
-claude -p "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, docs/arch.md, связанный research при наличии. Затем глубоко проверь ревью по плану, правилам, архитектуре и релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: что добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Формат: '+', '−', '~', '?'." > "${REVIEW_FILE%.md}_cli_meta.md"
+claude -p "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, docs/arch.md, связанный research при наличии. Затем глубоко проверь ревью по плану, правилам, архитектуре и релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: какие проблемы добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Не предлагай перечислять выполненную работу. Формат: '+', '−', '~', '?'." > "${REVIEW_FILE%.md}_cli_meta.md"
 ```
 
 Соседней CLI нет — `AskUserQuestion`: завершить как есть или прервать.
@@ -231,7 +238,7 @@ claude -p "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, do
 Добавь в `meta_reviewers` имя CLI. `status: meta-reviewed` → `final`.
 
 ### 5. Финал
-Короткое сообщение: режим (`normal` или `strict`), путь к файлу ревью, итоговая оценка, сколько пунктов «править обязательно» / «на усмотрение» / «не править». Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-review strict`». Что предлагаешь дальше — `eda-fix-by-review` для применения или `eda-commit` если оценка приемлема.
+Короткое сообщение: режим (`normal` или `strict`), путь к файлу ревью, итоговая оценка, сколько пунктов «править обязательно» / «на усмотрение». Не пересказывай выполненную работу. Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-review strict`». Что предлагаешь дальше — `eda-fix-by-review` для применения или `eda-commit` если оценка приемлема.
 
 ## Чего НЕ делать
 - Править код. Это `eda-fix-by-review`.
@@ -242,3 +249,4 @@ claude -p "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, do
 - Задавать вопросы без блокировки и продолжать работу до ответа.
 - Сохранять ревью куда-либо кроме `docs/reviews/`.
 - Оформлять замечания без контекста перед конкретикой.
+- Перечислять выполненные пункты плана или давать общий отчёт о проделанной работе.