@gian-tiaga/eda 2.0.0 → 3.1.0

package/skills/eda-discover-automations/SKILL.md

@@ -19,7 +19,7 @@ description: 'Аудирует автоматические проверки п
 |---|---|---|
 | `discover-automations.include_plans` | `true`, `false` | `plans`, «с планами»; выключение: `normal`, «без планов» |
 
-Обычный режим анализирует текущий проект и, если они есть, `docs/reviews/`, `docs/review-fixes/`, `docs/fixes/`. Режим `discover-automations.include_plans: true` добавляет `docs/plans/`. Отсутствие истории не отменяет полный аудит текущих проверок.
+Обычный режим анализирует текущий проект и, если они есть, `docs/artifacts/reviews/`, `docs/artifacts/review-fixes/`, `docs/artifacts/fixes/`. Режим `discover-automations.include_plans: true` добавляет `docs/artifacts/plans/`. Отсутствие истории не отменяет полный аудит текущих проверок.
 
 ## Вход из сообщения пользователя
 
@@ -49,11 +49,11 @@ description: 'Аудирует автоматические проверки п
 
 Если вход неоднозначен — `AskUserQuestion`: все ревью и фиксы / все ревью, фиксы и планы / последние N / период / конкретные файлы.
 
-Получи список файлов из `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`. В режиме `plans` дополнительно получи список файлов из `docs/plans/`. Отсутствующие или пустые папки отметь в отчёте, но не блокируйся: проведи baseline gap-аудит по коду, manifest-файлам, конфигам, scripts и CI текущего проекта.
+Получи список файлов из `docs/artifacts/reviews/`, `docs/artifacts/review-fixes/` и `docs/artifacts/fixes/`. В режиме `plans` дополнительно получи список файлов из `docs/artifacts/plans/`. Отсутствующие или пустые папки отметь в отчёте, но не блокируйся: проведи baseline gap-аудит по коду, manifest-файлам, конфигам, scripts и CI текущего проекта.
 
 ### 2. Прочитать контекст
 - Все выбранные ревью, отчёты о фиксах по ревью и обычные фиксы.
-- В режиме `plans`: все выбранные планы из `docs/plans/`.
+- В режиме `plans`: все выбранные планы из `docs/artifacts/plans/`.
 - `docs/rules.md`, `docs/arch.md` (если есть) — прочитай и строго следуй им.
 - Сначала определи затронутые историей и текущим аудитом доменные области. Затем через `docs/business.md` выбери только карточки этих областей; если подходящих нет, продолжай без business-контекста. Используй карточки лишь для поиска автоматизируемых инвариантов и acceptance-сценариев, не расширяй аудит на несвязанные темы.
 - Какие языки и фреймворки в проекте — определи сам.
@@ -96,19 +96,19 @@ description: 'Аудирует автоматические проверки п
 4. `agent` — MCP-сервер, новая/обновлённая eda-инструкция, специализированная агентная проверка или обязательный источник контекста. Предлагай только когда это закрывает значимую ошибку AI-процесса или даёт агенту данные, которые нельзя надёжно получить из кода.
 5. `rules` / `architecture` — текстовые правила и архитектурные уточнения, если проблема связана с договорённостью, границей модулей или ownership.
 
-Предпочитай уже установленный инструмент, если он ловит этот класс проблем. Новый инструмент предлагай только если он не дублирует инструмент того же класса. Для проблем из планов предлагай проверку `docs/plans/*.md`, а не runtime-линтер кода. Если правило или архитектура уже зафиксированы, не дублируй текст; предложи только уточнение, которое закрывает найденный случай.
+Предпочитай уже установленный инструмент, если он ловит этот класс проблем. Новый инструмент предлагай только если он не дублирует инструмент того же класса. Для проблем из планов предлагай проверку `docs/artifacts/plans/*.md`, а не runtime-линтер кода. Если правило или архитектура уже зафиксированы, не дублируй текст; предложи только уточнение, которое закрывает найденный случай.
 
 Подменять линтер, статанализатор или тест MCP-сервером/скилом нельзя, если ошибку можно надёжно поймать программной проверкой.
 
 Для каждой программной проверки укажи точный инструмент, команду/сценарий и контур: `pre-commit`, `pre-push`, `PR CI`, `nightly`, `release`, `post-deploy`. Быстрые проверки отдели от тяжёлых. Для MCP укажи сервер/класс инструмента, проверяемый сценарий, минимальные права, тестовые данные и контур `MCP/manual`; MCP не называй автоматической CI-проверкой, если он реально не запускается без участия агента.
 
 ### 5. Сохранить отчёт
-`docs/automations/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Slug — короткое описание набора (например, `php-strict-rules`).
+`docs/artifacts/automations/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Slug — короткое описание набора (например, `php-strict-rules`).
 
 ```markdown
 ---
 date: <YYYY-MM-DD HH:MM>
-sources: [docs/reviews/..., docs/review-fixes/..., docs/fixes/..., docs/business/...]
+sources: [docs/artifacts/reviews/..., docs/artifacts/review-fixes/..., docs/artifacts/fixes/..., docs/business/...]
 mode: <normal | plans>
 status: draft
 ---
@@ -132,7 +132,7 @@ status: draft
 ### 1. <название паттерна>
 - **Тип:** automation / tests / tooling
 - **Что ловит:** ...
-- **Встречалось в:** `docs/reviews/...` (×1), `docs/reviews/...` (×2)
+- **Встречалось в:** `docs/artifacts/reviews/...` (×1), `docs/artifacts/reviews/...` (×2)
 - **Почему автоматизировать:** <повторяемость либо высокий ущерб и вероятность повторения>
 - **Инструмент:** <название или текущий test runner> (если новый для проекта — пометка «требует установки»)
 - **Команда / сценарий:** <точная команда, glob, правило или тестовый сценарий>
@@ -150,7 +150,7 @@ status: draft
 ### 1. <название паттерна>
 - **Тип:** agent
 - **Что закрывает:** <какую ошибку процесса или нехватку контекста>
-- **Встречалось в:** `docs/reviews/...` (×1), `docs/fixes/...` (×1)
+- **Встречалось в:** `docs/artifacts/reviews/...` (×1), `docs/artifacts/fixes/...` (×1)
 - **Почему автоматизировать:** <повторяемость либо высокий ущерб и вероятность повторения>
 - **Предложение:** MCP-сервер / новый eda-скил / правка существующего скила / специализированная агентная проверка
 - **Сценарий и доступ:** <что проверяет, минимальные права, тестовые данные, почему CLI/CI недостаточно>
@@ -166,7 +166,7 @@ status: draft
 - **Тип:** rules / architecture
 - **Куда:** `docs/rules.md` / `docs/arch.md`, раздел <название или «новый раздел»>
 - **Почему:** <какой паттерн закрывает>
-- **Встречалось в:** `docs/fixes/...` (×1), `docs/reviews/...` (×1)
+- **Встречалось в:** `docs/artifacts/fixes/...` (×1), `docs/artifacts/reviews/...` (×1)
 - **Черновик текста:**
   ```markdown
   <готовый фрагмент для docs/rules.md или docs/arch.md>

package/skills/eda-explore/SKILL.md

@@ -38,7 +38,7 @@ description: 'Исследует техническую тему или зада
 
 ## Главные правила
 
-1. **Никаких правок кода.** Запись только в `docs/researches/`.
+1. **Никаких правок кода.** Запись только в `docs/artifacts/researches/`.
 2. **Итог — конкретика.** Нельзя заканчивать абстрактными описаниями, списком возможностей или «можно выбрать один из вариантов».
 3. **Развилки закрывай по `decision_mode`.** Значимые развилки подтверждай до финализации, мелкие локальные решения выбирай сам и не создавай шум.
 4. **Риски вплетай в исследование.** Не создавай отдельный обязательный раздел или этап рисков. Если риск влияет на выбор, источник, ограничение или будущую проверку, фиксируй его рядом с соответствующим решением: что может пойти не так и как это учитывается — снимаем, принимаем или выносим за рамки.
@@ -87,7 +87,7 @@ description: 'Исследует техническую тему или зада
 
 ### 4. Собрать отчёт
 
-Сохрани отчёт в `docs/researches/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
+Сохрани отчёт в `docs/artifacts/researches/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
 
 Формат отчёта должен быть компактным и универсальным: четыре основных раздела, без обязательного раздувания под каждый тип исследования. Таблицы, ASCII-диаграммы и дополнительные подпункты добавляй внутри этих разделов только когда они действительно помогают ясности.
 
@@ -176,4 +176,4 @@ CLI нет — `AskUserQuestion`: продолжать без ревью или
 - Перечислять риски без выбранного закрытия.
 - Планировать реализацию по шагам — это работа `eda-plan`.
 - Указывать `latest` без конкретной проверенной версии и источника.
-- Сохранять отчёт куда-либо кроме `docs/researches/`.
+- Сохранять отчёт куда-либо кроме `docs/artifacts/researches/`.

package/skills/eda-fix/SKILL.md

@@ -20,7 +20,7 @@ description: 'Вносит изменения в код по плану или
 3. **Делай только указанные фиксы.** Не расширяй задачу до рефакторинга и не чини соседние проблемы без необходимости.
 4. **Тесты рядом с правкой.** Меняешь поведение — добавь или обнови точечный тест.
 5. **Финальная проверка обязательна.** В конце прогони подходящие тесты и линтеры проекта.
-6. **Историю фиксируй в `docs/fixes/`.** Отчёт обязателен даже для маленькой правки.
+6. **Историю фиксируй в `docs/artifacts/fixes/`.** Отчёт обязателен даже для маленькой правки.
 7. **Не коммить и не пушь.** Это `eda-commit`. Не делай ревью — это `eda-review`.
 
 ## Интерактивные вопросы
@@ -34,7 +34,7 @@ description: 'Вносит изменения в код по плану или
 ## Этапы
 
 ### 1. Определить задачу
-Определи `$FIX_CONTEXT`: путь к файлу прочитай, план из `docs/plans/` используй как план фикса, текст используй как контекст. Если входа нет или он неоднозначен — спроси через `AskUserQuestion`.
+Определи `$FIX_CONTEXT`: путь к файлу прочитай, план из `docs/artifacts/plans/` используй как план фикса, текст используй как контекст. Если входа нет или он неоднозначен — спроси через `AskUserQuestion`.
 
 ### 2. Прочитать рамку проекта
 Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Сначала определи задачу фикса и затронутое поведение. Если связанный план содержит `sources.business`, прочитай только перечисленные применимые карточки; иначе через `docs/business.md` выбери по описаниям только карточки этой темы. Если подходящих карточек нет, продолжай без business-контекста. Если существует `docs/references.md`, выбери по индексу только применимые технические карточки и используй их примеры как ожидаемую форму реализации. Если `$FIX_CONTEXT` ссылается на research, review, issue или другой файл — прочитай и его.
@@ -49,12 +49,12 @@ description: 'Вносит изменения в код по плану или
 Прогони подходящие тесты и линтеры. Команды определи по стеку проекта. Свои поломки — исправь и повтори. Чужие или несвязанные поломки — зафиксируй в отчёте и спроси через `AskUserQuestion`, если без решения нельзя продолжать.
 
 ### 6. Сохранить отчёт
-Сохрани отчёт в `docs/fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
+Сохрани отчёт в `docs/artifacts/fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
 
 ```markdown
 ---
 date: <YYYY-MM-DD HH:MM>
-source: <text | path | docs/plans/...>
+source: <text | path | docs/artifacts/plans/...>
 status: done
 ---
 
@@ -83,8 +83,8 @@ status: done
 ## Чего НЕ делать
 - Коммитить, пушить, создавать PR.
 - Делать ревью вместо фикса.
-- Выполнять большой план с чекбоксами и журналом `docs/executions/` — это `eda-plan-execute`.
+- Выполнять большой план с чекбоксами и журналом `docs/artifacts/executions/` — это `eda-plan-execute`.
 - Применять замечания из готового ревью — это `eda-fix-by-review`.
-- Сохранять отчёт куда-либо кроме `docs/fixes/`.
+- Сохранять отчёт куда-либо кроме `docs/artifacts/fixes/`.
 - Загружать несвязанные business-карточки или расширять ими scope фикса.
 - Игнорировать применимую карточку или молча отклоняться от её требований либо примера.

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

@@ -5,80 +5,73 @@ description: 'Исправляет код по готовому ревью из
 
 # Скил: Исправитель по ревью (eda-fix-by-review)
 
-Берёшь готовое ревью из `docs/reviews/`, применяешь замечания к коду, сохраняешь отчёт о фиксах в `docs/review-fixes/`. После всех правок — полный прогон тестов и линтеров.
+Берёшь готовое ревью из `docs/artifacts/reviews/` или сообщения, применяешь все находки к коду и сохраняешь отчёт в `docs/artifacts/review-fixes/`. После правок выполняешь полный прогон тестов и линтеров.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+Текст рядом с вызовом скилла в текущем сообщении — главный вход. Сначала разбери тему, задачу, путь к файлу, номера замечаний, ограничения и прямые указания. Если входа достаточно, продолжай без вопроса. Старое обсуждение не считай входом, если пользователь явно не связал его с текущим вызовом.
 
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Режим запуска
-
-Обычный режим: все пункты «Править обязательно» применяешь сразу, «На усмотрение автора» выносишь через `AskUserQuestion`, «Не править» пропускаешь.
-
-Режим `apply-optional`: все пункты «Править обязательно» применяешь без исключений. По каждому пункту «На усмотрение автора» сам принимаешь решение без вопроса: применяешь, если правка явно улучшает качество, снижает риск или стоит дёшево; отклоняешь, если польза спорная, правка расширяет scope, создаёт риск регрессии, конфликтует с правилами/архитектурой или требует продуктового решения. Название режима означает «разобрать optional без вопроса», а не «механически применить все optional». Пункты «Не править» всё равно пропускаешь.
+У нового формата ревью одна группа находок: каждый пункт обязательно исправить. Режимов выбора рекомендаций нет. Если дан старый файл с разделами `Править обязательно`, `На усмотрение автора` и `Не править`, применяй только пункты из `Править обязательно`; остальные старые предложения не переноси в работу и отчёт.
 
 ## Главные правила
 
-1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`. Сначала определи замечания и затронутое ими поведение; затем через `sources.business` связанного плана или `docs/business.md` выбери только применимые business-карточки, а через `docs/references.md` — только карточки затронутых компонентов. Если подходящих business-карточек нет, продолжай без них. Сделай это один раз в начале.
-2. **Интерактивные вопросы** — по разделу ниже.
-3. **Не переформулируй замечания.** Применяй то, что написано в ревью. Если непонятно — спроси через `AskUserQuestion`.
-4. **Не делаешь само ревью и не коммитишь.** Только применяешь замечания и пишешь отчёт.
-5. **Логика по группам ревью:** «Править обязательно» — правишь все сразу; «На усмотрение автора» — спроси через `AskUserQuestion`, кроме режима `apply-optional`, где сам решаешь применить или отклонить; «Не править» — пропускаешь и отмечаешь в отчёте.
-6. **Тесты — внутри той же правки.** Замечание касается поведения → правка кода + тесты к ней в одном шаге, точечно прогнал.
-7. **Финальный полный прогон тестов и линтеров — обязателен.** В конце, не на каждой правке.
-8. **Простой язык** в формулировках и сообщениях. **Таблицы** для отчёта о фиксах.
+1. Перед правкой прочитай `docs/rules.md` и `docs/arch.md`. Определи замечания и затронутое поведение; затем через `sources.business` связанного плана или `docs/business.md` выбери только применимые business-карточки, а через `docs/references.md` — только карточки затронутых компонентов.
+2. Применяй все выбранные находки. Не переоценивай их полезность и не превращай исправление в более широкий рефакторинг.
+3. Отклонить находку можно, только если она фактически неверна: код уже делает требуемое, доказательство не воспроизводится или правка нарушает применимое правило либо архитектуру. Отклонение с причиной запиши в отчёт. Трудоёмкость, вкус и несогласие с формулировкой основанием не являются.
+4. Задавай вопрос только если находка неоднозначна, противоречит коду или обязательной документации, требует продуктового решения, расширяет scope либо ведёт к рискованному действию. В остальных случаях работай автономно.
+5. Не делай новое ревью и не коммить. Только исправляй замечания и пиши отчёт.
+6. Если находка касается поведения, добавь или обнови точечный тест в той же правке и прогони его.
+7. В конце обязательно прогони полный набор тестов и линтеров один раз.
+8. Пиши просто и конкретно; в отчёте используй таблицу.
 
 ## Интерактивные вопросы
 
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+Когда без ответа нельзя безопасно продолжать:
+
 - Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-- Для исправления кода это правило важнее требования довести фиксы до конца: не применяй пункты «на усмотрение автора» без ответа пользователя, кроме явного режима `apply-optional`, где решение принимает сам агент; не переформулируй замечания и не правь чужие/несвязанные поломки вместо ответа пользователя.
+- Codex interactive: используй `request_user_input`, если доступен; иначе задай один короткий вопрос с 2–3 вариантами и остановись до ответа.
+- Codex exec и другой неинтерактивный запуск: не читай stdin; верни `blocked: нужен ответ пользователя`, перечисли вопрос и варианты, не выполняй рискованное действие.
+
+Не запускай команды, которые ждут интерактивного ввода в терминале. Вопрос не разрешает молча заменить находку другой правкой или исправлять несвязанные поломки.
 
 ## Этапы
 
 ### 1. Выбрать ревью
-Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», номера замечаний или вставленный текст замечаний. Если замечания вставлены в сообщение — используй режим `$REVIEW_SOURCE=review_text`, не выбирай файл ревью и сохрани отчёт с `review: text`.
 
-Если найдено ровно одно ревью — используй режим `$REVIEW_SOURCE=review_file` и продолжай без вопроса. Если замечания даны текстом — используй режим `$REVIEW_SOURCE=review_text` и продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста и вход не содержит замечания — остановись с понятным вопросом или статусом `blocked: нужно ревью`.
+Разбери путь к ревью, название, «последнее ревью», номера находок или вставленный текст. Для текста используй `$REVIEW_SOURCE=review_text`, не выбирай файл и сохраняй отчёт с `review: text`.
+
+Если найден ровно один файл, используй `$REVIEW_SOURCE=review_file`. Если найдено несколько равно подходящих файлов или входа нет, задай один вопрос со списком. Если `docs/artifacts/reviews/` пуста и текст замечаний не дан, остановись с `blocked: нужно ревью`.
 
 ### 2. Прочитать контекст
-Прочитай `docs/rules.md`, `docs/arch.md`, если они есть. Если связанный план содержит `sources.business`, прочитай только перечисленные карточки, относящиеся к исправляемым замечаниям; иначе выбери их по описаниям через `docs/business.md`. Отсутствие подходящей карточки не является блокером. Через `docs/references.md` выбери только применимые технические карточки. Если связанный план содержит `sources.references`, прочитай перечисленные карточки и не загружай остальные.
 
-Если `$REVIEW_SOURCE=review_file`, прочитай сам файл ревью. Если ревью ссылается на план/research — прочитай и их.
+Прочитай `docs/rules.md` и `docs/arch.md`, если они есть. Для исправляемого поведения выбери только применимые business-карточки и технические reference-карточки. Если связанный план уже задаёт `sources.business` или `sources.references`, используй относящиеся к находкам пути из этих списков.
+
+При `$REVIEW_SOURCE=review_file` прочитай ревью целиком, а также явно связанные план и research. При `$REVIEW_SOURCE=review_text` работай по текущему сообщению. Файла ревью нет: не пытайся читать `$REVIEW_FILE` и не ищи план или research без явной ссылки.
 
-Если `$REVIEW_SOURCE=review_text`, работай по замечаниям из текущего сообщения пользователя. Файла ревью нет: не пытайся читать `$REVIEW_FILE` и не ищи связанные plan/research, если они не указаны в тексте.
+### 3. Применить находки
 
-### 3. Применить замечания
-Раздели пункты ревью по группам (берёшь из раздела «Рекомендации»):
-- **Править обязательно** → правишь все пункты сразу. Если меняешь поведение — добавь точечный тест в этой же правке.
-- **На усмотрение автора** → в обычном режиме собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя; в режиме `apply-optional` сам реши по каждому пункту, применяй только принятые решения без вопроса, а отклонённые фиксируй с причиной.
-- **Не править** → пропусти.
+Исправь все находки нового формата либо выбранные пользователем номера. Для старого формата возьми только пункты из `Править обязательно`. Делай минимальную достаточную правку и точечную проверку после каждого логического изменения. Находку, которая оказалась фактически неверной, не исправляй: запиши её в «Отклонённые находки» с доказательством.
 
-Останавливайся и спрашивай, если замечание непонятно, противоречит коду или проектной документации либо задевает рискованное вне ревью (удаление, миграции, секреты). Если исправление противоречит применимой business-карточке, покажи конфликт и спроси: изменить состав исправлений или сначала пересогласовать правило через `eda-business`. Не разрешай такой конфликт автоматически даже в `apply-optional`. Подтверждённое отклонение от технической карточки зафиксируй в отчёте.
+Остановись с вопросом при неоднозначности, конфликте с правилами, архитектурой или business-карточкой, необходимости расширить scope либо выполнить рискованное действие. При конфликте с business-карточкой предложи изменить состав исправлений или сначала пересогласовать правило через `eda-business`. Подтверждённое отклонение от технической карточки зафиксируй в отчёте.
 
 ### 4. Финальная проверка
-Прогони полный сьют тестов и линтеры. Команды — стандартные для стека; непонятно — `AskUserQuestion`. Свои поломки — правишь и повторяешь. Чужие/несвязанные — `AskUserQuestion`.
 
-### 5. Сохранить отчёт о фиксах и связать с ревью
-Сохрани отчёт в `docs/review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md` (slug — тот же что у ревью или близкий). Если `$REVIEW_SOURCE=review_file`, затем **допиши в конец файла ревью** (`$REVIEW_FILE`) раздел со ссылкой:
+Прогони полный сьют тестов и линтеры стандартными командами проекта. Свои поломки исправь и повтори проверку. При чужой или несвязанной ошибке остановись с конкретным блокером.
+
+### 5. Сохранить отчёт и связать с ревью
+
+Сохрани `docs/artifacts/review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Если `$REVIEW_SOURCE=review_file`, допиши в конец `$REVIEW_FILE`:
 
 ```markdown
 ## Применённые фиксы
-Отчёт: `docs/review-fixes/{file}.md`
+Отчёт: `docs/artifacts/review-fixes/{file}.md`
 ```
 
-Если `$REVIEW_SOURCE=review_text`, не дописывай ссылку в исходное ревью: такого файла нет. В отчёте укажи `review: text`.
-
-Шаблон отчёта:
+Если `$REVIEW_SOURCE=review_text`, не дописывай ссылку в исходное ревью: исходного файла нет.
 
 ```markdown
 ---
-review: <путь к docs/reviews/...>
+review: <docs/artifacts/reviews/... | text>
 date: <YYYY-MM-DD HH:MM>
 status: done
 ---
@@ -89,13 +82,11 @@ status: done
 | # | Замечание | Файлы | Тесты | Статус |
 |---|-----------|-------|-------|--------|
 | 1 | <кратко из ревью> | `path/a.py` | `path/test_a.py` (2 ✓) | ✓ применено |
-| 2 | ... | ... | — | ✓ применено |
-| 3 | ... | — | — | ✗ отклонено (на усмотрение, причина: <короткое обоснование>) |
-| 4 | ... | — | — | — не править (по решению ревью) |
 
-## Решения по optional
-- **Принято:** <номера и коротко почему>
-- **Отклонено:** <номера и коротко почему, чтобы следующие ревьюеры не повторяли это как открытое замечание>
+## Отклонённые находки
+| # | Замечание | Почему отклонена |
+|---|-----------|------------------|
+| 2 | <кратко из ревью> | <чем подтверждается, что находка неверна> |
 
 ## Финальная проверка
 - **Тесты:** `<команда>` — ✓ / ✗
@@ -103,18 +94,16 @@ status: done
 - **Заметки:** <если что-то осталось не зелёным — почему>
 ```
 
-Если `$REVIEW_SOURCE=review_file` и в режиме `apply-optional` отклонены пункты «На усмотрение автора», в добавляемом в ревью разделе `## Применённые фиксы` после ссылки на отчёт добавь короткий список `Отклонённые optional-решения` с причинами. Это нужно, чтобы следующие ревьюеры видели уже принятое решение и не повторяли тот же optional-пункт без новых аргументов.
-
 ### 6. Финал
-Короткое сообщение: путь к ревью или «источник: текст из сообщения», путь к отчёту о фиксах, сколько применено / пропущено / отклонено, результат финальной проверки, состояние git («не закоммичено»). Подсказка дальше — `eda-commit`.
+
+Короткое сообщение: путь к ревью или «источник: текст из сообщения», путь к fix-отчёту, сколько находок применено и сколько отклонено, результат финальной проверки и состояние git «не закоммичено». Предложи `eda-commit`.
 
 ## Чего НЕ делать
+
 - Делать само ревью — это `eda-review`.
-- Коммитить, пушить — это `eda-commit`.
-- Применять или отклонять «на усмотрение» молча без явного режима `apply-optional` или ответа пользователя.
-- Игнорировать «не править» и пробовать «на всякий случай» — это нарушает решение ревью.
-- Гонять полный сьют и линтеры на каждой правке — только в конце.
-- Пропускать финальную проверку.
-- Сохранять отчёт куда-либо кроме `docs/review-fixes/`.
-- Загружать несвязанные business-карточки или расширять ими состав исправлений.
-- Игнорировать применимую карточку или молча отклоняться от её требований либо примера.
+- Коммитить или пушить — это `eda-commit`.
+- Отклонять находку по вкусу, из-за трудоёмкости или несогласия с формулировкой: основание — только фактическая ошибка находки, и всегда с причиной в отчёте.
+- Расширять scope ради улучшений, которых нет в находках.
+- Гонять полный сьют после каждого пункта или пропускать финальную проверку.
+- Сохранять отчёт вне `docs/artifacts/review-fixes/`.
+- Загружать несвязанные business-карточки или молча отклоняться от применимого правила.

package/skills/eda-manual-test/SKILL.md

@@ -23,7 +23,7 @@ description: 'Проводит ручную smoke/acceptance-проверку и
 6. **Секреты не трогай.** Используй только уже доступные локальные `.env`, тестовые аккаунты и настройки. Не проси пользователя прислать секреты в чат и не печатай токены, cookies, passwords, API keys или Authorization headers в отчёт.
 7. **Разрушительное подтверждай.** Реальные платежи, удаление данных, отправку email/SMS/push, изменение production/staging-данных, миграции, очистку БД и похожие действия выполняй только после `AskUserQuestion`.
 8. **Проверяй фактическое поведение.** Не ограничивайся чтением кода. Если сценарий нельзя выполнить, зафиксируй `blocked` и конкретную причину.
-9. **Отчёт обязателен.** Сохрани результат в `docs/manual-tests/`, даже если проверка заблокирована или нашла баги.
+9. **Отчёт обязателен.** Сохрани результат в `docs/artifacts/manual-tests/`, даже если проверка заблокирована или нашла баги.
 10. **Задача важнее дополнительного контекста.** Основной чеклист строй по выполненной задаче: текущему сообщению и явно связанному плану, issue, review или fix-отчёту. Business-карточки подключай только после определения target и только для непосредственно затронутого поведения.
 
 ## Интерактивные вопросы
@@ -85,15 +85,15 @@ description: 'Проводит ручную smoke/acceptance-проверку и
 - видимые состояния ошибок, пустых данных или невалидного ввода, если они относятся к задаче;
 - текст и элементы управления не ломаются на очевидном desktop/mobile viewport, если менялась вёрстка.
 
-Скриншоты сохраняй только если инструмент это поддерживает и они помогают подтвердить результат или баг. Складывай их рядом с отчётом или в подпапку `docs/manual-tests/assets/`.
+Скриншоты сохраняй только если инструмент это поддерживает и они помогают подтвердить результат или баг. Складывай их рядом с отчётом или в подпапку `docs/artifacts/manual-tests/assets/`.
 
 ### 7. Сохранить отчёт
-Сохрани отчёт в `docs/manual-tests/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
+Сохрани отчёт в `docs/artifacts/manual-tests/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
 
 ```markdown
 ---
 date: <YYYY-MM-DD HH:MM>
-source: <text | git diff HEAD | docs/plans/... | docs/reviews/...>
+source: <text | git diff HEAD | docs/artifacts/plans/... | docs/artifacts/reviews/...>
 target: <api | frontend | fullstack | other>
 status: <passed | failed | blocked>
 ---
@@ -134,7 +134,7 @@ status: <passed | failed | blocked>
 Короткое сообщение: путь к отчёту, итог `passed` / `failed` / `blocked`, какие сценарии реально проверены, какие процессы остановлены, состояние git («не закоммичено»). Если итог `failed` или `blocked` — предложи дальше `eda-fix`. Если итог `passed` — предложи дальше `eda-review` или `eda-commit`.
 
 ## Чего НЕ делать
-- Править код, конфиги, миграции, seed-данные или документацию проекта, кроме отчёта в `docs/manual-tests/`.
+- Править код, конфиги, миграции, seed-данные или документацию проекта, кроме отчёта в `docs/artifacts/manual-tests/`.
 - Писать или обновлять unit/e2e/autotests. Это работа `eda-fix`, `eda-plan-execute` или отдельной задачи.
 - Устанавливать Playwright, браузеры, npm-пакеты, docker images или системные зависимости без явного подтверждения.
 - Подменять ручную проверку запуском `npm test` без фактического прохождения API/UI-сценария.

package/skills/eda-new-project/SKILL.md

@@ -20,7 +20,7 @@ description: 'Собирает и согласует требования, гр
 3. **Стек подбирается под задачу.** Для каждого значимого выбора дай 2–3 реалистичных варианта, рекомендацию и причину; не навязывай любимые технологии.
 4. **Фиксируй драйверы, а не архитектуру.** Запиши свойства, которым будущая архитектура должна соответствовать, но не выбирай слои, модули, направления зависимостей, структуру папок или внутренние data-flow.
 5. **Не дублируй `eda-prepare-ai`.** Не проектируй архитектуру, правила, строгие режимы инструментов, матрицу проверок, AI-скилы, агентные роли или MCP. После сохранения всегда передай подтверждённый стартовый документ в `eda-prepare-ai` без дополнительного вопроса.
-6. **Не пишешь код и не ставишь пакеты.** Сам меняй только `docs/project-starts/`; не создавай конфиги, CI или проектную AI-документацию.
+6. **Не пишешь код и не ставишь пакеты.** Сам меняй только `docs/artifacts/project-starts/`; не создавай конфиги, CI или проектную AI-документацию.
 7. **Проверяй версии выбранного стека.** Для каждого подтверждаемого пакета, runtime, framework, СУБД, CLI или сервиса найди актуальную стабильную версию по официальному источнику. Не пиши `latest` без номера версии, источника и даты проверки.
 8. **Не усиливай требования догадками.** Отделяй прямой факт пользователя от вывода: например, хостинг в конкретной стране сам по себе не означает обязательную резидентность данных. Не подтверждённое следствие запиши как открытый вопрос, а не как принятое ограничение.
 
@@ -83,7 +83,7 @@ description: 'Собирает и согласует требования, гр
 
 ### 4. Сохранить стартовый документ
 
-Сохрани `docs/project-starts/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
+Сохрани `docs/artifacts/project-starts/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
 
 ```markdown
 ---
@@ -160,4 +160,4 @@ status: ready-for-prepare-ai
 - Подбирать AI-скилы, агентные роли или MCP.
 - Создавать `docs/rules.md`, `docs/arch.md`, references, `AGENTS.md` или `CLAUDE.md`.
 - Писать код, миграции, конфиги или CI, устанавливать зависимости.
-- Сохранять стартовый документ куда-либо кроме `docs/project-starts/`.
+- Сохранять стартовый документ куда-либо кроме `docs/artifacts/project-starts/`.

package/skills/eda-orhestra/SKILL.md

@@ -51,7 +51,7 @@ orhestra:
 - `steps`: упорядоченный непустой список. Выполняй сверху вниз только элементы с `enabled: true`; отсутствующий `enabled` считай `true`.
 - `id`: уникальное непустое имя шага для ссылок из `on_failure.then`.
 - `skill`: имя установленного `eda-*`-скила. Не разрешай `eda-orhestra`, `eda-aim`, `eda-commit`, `eda-send-review`, `eda-worktree` и `eda-merge-worktree`.
-- `args`: строка, которую нужно дословно добавить к входу этого скилла. Отсутствующее значение считай пустой строкой. Для дефолтного `eda-plan` передавай `без проверок`, чтобы оба вида ревью выполнил следующий `eda-plan-polish`. Для `eda-polish` здесь же задавай штатные `threshold N` и `limit N`; дефолт — `limit 5`.
+- `args`: строка, которую нужно дословно добавить к входу этого скилла. Отсутствующее значение считай пустой строкой. Для дефолтного `eda-plan` передавай `без проверок`, чтобы оба вида ревью выполнил следующий `eda-plan-polish`. Для `eda-polish` здесь же задавай штатный `limit N`; дефолт — `limit 5`.
 - `on_failure`: опциональный обработчик `failed` у шага `eda-manual-test`. Если поля нет, сохрани failed-отчёт и остановись без исправлений.
 - `on_failure.skill` и `on_failure.args`: разрешённый установленный скил исправления и его аргументы; дефолты `eda-fix` и пустая строка. Для `skill` действуют те же запреты, что для `steps[].skill`.
 - `on_failure.then`: id шагов, которые после исправления нужно повторить в указанном порядке. Пропускай отключённые шаги. Список должен содержать id активного `eda-manual-test`, иначе исправление нельзя подтвердить.
@@ -119,7 +119,7 @@ orhestra:
 1. Запусти скилл с подготовленным вводом.
 2. Обработай его вопрос по режиму.
 3. Прочитай сохранённый артефакт и явный статус. `blocked`, неполный обязательный результат или непройденная обязательная проверка останавливают цепочку.
-4. Для `eda-polish` считай успехом только последний полный review со статусом `reviewed` или `reviewed-with-warnings` и `score >= threshold`; отдельного polish-файла нет.
+4. Для `eda-polish` считай успехом только последний полный review со статусом `reviewed` или `reviewed-with-warnings`, `result: clean` и без находок; отдельного polish-файла нет.
 5. Для успешного шага сохрани все пути и передай их следующему.
 
 Если `eda-manual-test` вернул `failed`: