@gian-tiaga/eda 0.8.5 → 0.8.6

package/README.md

@@ -47,7 +47,7 @@ eda update-all ~/Code
 | `eda-fix-by-review` | Применяет замечания из ревью. Обязательные — все сразу. Optional-пункты в обычном режиме спрашивает, а в `apply-optional` сам решает: применяет полезные, отклонённые обосновывает в отчёте. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |
 | `eda-manual-test` | Делает ручную smoke/acceptance-проверку после изменений: API прогоняет через `curl`/HTTP-запросы, фронт — через Playwright или доступную browser automation. Сам строит чеклист из входа, плана или diff, запускает очевидные dev/API-серверы и сохраняет QA-отчёт. Не правит код, не пишет автотесты и не коммитит | `docs/manual-tests/` |
 | `eda-polish` | Оркестрирует доводку изменений: запускает `eda-review draft`, затем `eda-review-check`, затем `eda-fix-by-review apply-optional` и повторяет цикл до оценки 95/100 или лимита 5 итераций. Обязательные замечания чинятся все, optional-пункты fix-агент применяет или отклоняет сам с обоснованием. Каждый шаг идёт в изолированном субагенте или отдельном CLI-процессе. Не коммитит | `docs/reviews/`, `docs/review-fixes/` |
-| `eda-send-review` | Отправляет ревью на GitHub PR через `gh` — как комментарий, review, approve или request-changes. Сам определяет PR по текущей ветке | (комментарий в PR) |
+| `eda-send-review` | Отправляет ревью на GitHub PR через `gh` всегда в едином формате: общий комментарий-сводка плюс комментарии к строкам кода. Тип (`comment`/`approve`/`request-changes`) задаёт только статус review; `approve` и `request-changes` подтверждаются. По умолчанию шлёт все пункты. Сам определяет PR по текущей ветке | (комментарий в PR) |
 | `eda-commit` | Делает один аккуратный коммит в стиле проекта. В конце спрашивает: push, merge в main + удалить ветку, или ничего | (git) |
 | `eda-worktree` | Создаёт git worktree рядом с основным проектом в папке `{name}-work-{n}` и одноимённую ветку. Базу берёт из аргумента или спрашивает | соседняя папка `{name}-work-{n}` |
 | `eda-merge-worktree` | Мержит ветку из соседнего worktree в текущую ветку. Принимает номер `1`, короткое имя `work-1` или полное имя `{name}-work-1`. Worktree и ветку после merge не удаляет | (git) |

package/lib/install.js

@@ -165,7 +165,7 @@ export async function updateAll({
     output.write(`\n=== ${projectLabel} ===\n`);
 
     try {
-      const targets = await detectTargets(projectDir);
+      const targets = await detectInstalledTargets(projectDir);
       if (targets.length === 0) {
         output.write('Пропускаю: установленные среды исчезли во время обхода.\n');
         skippedProjects.push(projectDir);
@@ -295,6 +295,28 @@ async function detectTargets(cwd) {
   return targets;
 }
 
+// Среда считается установленной, только если в её папке скилов лежит хотя бы один eda-скил.
+// Используется при массовом обходе (update-all), чтобы не засыпать скилами проекты,
+// где папка .claude/skills или .codex/skills есть, но eda-скилов в ней нет.
+async function detectInstalledTargets(cwd) {
+  const targets = [];
+  if (await hasInstalledSkill(path.join(cwd, '.claude/skills'))) targets.push('claude');
+  if (await hasInstalledSkill(path.join(cwd, '.codex/skills'))) targets.push('codex');
+  return targets;
+}
+
+async function hasInstalledSkill(skillsDir) {
+  let entries;
+  try {
+    entries = await fs.readdir(skillsDir, { withFileTypes: true });
+  } catch (err) {
+    if (['ENOENT', 'ENOTDIR', 'EACCES', 'EPERM'].includes(err?.code)) return false;
+    throw err;
+  }
+  // eda-скилы лежат как папка eda-* (новый layout) или файл eda-*.md (старый Codex layout).
+  return entries.some(entry => entry.name.startsWith('eda-'));
+}
+
 async function syncSkills(cwd, targets, output = process.stdout, { action = 'update', writeDone = true } = {}) {
   const skills = await listSkills();
   if (skills.length === 0) {
@@ -326,7 +348,7 @@ async function findInstalledProjects(rootDir, maxDepth) {
   const projects = [];
 
   async function walk(dir, depth) {
-    const targets = await detectTargets(dir);
+    const targets = await detectInstalledTargets(dir);
     if (targets.length > 0) projects.push(dir);
     if (depth >= maxDepth) return;
 

package/package.json

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

package/skills/eda-send-review.md

@@ -1,25 +1,27 @@
 ---
 name: eda-send-review
-description: 'Отправляет ревью из `docs/reviews/...`, выбранное по тексту рядом с вызовом, на GitHub PR через `gh` — как review (comment/approve/request-changes) или как обычный комментарий. Перед отправкой читает `docs/rules.md` и `docs/arch.md` и строго следует им. Целевой PR определяется из текста или автоматически по текущей ветке; если PR нет — предлагает создать. После отправки в конец файла ревью дописывает ссылку на PR-комментарий. Не правит код, не делает само ревью. Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
+description: 'Отправляет ревью из `docs/reviews/...`, выбранное по тексту рядом с вызовом, на GitHub PR через `gh` — всегда в едином формате: общий комментарий-сводка плюс комментарии к строкам кода (inline). Тип отправки (`comment`/`approve`/`request-changes`) задаёт только статус review, но не структуру вывода. По умолчанию отправляет все пункты; если в тексте указано подмножество — только его. Перед отправкой читает `docs/rules.md` и `docs/arch.md` и строго следует им. Целевой PR определяется из текста или по текущей ветке; если PR нет — предлагает создать. После отправки в конец файла ревью дописывает ссылку. Не правит код, не делает само ревью. Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
 ---
 
 # Скил: Отправитель ревью (eda-send-review)
 
-Берёшь готовое ревью из `docs/reviews/`, отправляешь его на GitHub PR через `gh`. В конец файла ревью дописываешь, куда отправил.
+Берёшь готовое ревью из `docs/reviews/`, отправляешь его на GitHub PR через `gh`. Отправляешь **всегда в одном формате**: общий комментарий-сводка плюс комментарии к строкам кода. В конец файла ревью дописываешь, куда отправил.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения, какие пункты отправлять и прямые указания.
 
 Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
 
 ## Главные правила
 
-1. **Интерактивные вопросы** — по разделу ниже.
-2. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им при выборе способа отправки и финальной отметке.
-3. **Не правишь код, не делаешь само ревью.** Только переупаковка и отправка.
-4. **Никаких самостоятельных оценок.** Тип отправки определяется на основе ревью и текста пользователя. `comment` означает обычный комментарий PR, `review-comment` — review без статуса. `approve` и `request-changes` всегда подтверждаются пользователем.
-5. **Простой язык.** В сообщениях пользователю и комментарии PR без лишних терминов.
+1. **Единый формат всегда.** Отправляешь как GitHub review: тело — общий комментарий-сводка, а каждое замечание с привязкой к строке — отдельным комментарием к строке кода (inline). Тип отправки меняет только статус review (`event`), но не структуру вывода.
+2. **По умолчанию — все пункты.** Если пользователь не указал, что отправлять, отправляешь все замечания ревью. Если указал подмножество — только его.
+3. **Интерактивные вопросы** — по разделу ниже.
+4. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им при выборе способа отправки и финальной отметке.
+5. **Не правишь код, не делаешь само ревью.** Только переупаковка и отправка.
+6. **Никаких самостоятельных оценок.** Статус review определяется по оценке ревью и тексту пользователя. `approve` и `request-changes` всегда подтверждаются пользователем.
+7. **Простой язык.** В сообщениях пользователю и комментариях PR без лишних терминов.
 
 ## Интерактивные вопросы
 
@@ -28,61 +30,82 @@ description: 'Отправляет ревью из `docs/reviews/...`, выбр
 - Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
 - Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
 - Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-- Для отправки ревью это правило важнее продолжения: не создавай PR, не отправляй approve/request-changes и не меняй тип отправки вместо ответа пользователя.
+- Для отправки ревью это правило важнее продолжения: не создавай PR, не отправляй approve/request-changes и не меняй статус отправки вместо ответа пользователя.
 
 ## Этапы
 
 ### 1. Проверить инструменты
 `gh --version` + `gh auth status`. Если `gh` отсутствует или не авторизован — остановись, сообщи и выйди (это пользователю нужно решить).
 
-### 2. Выбрать ревью
-Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», PR (`PR 12`, `#12`) и тип отправки (`comment`, `review-comment`, `approve`, `request-changes`).
+### 2. Выбрать ревью и что отправлять
+Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», PR (`PR 12`, `#12`) и статус отправки (`comment`, `review-comment`, `approve`, `request-changes`).
 
 Если найдено ровно одно ревью — продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста — остановись с понятным вопросом или статусом `blocked: нужно ревью`. Прочитай файл целиком: оценку, замечания, рекомендации.
 
+**Что отправлять.** По умолчанию — все замечания. Если в тексте указано подмножество, отправь только его. Синтаксис свободный, распознавай по смыслу: по номерам («пункты 1, 3, 5»), по обязательности («только обязательные» → раздел «Править обязательно»), по типу («только security» → замечания с этим `Тип`). Выбор влияет и на сводку, и на комментарии к строкам.
+
 ### 3. Найти целевой PR
 Если номер PR указан в тексте пользователя — используй его. Иначе попробуй `gh pr view --json number,url,headRefName` — если у текущей ветки уже есть PR, возьми его номер.
 
 Если PR нет — `AskUserQuestion`: «PR ещё нет: создать PR из текущей ветки / указать номер существующего PR / прервать». При создании используй `gh pr create` (заголовок и тело — по последним коммитам ветки).
 
-### 4. Выбрать тип отправки
-Предложи вариант по оценке: score ≥ 80 → **approve** с комментарием; score < 50 → **request-changes**; иначе → **review-comment**.
+### 4. Выбрать статус review
+Review отправляется всегда; здесь выбирается только его статус (`event`).
+
+| Условие | event | Подтверждение |
+|---|---|---|
+| score ≥ 80 (или в тексте `approve`) | `APPROVE` | всегда `AskUserQuestion` |
+| score < 50 (или в тексте `request-changes`) | `REQUEST_CHANGES` | всегда `AskUserQuestion` |
+| иначе (или в тексте `comment` / `review-comment`) | `COMMENT` | без подтверждения |
+
+`comment` и `review-comment` означают review без статуса (`event=COMMENT`) — обычный комментарий-ревью, который тоже несёт сводку и комментарии к строкам. `approve` и `request-changes` подтверждай через `AskUserQuestion` всегда, даже если указаны в тексте. Если предложенный статус противоречит ревью — `AskUserQuestion`: подтвердить / выбрать другой.
 
-Если тип отправки указан в тексте и это `comment` или `review-comment`, используй его без дополнительного выбора, если нет противоречий с ревью. `approve` и `request-changes` всегда подтверждай через `AskUserQuestion`, даже если они указаны inline. Если тип не указан или противоречит ревью — `AskUserQuestion`: подтвердить предложенный тип / выбрать другой / отправить как обычный комментарий PR (вне review).
+### 5. Собрать сводку и комментарии к строкам
+Из выбранных пунктов собери две части.
 
-### 5. Сформировать тело
-Структура комментария:
+**Сводка** — тело review:
 
 ```markdown
 ## Ревью: <заголовок>
 
 **Оценка:** N/100. <одно-два предложения почему>
 
-### Замечания
-1. **[тип]** `path/file.py:42` — <что не так>. → <что предлагаешь>
-2. ...
+<короткое резюме: что отправлено и общий вывод>
 
 ### Рекомендации
 - **Править обязательно:** 1, 3, 5
 - **На усмотрение автора:** 2, 4
-- **Не править:** —
+
+### Замечания вне diff
+1. **[тип]** `path/file.py:42` — <что не так>. → <что предлагаешь>
 
 _Сгенерировано из `<путь к docs/reviews/...>`_
 ```
 
+Раздел «Замечания вне diff» добавляй только если такие пункты есть (см. ниже); иначе опусти его.
+
+**Комментарии к строкам** — по одному на каждое отправляемое замечание, чьё `Где: path:line` входит в diff PR. Для каждого: `{ "path": "<path>", "line": <line>, "side": "RIGHT", "body": "<суть простым языком + рекомендация + как исправить>" }`. Для замечания об удалённой строке используй `"side": "LEFT"`.
+
+Какие строки входят в diff — определи по `gh pr diff <num>`. Замечания, чьи строки в diff не попали (или без `path:line`), в комментарии к строкам **не** клади — перенеси их в раздел «Замечания вне diff» сводки, чтобы ничего не потерялось.
+
 ### 6. Отправить
-По выбранному типу:
+Тело сводки и комментарии собери в один JSON через `mktemp`:
 
-| Тип | Команда |
-|---|---|
-| comment (PR comment) | `gh pr comment <num> --body-file <tmpfile>` |
-| review-comment | `gh pr review <num> --comment --body-file <tmpfile>` |
-| approve | `gh pr review <num> --approve --body-file <tmpfile>` |
-| request-changes | `gh pr review <num> --request-changes --body-file <tmpfile>` |
+```json
+{ "body": "<сводка>", "event": "COMMENT|APPROVE|REQUEST_CHANGES", "comments": [ { "path": "...", "line": 42, "side": "RIGHT", "body": "..." } ] }
+```
+
+Отправь одним вызовом Reviews API:
 
-Тело пиши во временный файл (`mktemp`) и передавай через `--body-file` — иначе спецсимволы и переносы поедут не туда.
+```bash
+OWNER_REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
+gh api "repos/$OWNER_REPO/pulls/<num>/reviews" --method POST --input <payload.json>
+```
 
-Если команда упала — покажи вывод пользователю и спроси через `AskUserQuestion` (повторить / другой тип / прервать).
+Fallback'ы:
+- API упал с `422` из-за конкретных строк — перенеси эти пункты в раздел «Замечания вне diff» сводки и переотправь без них.
+- У цели нет diff/строк PR вовсе (нечего привязывать) — отправь только сводку обычным комментарием: `gh pr comment <num> --body-file <tmpfile>`.
+- Другая ошибка — покажи вывод пользователю и спроси через `AskUserQuestion` (повторить / другой статус / прервать).
 
 ### 7. Дописать ссылку в файл ревью
 В конец `$REVIEW_FILE` добавь:
@@ -90,16 +113,19 @@ _Сгенерировано из `<путь к docs/reviews/...>`_
 ```markdown
 ## Отправлено
 - PR: <URL из ответа gh>
-- Тип: <comment | review-comment | approve | request-changes>
+- Статус: <comment | approve | request-changes>
+- Отправлено пунктов: <сколько / inline + сколько в сводке>
 - Дата: <YYYY-MM-DD HH:MM>
 ```
 
 ### 8. Финал
-Короткое сообщение: PR-номер и URL, тип отправки, путь к файлу ревью.
+Короткое сообщение: PR-номер и URL, статус отправки, сколько пунктов ушло комментариями к строкам и сколько в сводку, путь к файлу ревью.
 
 ## Чего НЕ делать
 - Делать само ревью или править замечания — это `eda-review` / `eda-fix-by-review`.
-- Отправлять `approve` без явного подтверждения через `AskUserQuestion`, даже если оценка ≥ 80.
-- Передавать тело комментария через `-b "..."` со спецсимволами без `--body-file` — поломает форматирование.
+- Отправлять всё одним обычным комментарием PR, когда строки можно привязать к diff — обычный комментарий только fallback при отсутствии diff.
+- Терять замечания вне diff — они идут в сводку отдельным разделом.
+- Отправлять `approve` или `request-changes` без явного подтверждения через `AskUserQuestion`, даже если оценка ≥ 80.
+- Передавать тело через `-b "..."` со спецсимволами — только `--input` (Reviews API) или `--body-file` (fallback).
 - Создавать PR молча, если его нет — только через `AskUserQuestion`.
 - Сохранять копии отправленного в отдельные файлы — связь через ссылку в файле ревью.