@gian-tiaga/eda 0.4.5 → 0.4.6

package/README.md

@@ -31,7 +31,7 @@ eda init
 | `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.5",
+  "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-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/`.
 - Оформлять замечания без контекста перед конкретикой.
+- Перечислять выполненные пункты плана или давать общий отчёт о проделанной работе.