@gian-tiaga/eda 2.0.0 → 2.1.0

package/skills/eda-plan-review-fix/SKILL.md

@@ -1,30 +1,15 @@
 ---
 name: eda-plan-review-fix
-description: 'Исправляет готовый план по сохранённому plan-review и фиксирует решения по findings.'
+description: 'Исправляет готовый план по всем находкам сохранённого plan-review.'
 ---
 
 # Скил: Исправитель плана по ревью (eda-plan-review-fix)
 
-Применяй подтверждённые findings из `docs/plan-reviews/` только к связанному плану. Не делай новое ревью: твой контракт — точечно изменить основные разделы плана и сохранить проверяемую цепочку SHA-256.
+Применяй подтверждённые находки из `docs/plan-reviews/` только к связанному плану. Не делай новое ревью: твой контракт — точечно изменить основные разделы плана и сохранить проверяемую цепочку SHA-256.
 
 ## Вход из сообщения пользователя
 
-Разбери путь или название review, «последнее ревью», режим `apply-optional`, ограничения и явные решения по ID. Если вход однозначен, продолжай без вопроса. При нескольких равных review или противоречивом target используй `AskUserQuestion`.
-
-## Режимы
-
-Обычный режим:
-
-- все required применяй без дополнительного подтверждения;
-- optional собери в один-два раунда `AskUserQuestion`;
-- waived и отклонённые findings не применяй.
-
-`apply-optional`:
-
-- все required применяй;
-- optional применяй, если правка конкретна, обратима, остаётся в scope и улучшает исполнимость;
-- иначе пометь optional как `waived` с конкретной причиной;
-- продуктовое решение, конфликт с business/rules/architecture или расширение scope всё равно требует пользователя.
+Разбери путь или название review, «последнее ревью», ограничения и явные решения пользователя. Если вход однозначен, продолжай без вопроса. При нескольких равных review или противоречивом target используй `AskUserQuestion`.
 
 ## Вопросы
 
@@ -37,20 +22,21 @@ description: 'Исправляет готовый план по сохранён
 1. Работай только с review из `docs/plan-reviews/` и его `plan` из `docs/plans/`.
 2. Вычисли SHA-256 текущего плана до правок. Он обязан совпадать с `plan_sha256` review. При несовпадении остановись: review устарел, нужен новый `eda-plan-review`.
 3. Перед правкой прочитай план, `docs/rules.md`, `docs/arch.md`, только применимые `sources.business`, `sources.references` и `sources.research`.
-4. Не переоценивай findings и не создавай новые. Если finding недоказан, противоречит контексту или непонятен, остановись и попроси повторное review либо решение пользователя.
-5. Required нельзя автономно отклонить или сделать waived.
-6. Встраивай правки в `Целевой алгоритм`, `Контракты реализации`, фазы, тесты, логирование и эксплуатацию. Не создавай длинный журнал ревью в теле плана.
-7. Сохраняй ID задач и прямые зависимости; при структурной правке актуализируй все ссылки.
-8. Не правь код, конфиги, зависимости, миграции или другие документы. Не запускай проверки проекта.
-
-## Применить findings
-
-1. Прочитай раздел `Gate`, все открытые findings и `Отклонённые предложения`.
-2. До редактирования собери все вопросы и optional-решения. Не делай частичную правку до ответа на блокирующий вопрос.
-3. Примени required и выбранные optional одним связным изменением плана.
-4. Для каждого ID зафиксируй `applied` или `waived`; не меняй fingerprint.
+4. Не переоценивай находки и не создавай новые. Каждая находка в итоговом review требует исправления. Если находка недоказана, противоречит контексту или непонятна, остановись и попроси повторное review либо решение пользователя.
+5. Не пропускай находку и не заменяй её пожеланием на будущее. Продуктовый выбор, конфликт с business/rules/architecture или расширение scope передай пользователю одним блокирующим вопросом до любых правок.
+6. Делай минимально достаточный diff. Сначала удаляй лишнее или заменяй существующую формулировку; не добавляй новый абзац, если достаточно одной строки, не повторяй сведения между разделами и не добавляй rationale, примеры или фон, которых не требует находка.
+7. Встраивай правки в `Целевой алгоритм`, `Контракты реализации`, фазы, тесты, логирование и эксплуатацию. Не создавай длинный журнал ревью в теле плана.
+8. Сохраняй ID задач и прямые зависимости; при структурной правке актуализируй все ссылки.
+9. Не правь код, конфиги, зависимости, миграции или другие документы. Не запускай проверки проекта.
+
+## Применить находки
+
+1. Прочитай раздел `Gate`, все открытые находки и `Отклонённые предложения`.
+2. До редактирования собери все реальные блокирующие вопросы. Не делай частичную правку до ответа.
+3. Примени все открытые находки одним связным минимальным изменением плана. Отклонённые предложения не применяй.
+4. Для каждого ID зафиксируй `applied`; не меняй fingerprint.
 5. Заранее определи `$FIX_FILE`, обнови front matter плана полями `status`, `plan_review` и `plan_review_fix`, затем вычисли окончательный SHA-256 как `$AFTER_SHA256`.
-6. Если обязательные правки были, но итоговый SHA-256 не изменился, остановись `blocked: fix не изменил план` и не выдавай успех.
+6. Если находки были, но итоговый SHA-256 не изменился, остановись `blocked: fix не изменил план` и не выдавай успех.
 
 После успешного изменения:
 
@@ -74,32 +60,29 @@ date: <YYYY-MM-DD HH:MM>
 
 # Исправления плана по ревью: <название>
 
-## Применённые findings
+## Применённые находки
 | ID | Что изменено | Раздел плана | Статус |
 |---|---|---|---|
 | PR-001 | <конкретная правка> | <раздел> | applied |
 
-## Waived optional
-| ID | Причина | Новые доказательства для пересмотра |
-|---|---|---|
-
 ## Цепочка
 - **Before SHA-256:** `<hash>`
 - **After SHA-256:** `<hash>`
 - **Нужен подтверждающий review:** да
 ```
 
-После записи отчёта допиши в review один раздел `## Применённые исправления` со ссылкой на fix, after SHA-256 и списком waived ID. Не дублируй раздел при повторном продолжении того же запуска.
+После записи отчёта допиши в review один раздел `## Применённые исправления` со ссылкой на fix, after SHA-256 и списком applied ID. Не дублируй раздел при повторном продолжении того же запуска.
 
 ## Финал
 
-Сообщи пути к plan/review/fix, before/after SHA-256, applied/waived, оставшиеся блокеры и что изменения не закоммичены. Следующий шаг — `eda-plan-review` для подтверждения или возврат вызывающему `eda-plan-polish`.
+Сообщи пути к plan/review/fix, before/after SHA-256, applied ID, оставшиеся блокеры и что изменения не закоммичены. Следующий шаг — `eda-plan-review` для подтверждения или возврат вызывающему `eda-plan-polish`.
 
 ## Чего НЕ делать
 
 - Делать новое ревью или выставлять score.
 - Исправлять код или файлы вне выбранного плана, review и fix-отчёта.
 - Применять stale review к другому SHA-256.
-- Молча отклонять required или продуктовый конфликт.
+- Молча пропускать находку или самостоятельно разрешать продуктовый конфликт.
+- Раздувать план пояснениями и повторами вместо минимального удаления или замены.
 - Добавлять журнал итераций в тело плана.
 - Коммитить, запускать тесты, lint, build, typecheck, миграции или другой CLI.

package/skills/eda-polish/SKILL.md

@@ -1,12 +1,11 @@
 ---
 name: eda-polish
-description: 'Итеративно ревьюит и исправляет изменения до заданной оценки качества.'
+description: 'Итеративно ревьюит и исправляет изменения до чистого результата и заданной оценки качества.'
 ---
 
 # Скил: Полировка изменений (eda-polish)
 
-Оркестрируй цикл `eda-review` → `eda-fix-by-review apply-optional` → повторное `eda-review`. Основной агент только управляет итерациями, читает сохранённые артефакты и сообщает результат.
-В начале каждой итерации запускай полное `eda-review` целевого изменения.
+Оркестрируй цикл `eda-review` → `eda-fix-by-review` → повторное `eda-review`. Основной агент только управляет итерациями, читает сохранённые артефакты и сообщает результат. В начале каждой итерации запускай полное `eda-review` целевого изменения.
 
 ## Вход из сообщения пользователя
 
@@ -16,12 +15,12 @@ description: 'Итеративно ревьюит и исправляет изм
 
 ## Правила
 
-1. Каждый вызов `eda-review` и `eda-fix-by-review apply-optional` запускай отдельным изолированным субагентом. Основной агент не делает их работу.
+1. Каждый вызов `eda-review` и `eda-fix-by-review` запускай отдельным изолированным субагентом. Основной агент не делает их работу.
 2. Если нативные субагенты недоступны, остановись; не заменяй шаги CLI-процессами.
-3. Сравнивай порог только со `score` полного ревью со статусом `reviewed` или `reviewed-with-warnings`.
-4. Все пункты «править обязательно» исправь. Для каждого optional-пункта fix-агент сам решает, применять ли его, и сохраняет причины отклонения, чтобы следующие ревьюеры не повторяли решение без новых аргументов.
+3. Успех требует одновременно: полный review со статусом `reviewed` или `reviewed-with-warnings`, `result: clean`, ноль находок и `score >= threshold`.
+4. Любая находка обязательно исправляется независимо от score. Порог не превращает найденную проблему в допустимую.
 5. Не коммить и не отправляй ревью.
-6. Останавливайся при повторном сбое обязательной проверки review, блокере fix-агента, отсутствии применимых замечаний ниже порога или если score не растёт два круга подряд.
+6. Останавливайся при повторном сбое обязательной проверки review, блокере fix-агента, неизменном наборе находок один полный круг или достижении лимита.
 
 ## Вопросы
 
@@ -29,53 +28,42 @@ description: 'Итеративно ревьюит и исправляет изм
 
 ## Цикл
 
-Сформируй `$TARGET_CONTEXT`, `$THRESHOLD`, `$LIMIT` и внутренний журнал: номер итерации, review file, score, fix report и причина продолжения.
+Сформируй `$TARGET_CONTEXT`, `$THRESHOLD`, `$LIMIT` и журнал: номер итерации, review file, result, score, список находок, fix report и причина продолжения.
 
 Для каждой итерации:
 
-1. Запусти отдельного субагента с задачей:
+1. Запусти отдельного субагента:
 
    ```text
    Используй eda-review для <TARGET_CONTEXT>.
    План: <PLAN_FILE | none>.
    Overrides проверок и моделей: <из запроса | none>.
-   Верни путь к файлу, status, score и coverage.
+   Верни путь к файлу, status, result, score, находки и coverage.
    ```
 
-2. Если review остановился из-за обязательного агента, останови весь цикл. `reviewed-with-warnings` из-за недоступных previous reviews разрешён и не блокирует цикл.
-3. Если `score >= threshold`, заверши успешно.
-4. Если score ниже порога, прочитай рекомендации. Если обязательных и optional-пунктов нет, остановись `blocked: нет применимых замечаний для повышения оценки`.
-5. Запусти отдельного субагента:
+2. Если review остановился из-за обязательного агента, останови цикл. `reviewed-with-warnings` из-за недоступных previous reviews разрешён.
+3. Если `result: clean`, находок нет и `score >= threshold`, заверши успешно. Если `result` противоречит числу находок, считай файл невалидным и остановись.
+4. Если находки есть, запусти отдельного субагента:
 
    ```text
-   Используй eda-fix-by-review apply-optional для <REVIEW_FILE>.
-   Примени все обязательные замечания. По каждому optional сам реши, применять ли его; отклонённые решения сохрани с причиной.
+   Используй eda-fix-by-review для <REVIEW_FILE>.
+   Примени все находки минимальными достаточными правками и выполни проверки.
    Верни путь к fix-отчёту и результат проверок.
    ```
 
-6. При успешных исправлениях начни следующую итерацию с новым полным `eda-review`.
+5. После успешных исправлений начни новую итерацию с полным `eda-review`.
 
-Если score не растёт два проверенных круга подряд, остановись раньше лимита. Если достигнут лимит, не скрывай незавершённую сходимость.
+Если после полного круга набор находок не изменился, остановись раньше лимита с конкретными оставшимися проблемами. При достижении лимита не скрывай незавершённую сходимость. Состояние `clean` со score ниже threshold является несогласованным с контрактом `eda-review`: при отсутствии находок score должен быть `100`; остановись как на ошибке контракта.
 
 ## Финал
 
-Сообщи:
-
-- результат: достигнут порог, достигнут лимит, blocked, нет применимых замечаний или score не растёт;
-- итоговую оценку и порог;
-- количество итераций;
-- последний review file и fix report;
-- предупреждения coverage, если они были;
-- что изменения не закоммичены.
-
-При успехе предложи `eda-commit`. При неуспехе назови конкретный блокер или оставшиеся замечания.
+Сообщи результат, итоговый result и score, порог, число итераций, последний review file и fix report, оставшиеся находки и coverage warnings. Укажи, что изменения не закоммичены. При успехе предложи `eda-commit`; при неуспехе назови конкретный блокер.
 
 ## Чего НЕ делать
 
 - Делать ревью или исправления основным агентом.
 - Запускать отдельный этап проверки готового ревью.
-- Сравнивать порог с неполным или заблокированным ревью.
-- Механически применять все optional-пункты.
-- Терять причины отклонённых optional-решений.
+- Считать цикл успешным только по score при наличии находок.
+- Выбирать или отклонять принятые находки.
 - Переписывать `docs/settings.yaml`, правила или архитектуру ради score.
 - Коммитить, пушить или отправлять ревью.

package/skills/eda-review/SKILL.md

@@ -114,7 +114,7 @@ REVIEW_CONTEXT: <краткий общий контекст>
 
 ## Проверить ответы и обработать сбои
 
-Проверь для каждого ответа `status`, `check`, фактически запрошенный `model` и структуру `findings`. Несовпадение модели считай ошибкой контракта. Находка без конкретного риска и доказательства не подтверждена.
+Проверь для каждого ответа `status`, `check`, фактически запрошенный `model` и структуру `находки`. Несовпадение модели считай ошибкой контракта. Каждая находка означает дефект, который обязательно исправить. Находка без точного места, конкретного достижимого риска, доказательства и проверяемого способа исправления не подтверждена.
 
 - При `blocked`, неверном YAML или отсутствующих обязательных полях один раз повтори того же агента на той же модели с исходным контекстом и описанием ошибки формата.
 - `completed` означает успешно выполненную проверку. `not_applicable` перенеси в skipped с причиной и не повторяй.
@@ -128,9 +128,11 @@ REVIEW_CONTEXT: <краткий общий контекст>
 
 1. Проверь находки по указанным evidence и отклони неподтверждённые.
 2. Объедини дубли разных агентов в один пункт, сохранив все полезные доказательства.
-3. Распредели проблемы по тяжести и рекомендации `required` или `optional`.
-4. Сам выставь итоговый `score` от 0 до 100 по серьёзности, вероятности, влиянию и общему качеству реализации. Не используй фиксированные вычеты, среднее или минимум оценок агентов. Добавь короткое обоснование числа.
-5. Не выполняй дополнительное самостоятельное ревью и не добавляй новые domain-находки от себя.
+3. Оставь только конкретные ошибки, нарушения контрактов и существенные неточности, которые нельзя безопасно игнорировать. Косметические улучшения, вкусовой рефакторинг, спекулятивное усиление, необязательные тесты, документацию и оптимизации отклони, а не превращай в находку.
+4. Для каждой принятой находки проверь точное место, доказательство, практическое влияние, минимальное исправление и способ проверки. Если хотя бы одного элемента нет, отклони находку.
+5. Сам выставь итоговый `score` от 0 до 100 по серьёзности, вероятности, влиянию и общему качеству реализации. Не используй фиксированные вычеты, среднее или минимум оценок агентов. Ориентир: `100` — находок нет; `95–99` — только low; `80–94` — medium или несколько low; `60–79` — high; ниже `60` — critical или нужна существенная переработка. Любое снижение score связывай с принятыми находками; если находок нет, score равен `100`. Добавь короткое обоснование числа.
+6. Установи `result: clean`, только если находок нет; при любой находке используй `result: changes-required` независимо от score.
+7. Не выполняй дополнительное самостоятельное ревью и не добавляй новые domain-находки от себя.
 
 Ревью содержит только проблемы. Не перечисляй выполненную работу, похвалу и успешные проверки. Исключение — короткий технический раздел покрытия.
 
@@ -144,6 +146,7 @@ target: <что проверено>
 plan: <docs/plans/... | none>
 score: <0..100>
 status: <reviewed | reviewed-with-warnings>
+result: <clean | changes-required>
 date: <YYYY-MM-DD HH:MM>
 checks:
   - name: <check>
@@ -184,29 +187,18 @@ checks:
 
 - **Тип:** <check>
 - **Тяжесть:** <critical | high | medium | low>
-- **Рекомендация:** <править обязательно | на усмотрение автора>
 - **Файлы:** `<path:line>`
 - **Что подтверждает проблему:** <evidence>
 - **Как исправить:** <общий подход и конкретные шаги>
 - **Тесты:** <что добавить или обновить>
 
-## Рекомендации
-
-### Править обязательно
-- <номера или «Нет»>
-
-### На усмотрение автора
-- <номера или «Нет»>
-
-### Не править
-- <только явно отклонённые пункты или «Нет»>
 ```
 
 Основная часть каждого замечания — главный ответ: простой язык, 1–3 коротких абзаца и контекст, понятный без чтения diff или плана. Файлы, строки, SQL, DTO и внутренние имена давай ниже в `Технические детали`.
 
 ## Финал
 
-Коротко сообщи путь к ревью, статус, score, количество обязательных и optional-проблем, completed/skipped/warnings. Предложи `eda-fix-by-review` для исправления или `eda-commit`, если результат приемлем.
+Коротко сообщи путь к ревью, status, result, score, количество находок, completed/skipped/warnings. При `changes-required` предложи `eda-fix-by-review`; при `clean` — `eda-commit`.
 
 ## Чего НЕ делать
 

package/skills/eda-send-review/SKILL.md

@@ -53,9 +53,9 @@ description: 'Публикует готовое ревью из `docs/reviews/`
 ### 2. Выбрать ревью и что отправлять
 Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», PR (`PR 12`, `#12`), статус отправки (`comment`, `review-comment`, `approve`, `request-changes`) и указание закрыть или сохранить предыдущие ревью.
 
-Если найдено ровно одно ревью — продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста — остановись с понятным вопросом или статусом `blocked: нужно ревью`. Прочитай файл целиком: оценку, замечания, рекомендации. Отсутствие статуса отправки само по себе не считается недостатком входа и не требует вопроса.
+Если найдено ровно одно ревью — продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста — остановись с понятным вопросом или статусом `blocked: нужно ревью`. Прочитай файл целиком: result, оценку и замечания. Отсутствие статуса отправки само по себе не считается недостатком входа и не требует вопроса.
 
-**Что отправлять.** По умолчанию — все замечания. Если в тексте указано подмножество, отправь только его. Синтаксис свободный, распознавай по смыслу: по номерам («пункты 1, 3, 5»), по обязательности («только обязательные» → раздел «Править обязательно»), по типу («только security» → замечания с этим `Тип`). Выбор влияет и на сводку, и на комментарии к строкам.
+**Что отправлять.** По умолчанию — все замечания. Если в тексте указано подмножество, отправь только его. Синтаксис свободный, распознавай по смыслу: по номерам («пункты 1, 3, 5») или по типу («только security» → замечания с этим `Тип`). У находок нет разных степеней обязательности: каждый отправляемый пункт требует исправления. Выбор влияет и на сводку, и на комментарии к строкам. Для старого формата отправляй только раздел `Править обязательно`; предложения из остальных групп отбрасывай.
 
 ### 3. Найти целевой PR
 Если номер PR указан в тексте пользователя — используй его. Иначе попробуй `gh pr view --json number,url,headRefName` — если у текущей ветки уже есть PR, возьми его номер.
@@ -73,7 +73,7 @@ Review отправляется всегда; здесь выбирается т
 | явно указано `comment` / `review-comment` | `COMMENT` | не задавать |
 | статус не указан | `COMMENT` | не задавать |
 
-`comment` и `review-comment` означают review без решения о принятии изменений (`event=COMMENT`) — обычный комментарий-ревью, который тоже несёт сводку и комментарии к строкам. Явно приложенный или названный пользователем контекст текущего вызова учитывай наравне с текстом рядом со скиллом. Не выводи статус из score, раздела рекомендаций, не связанного с вызовом старого обсуждения или предыдущих запусков. Если в текущем контексте одновременно указаны несовместимые статусы и приоритет неясен — `AskUserQuestion` с тремя вариантами.
+`comment` и `review-comment` означают review без решения о принятии изменений (`event=COMMENT`) — обычный комментарий-ревью, который тоже несёт сводку и комментарии к строкам. Явно приложенный или названный пользователем контекст текущего вызова учитывай наравне с текстом рядом со скиллом. Не выводи статус из result, score, старого обсуждения или предыдущих запусков. Если в текущем контексте одновременно указаны несовместимые статусы и приоритет неясен — `AskUserQuestion` с тремя вариантами.
 
 ### 5. Собрать сводку и комментарии к строкам
 Из выбранных пунктов собери две части.
@@ -84,12 +84,12 @@ Review отправляется всегда; здесь выбирается т
 ## Ревью: <заголовок>
 
 **Оценка:** N/100. <одно-два предложения почему>
+**Результат:** <clean | changes-required>
 
 <короткое резюме: что отправлено и общий вывод>
 
-### Рекомендации
-- **Править обязательно:** 1, 3, 5
-- **На усмотрение автора:** 2, 4
+### Замечания
+1. **[тип]** <краткая суть и требуемое исправление>
 
 ### Замечания вне diff
 1. **[тип]** `path/file.py:42` — <что не так>. → <что предлагаешь>
@@ -170,7 +170,7 @@ gh api graphql -f query='mutation($id: ID!) { resolveReviewThread(input: {thread
 - Делать само ревью или править замечания — это `eda-review` / `eda-fix-by-review`.
 - Отправлять всё одним обычным комментарием PR, когда строки можно привязать к diff — обычный комментарий только fallback при отсутствии diff.
 - Терять замечания вне diff — они идут в сводку отдельным разделом.
-- Выводить `approve` или `request-changes` из score, рекомендаций или не связанного с вызовом старого контекста — без явного статуса в контексте текущего вызова всегда `COMMENT`.
+- Выводить `approve` или `request-changes` из result, score или не связанного с вызовом старого контекста — без явного статуса в контексте текущего вызова всегда `COMMENT`.
 - Скрывать или резолвить чужие, ручные или не связанные с предыдущими отправками `eda-send-review` комментарии.
 - Закрывать предыдущие отправки до успешной публикации нового ревью.
 - Передавать тело через `-b "..."` со спецсимволами — только `--input` (Reviews API) или `--body-file` (fallback).