@gian-tiaga/eda 2.1.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,7 +5,7 @@ description: 'Исправляет код по готовому ревью из
 
 # Скил: Исправитель по ревью (eda-fix-by-review)
 
-Берёшь готовое ревью из `docs/reviews/` или сообщения, применяешь все находки к коду и сохраняешь отчёт в `docs/review-fixes/`. После правок выполняешь полный прогон тестов и линтеров.
+Берёшь готовое ревью из `docs/artifacts/reviews/` или сообщения, применяешь все находки к коду и сохраняешь отчёт в `docs/artifacts/review-fixes/`. После правок выполняешь полный прогон тестов и линтеров.
 
 ## Вход из сообщения пользователя
 
@@ -17,11 +17,12 @@ description: 'Исправляет код по готовому ревью из
 
 1. Перед правкой прочитай `docs/rules.md` и `docs/arch.md`. Определи замечания и затронутое поведение; затем через `sources.business` связанного плана или `docs/business.md` выбери только применимые business-карточки, а через `docs/references.md` — только карточки затронутых компонентов.
 2. Применяй все выбранные находки. Не переоценивай их полезность и не превращай исправление в более широкий рефакторинг.
-3. Задавай вопрос только если находка неоднозначна, противоречит коду или обязательной документации, требует продуктового решения, расширяет scope либо ведёт к рискованному действию. В остальных случаях работай автономно.
-4. Не делай новое ревью и не коммить. Только исправляй замечания и пиши отчёт.
-5. Если находка касается поведения, добавь или обнови точечный тест в той же правке и прогони его.
-6. В конце обязательно прогони полный набор тестов и линтеров один раз.
-7. Пиши просто и конкретно; в отчёте используй таблицу.
+3. Отклонить находку можно, только если она фактически неверна: код уже делает требуемое, доказательство не воспроизводится или правка нарушает применимое правило либо архитектуру. Отклонение с причиной запиши в отчёт. Трудоёмкость, вкус и несогласие с формулировкой основанием не являются.
+4. Задавай вопрос только если находка неоднозначна, противоречит коду или обязательной документации, требует продуктового решения, расширяет scope либо ведёт к рискованному действию. В остальных случаях работай автономно.
+5. Не делай новое ревью и не коммить. Только исправляй замечания и пиши отчёт.
+6. Если находка касается поведения, добавь или обнови точечный тест в той же правке и прогони его.
+7. В конце обязательно прогони полный набор тестов и линтеров один раз.
+8. Пиши просто и конкретно; в отчёте используй таблицу.
 
 ## Интерактивные вопросы
 
@@ -39,7 +40,7 @@ description: 'Исправляет код по готовому ревью из
 
 Разбери путь к ревью, название, «последнее ревью», номера находок или вставленный текст. Для текста используй `$REVIEW_SOURCE=review_text`, не выбирай файл и сохраняй отчёт с `review: text`.
 
-Если найден ровно один файл, используй `$REVIEW_SOURCE=review_file`. Если найдено несколько равно подходящих файлов или входа нет, задай один вопрос со списком. Если `docs/reviews/` пуста и текст замечаний не дан, остановись с `blocked: нужно ревью`.
+Если найден ровно один файл, используй `$REVIEW_SOURCE=review_file`. Если найдено несколько равно подходящих файлов или входа нет, задай один вопрос со списком. Если `docs/artifacts/reviews/` пуста и текст замечаний не дан, остановись с `blocked: нужно ревью`.
 
 ### 2. Прочитать контекст
 
@@ -49,7 +50,7 @@ description: 'Исправляет код по готовому ревью из
 
 ### 3. Применить находки
 
-Исправь все находки нового формата либо выбранные пользователем номера. Для старого формата возьми только пункты из `Править обязательно`. Делай минимальную достаточную правку и точечную проверку после каждого логического изменения.
+Исправь все находки нового формата либо выбранные пользователем номера. Для старого формата возьми только пункты из `Править обязательно`. Делай минимальную достаточную правку и точечную проверку после каждого логического изменения. Находку, которая оказалась фактически неверной, не исправляй: запиши её в «Отклонённые находки» с доказательством.
 
 Остановись с вопросом при неоднозначности, конфликте с правилами, архитектурой или business-карточкой, необходимости расширить scope либо выполнить рискованное действие. При конфликте с business-карточкой предложи изменить состав исправлений или сначала пересогласовать правило через `eda-business`. Подтверждённое отклонение от технической карточки зафиксируй в отчёте.
 
@@ -59,18 +60,18 @@ description: 'Исправляет код по готовому ревью из
 
 ### 5. Сохранить отчёт и связать с ревью
 
-Сохрани `docs/review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Если `$REVIEW_SOURCE=review_file`, допиши в конец `$REVIEW_FILE`:
+Сохрани `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`, не дописывай ссылку в исходное ревью: исходного файла нет.
 
 ```markdown
 ---
-review: <docs/reviews/... | text>
+review: <docs/artifacts/reviews/... | text>
 date: <YYYY-MM-DD HH:MM>
 status: done
 ---
@@ -82,6 +83,11 @@ status: done
 |---|-----------|-------|-------|--------|
 | 1 | <кратко из ревью> | `path/a.py` | `path/test_a.py` (2 ✓) | ✓ применено |
 
+## Отклонённые находки
+| # | Замечание | Почему отклонена |
+|---|-----------|------------------|
+| 2 | <кратко из ревью> | <чем подтверждается, что находка неверна> |
+
 ## Финальная проверка
 - **Тесты:** `<команда>` — ✓ / ✗
 - **Линтер:** `<команда>` — ✓ / ✗
@@ -90,14 +96,14 @@ status: done
 
 ### 6. Финал
 
-Короткое сообщение: путь к ревью или «источник: текст из сообщения», путь к fix-отчёту, сколько находок применено, результат финальной проверки и состояние git «не закоммичено». Предложи `eda-commit`.
+Короткое сообщение: путь к ревью или «источник: текст из сообщения», путь к fix-отчёту, сколько находок применено и сколько отклонено, результат финальной проверки и состояние git «не закоммичено». Предложи `eda-commit`.
 
 ## Чего НЕ делать
 
 - Делать само ревью — это `eda-review`.
 - Коммитить или пушить — это `eda-commit`.
-- Выбирать, какие находки достойны исправления: принятая находка уже обязательна.
+- Отклонять находку по вкусу, из-за трудоёмкости или несогласия с формулировкой: основание — только фактическая ошибка находки, и всегда с причиной в отчёте.
 - Расширять scope ради улучшений, которых нет в находках.
 - Гонять полный сьют после каждого пункта или пропускать финальную проверку.
-- Сохранять отчёт вне `docs/review-fixes/`.
+- Сохранять отчёт вне `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`, `result: clean`, без находок и с `score >= threshold`; отдельного polish-файла нет.
+4. Для `eda-polish` считай успехом только последний полный review со статусом `reviewed` или `reviewed-with-warnings`, `result: clean` и без находок; отдельного polish-файла нет.
 5. Для успешного шага сохрани все пути и передай их следующему.
 
 Если `eda-manual-test` вернул `failed`: