@gian-tiaga/eda 3.4.0 → 3.6.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (14) hide show
  1. package/MIGRATION.md +2 -0
  2. package/README.md +32 -15
  3. package/agents/eda-commit-executor/agent.json +4 -4
  4. package/agents/eda-commit-executor/prompt.md +12 -3
  5. package/lib/install.js +91 -8
  6. package/package.json +1 -1
  7. package/skills/eda-commit/SKILL.md +2 -2
  8. package/skills/eda-commit/skill.json +2 -1
  9. package/skills/eda-manual-test/SKILL.md +110 -54
  10. package/skills/eda-orhestra/SKILL.md +16 -12
  11. package/skills/eda-polish/SKILL.md +2 -1
  12. package/skills/eda-prepare-ai/SKILL.md +20 -7
  13. package/skills/eda-review/SKILL.md +41 -16
  14. package/skills/eda-review/references/review-matrix.md +70 -0
package/skills/eda-manual-test/SKILL.md CHANGED
@@ -1,30 +1,50 @@
1
1
  ---
2
2
  name: eda-manual-test
3
- description: 'Проводит ручную smoke/acceptance-проверку изменённого API или интерфейса и сохраняет отчёт.'
3
+ description: 'Проводит ручную проверку изменений — API, база, консольные команды, интерфейс и алгоритмы — и сохраняет отчёт.'
4
4
  ---
5
5
 
6
6
  # Скил: Ручное тестирование (eda-manual-test)
7
7
 
8
- Делаешь ручную smoke/acceptance-проверку уже сделанных изменений. Проверяешь не «что тесты зелёные», а что пользовательский или API-сценарий реально работает: страница открывается, действие проходит, endpoint отвечает, ошибки выглядят ожидаемо. Сохраняешь QA-отчёт. Код не правишь.
8
+ Делаешь ручную проверку уже сделанных изменений. Проверяешь не «что тесты зелёные», а что всё реально работает: endpoint отвечает, в базе появились нужные записи, команда отрабатывает, страница открывается, алгоритм проходит по всем веткам. Сохраняешь QA-отчёт. Код не правишь.
9
9
 
10
10
  ## Вход из сообщения пользователя
11
11
 
12
12
  Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: URL, endpoint, сценарий, план, ревью, issue, ветку, ограничение по окружению, логин/роль без секретов и прямые указания.
13
13
 
14
- Если входа достаточно, продолжай без вопроса. Если входа нет, построй минимальный smoke-чеклист по незакоммиченному `git diff HEAD`, релевантному коду и документации проекта. `AskUserQuestion` задавай только если цель противоречива, найдено несколько равных окружений/URL, нужна авторизация без доступных тестовых данных или есть риск выполнить разрушительное действие. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
14
+ Если входа достаточно, продолжай без вопроса. Если входа нет, построй чеклист по незакоммиченному `git diff HEAD`, релевантному коду и документации проекта; глубину это не меняет. `AskUserQuestion` задавай только если цель противоречива, найдено несколько равных окружений/URL, нужна авторизация без доступных тестовых данных или есть риск выполнить разрушительное действие. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
15
+
16
+ ## Режим запуска
17
+
18
+ Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
19
+
20
+ Поддерживается только `version: 3`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт `full`; настройки старого формата не применяй.
21
+
22
+ | Настройка | Значения | Аргументы в сообщении |
23
+ |---|---|---|
24
+ | `manual-test.depth` | `full`, `smoke`, `ask_each_time` | `full`, `полная проверка`; `smoke`, `быстро`, `коротко` |
25
+
26
+ Если итоговое значение `ask_each_time`, задай блокирующий вопрос о глубине, кроме случая, когда пользователь уже выбрал её в текущем сообщении.
27
+
28
+ | Глубина | Что проверяется |
29
+ |---|---|
30
+ | `full` | все применимые области матрицы покрытия целиком, по каждому пункту артефакта и diff |
31
+ | `smoke` | запуск, основной happy path изменённой области и 1–2 негативных сценария |
32
+
33
+ `full` — глубина по умолчанию. Отсутствие плана её не снижает: без артефакта области определяются по `git diff HEAD` и всё равно закрываются целиком. Сузить проверку до главного сценария можно только по явному указанию пользователя или настройке. Полнота считается по областям и пунктам, а не по времени и не по числу шагов.
15
34
 
16
35
  ## Главные правила
17
36
 
18
37
  1. **Ручная проверка, не разработка.** Не правь код, не пиши и не обновляй автотесты, не меняй конфиги, не коммить и не пушь.
19
- 2. **Smoke по умолчанию.** Проверь запуск, основной happy path изменённой области и 1–2 негативных или edge-сценария, которые естественно следуют из задачи.
20
- 3. **API проверяй запросами.** Используй `curl`, встроенный HTTP-клиент, Node `fetch` или проектные scripts. Фиксируй method, URL, важные headers без секретов, body, status code и ключевые поля ответа.
21
- 4. **Фронт проверяй браузером.** Если в проекте есть Playwright — используй Playwright. Если Playwright не установлен, используй доступную browser automation хост-агента. Если браузерной автоматизации нет — спроси через `AskUserQuestion`; не устанавливай зависимости молча.
22
- 5. **Серверы поднимай сам, если это очевидно.** Определи команды по `package.json`, README, docker compose, Makefile или локальным инструкциям. Останавливай только процессы, которые сам запустил.
23
- 6. **Секреты не трогай.** Используй только уже доступные локальные `.env`, тестовые аккаунты и настройки. Не проси пользователя прислать секреты в чат и не печатай токены, cookies, passwords, API keys или Authorization headers в отчёт.
24
- 7. **Разрушительное подтверждай.** Реальные платежи, удаление данных, отправку email/SMS/push, изменение production/staging-данных, миграции, очистку БД и похожие действия выполняй только после `AskUserQuestion`.
25
- 8. **Проверяй фактическое поведение.** Не ограничивайся чтением кода. Если сценарий нельзя выполнить, зафиксируй `blocked` и конкретную причину.
26
- 9. **Отчёт обязателен.** Сохрани результат в `docs/artifacts/manual-tests/`, даже если проверка заблокирована или нашла баги.
27
- 10. **Задача важнее дополнительного контекста.** Основной чеклист строй по выполненной задаче: текущему сообщению и явно связанному плану, issue, review или fix-отчёту. Business-карточки подключай только после определения target и только для непосредственно затронутого поведения.
38
+ 2. **В `full` закрываешь каждую область.** У области либо результат фактической проверки, либо явная причина, почему она не затрагивается или заблокирована. Пустых и молча пропущенных областей быть не может.
39
+ 3. **Проверяй фактическое поведение.** Чтение кода, зелёный `npm test` и «должно работать по плану» проверкой не считаются. Если сценарий нельзя выполнить, зафиксируй `blocked` и конкретную причину.
40
+ 4. **API проверяй запросами.** Используй `curl`, встроенный HTTP-клиент, Node `fetch` или проектные scripts. Фиксируй method, URL, важные headers без секретов, body, status code и ключевые поля ответа.
41
+ 5. **Базу проверяй запросами к базе.** Используй psql/mysql/sqlite-клиент, ORM-консоль или проектные скрипты. Проверяй реальные строки, а не ответ API.
42
+ 6. **Фронт проверяй браузером.** Если в проекте есть Playwright — используй Playwright. Если Playwright не установлен, используй доступную browser automation хост-агента. Если браузерной автоматизации нет — спроси через `AskUserQuestion`; не устанавливай зависимости молча.
43
+ 7. **Серверы поднимай сам, если это очевидно.** Определи команды по `package.json`, README, docker compose, Makefile или локальным инструкциям. Останавливай только процессы, которые сам запустил.
44
+ 8. **Секреты не трогай.** Используй только уже доступные локальные `.env`, тестовые аккаунты и настройки. Не проси пользователя прислать секреты в чат и не печатай токены, cookies, passwords, API keys или Authorization headers в отчёт.
45
+ 9. **Разрушительное подтверждай.** Реальные платежи, удаление данных, отправку email/SMS/push, изменение production/staging-данных, откат миграций, очистку БД и похожие действия выполняй только после `AskUserQuestion`.
46
+ 10. **Отчёт обязателен.** Сохрани результат в `docs/artifacts/manual-tests/`, даже если проверка заблокирована или нашла баги.
47
+ 11. **Задача важнее дополнительного контекста.** Основной чеклист строй по выполненной задаче: текущему сообщению и явно связанному плану, issue, review или fix-отчёту. Business-карточки подключай только после определения target и только для непосредственно затронутого поведения.
28
48
 
29
49
  ## Интерактивные вопросы
30
50
 
@@ -36,56 +56,70 @@ description: 'Проводит ручную smoke/acceptance-проверку и
36
56
 
37
57
  ## Этапы
38
58
 
39
- ### 1. Определить цель проверки
40
- Разбери вход пользователя и зафиксируй `$TASK_CONTEXT`: что было сделано и какие результаты пользователь ожидает проверить. Если указан файл плана, ревью, research, issue, fix-отчёт или другой артефакт — прочитай его. Это главный источник сценариев и критериев. Если входа нет, изучи `git diff HEAD`, изменённые файлы, README и релевантные роуты/страницы/компоненты.
59
+ ### 1. Определить цель и глубину
60
+ Разбери вход пользователя и зафиксируй `$TASK_CONTEXT`: что было сделано и какие результаты пользователь ожидает проверить. Если указан файл плана, ревью, research, issue, fix- или execution-отчёт — прочитай его целиком. Это главный источник сценариев и критериев. Если входа нет, изучи `git diff HEAD`, изменённые файлы, README и релевантные роуты/страницы/компоненты.
41
61
 
42
- Определи `$TEST_TARGET`: `api`, `frontend`, `fullstack` или `other`. Если цель всё ещё неоднозначна и можно проверить не то окружение или не тот сценарий — спроси через `AskUserQuestion`.
62
+ Определи глубину по разделу «Режим запуска» и `$TEST_TARGET`: `api`, `frontend`, `fullstack`, `cli` или `other`. Если цель всё ещё неоднозначна и можно проверить не то окружение или не тот сценарий — спроси через `AskUserQuestion`.
43
63
 
44
64
  ### 2. Прочитать рамку проекта
45
- Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Найди команды запуска, тестовые URL, API-контракты, seed/test users и ограничения окружения в README, package scripts, docker compose, Makefile, OpenAPI/Swagger/Postman-файлах и существующих e2e-тестах.
65
+ Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Найди команды запуска, тестовые URL, API-контракты, миграции, консольные команды, seed/test users и ограничения окружения в README, package scripts, docker compose, Makefile, OpenAPI/Swagger/Postman-файлах и существующих e2e-тестах.
46
66
 
47
- После определения `$TASK_CONTEXT` и фактически изменённого поведения прочитай `docs/business.md`, если индекс существует. По описаниям выбери только карточки, которые прямо относятся к проверяемой задаче. Если таких карточек нет, продолжай без business-контекста и без предупреждения. Не открывай остальные карточки и не расширяй ими smoke-проверку.
67
+ После определения `$TASK_CONTEXT` и фактически изменённого поведения прочитай `docs/business.md`, если индекс существует. По описаниям выбери только карточки, которые прямо относятся к проверяемой задаче. Если таких карточек нет, продолжай без business-контекста и без предупреждения. Не открывай остальные карточки.
48
68
 
49
69
  Если ожидаемый результат задачи противоречит применимой business-карточке, не выбирай правильный вариант самостоятельно. До неоднозначного сценария покажи конфликт и через `AskUserQuestion` спроси: проверять изменённую задачу как новое правило или сначала пересогласовать карточку через `eda-business`. В неинтерактивном режиме зафиксируй `blocked` с этим вопросом.
50
70
 
51
71
  Не устанавливай Playwright, браузеры, пакеты, docker images или системные зависимости молча. Если без этого проверка невозможна — спроси через `AskUserQuestion` или зафиксируй `blocked` в неинтерактивном режиме.
52
72
 
53
- ### 3. Составить smoke-чеклист
54
- Составь короткий чеклист:
55
- - запуск приложения или API;
56
- - явные acceptance criteria и сценарии выполненной задачи;
57
- - основной happy path изменённой области;
58
- - 1–2 негативных или edge-сценария, которые следуют из задачи;
59
- - для фронта: console errors, network errors и видимые regressions на основной странице;
60
- - для API: status code, схема/ключевые поля ответа, обработка неверного ввода или прав доступа, если это относится к задаче.
73
+ ### 3. Разложить задачу на сценарии
74
+ Если дан план или другой артефакт, разбери его по разделам и переведи каждый пункт в проверяемый сценарий. Ни один раздел не остаётся без сценариев.
61
75
 
62
- Применимая business-карточка может добавить важный инвариант, ожидаемый результат или один релевантный негативный сценарий, который задача не сформулировала явно. Она не заменяет критерии задачи и не требует тестировать всю предметную область. Не расширяй проверку до полного exploratory QA, если пользователь не попросил.
63
-
64
- ### 4. Запустить окружение
65
- Если приложение ещё не запущено и команды очевидны, запусти нужные dev/API-серверы. Дождись готовности по логам, healthcheck, открытому порту или успешному запросу. Если порт занят, проверь, подходит ли уже запущенный сервис; если нет — спроси или выбери очевидный альтернативный порт только когда проект это поддерживает.
76
+ | Раздел артефакта | Что из него обязательно проверить |
77
+ |---|---|
78
+ | Задача, критерии готовности | каждый заявленный результат — отдельным сценарием |
79
+ | Целевой алгоритм | каждый путь от входного события до финального состояния, включая ошибочные ветки |
80
+ | Контракты: Данные и БД | каждую таблицу, поле, связь, индекс, unique и миграцию |
81
+ | Контракты: API и внешние контракты | каждый новый и изменённый endpoint, событие, очередь, внешний вызов |
82
+ | Фазы выполнения | `Результат` и `Проверка` каждой фазы |
83
+ | Тесты | сценарии из плана, выполненные руками, а не запуском автотестов |
84
+ | Логирование | что пишется в лог по сценарию и что писать запрещено |
85
+ | Документация и эксплуатация | новые env, миграции, консольные команды, шаги релиза |
86
+ | Принятые решения | видимые последствия решения в работающей системе |
87
+
88
+ Дополни сценариями из фактического `git diff HEAD`: изменения, которых нет в артефакте, тоже проверяются. Если артефакта нет, весь набор сценариев строится по diff тем же способом — по затронутым endpoints, миграциям, командам, экранам и ветвлениям кода. Применимая business-карточка может добавить важный инвариант или релевантный негативный сценарий. Она не заменяет критерии задачи и не требует тестировать всю предметную область.
89
+
90
+ ### 4. Собрать матрицу покрытия
91
+ Для `full` пройди все области. Каждая получает статус `✓ проверено`, `✗ провалено`, `— не затрагивается` с причиной или `? blocked` с причиной.
92
+
93
+ | Область | Что проверяется |
94
+ |---|---|
95
+ | API | все новые и затронутые endpoints: успешный ответ и его поля, валидация неверного ввода, права и auth, несуществующая сущность, коды ошибок, обратная совместимость старых клиентов |
96
+ | База данных | миграции применяются без ошибок; схема совпадает с планом (таблицы, колонки, типы, nullable, default, связи, индексы, unique); после сценария появились, обновились и удалились именно те строки с теми значениями; связанные записи и каскады; нет дублей и осиротевших записей; старые данные читаются |
97
+ | Консольные команды | каждая новая и изменённая команда: запуск с аргументами, поведение без аргументов, exit code, вывод, эффект в базе, повторный запуск |
98
+ | Интерфейс | каждый новый и изменённый экран: основной сценарий до результата, состояния загрузки, пустых данных, ошибки и успеха, валидация форм, видимость по ролям, отсутствие console/network errors, вёрстка на desktop и mobile, если менялась |
99
+ | Алгоритмы | сквозной проход по целевому алгоритму: каждая ветка условий, переход состояний, граничные значения, ошибочные пути и откаты |
100
+ | Фон и интеграции | очереди, воркеры, cron, вебхуки, письма и уведомления, события между модулями: задача ставится, выполняется и даёт ожидаемый эффект |
101
+ | Права и роли | что доступ есть у кого положено и его нет у остальных — на API и в интерфейсе |
102
+ | Конфигурация | новые env-переменные и настройки: значение по умолчанию, поведение при отсутствии и при выключенной фиче |
103
+ | Логи и ошибки | по сценарию пишутся ожидаемые записи с нужными полями; в логах и ответах нет секретов и stack traces наружу |
104
+ | Регрессии рядом | соседние сценарии, которые используют изменённый код или таблицы, продолжают работать |
105
+
106
+ В `smoke` глубоко проверяется только основной сценарий изменённой области; остальные области помечаются `— не проверялось в smoke`.
107
+
108
+ ### 5. Запустить окружение
109
+ Если приложение ещё не запущено и команды очевидны, запусти нужные dev/API-серверы, воркеры и базу. Дождись готовности по логам, healthcheck, открытому порту или успешному запросу. Если порт занят, проверь, подходит ли уже запущенный сервис; если нет — спроси или выбери очевидный альтернативный порт только когда проект это поддерживает.
66
110
 
67
111
  Фиксируй команды запуска в черновике отчёта. Не заверши свой ответ, пока запущенные тобой процессы, нужные только для проверки, ещё работают.
68
112
 
69
- ### 5. Проверить API
70
- Для API-сценариев выполни реальные запросы. Предпочитай воспроизводимые команды `curl`, но можно использовать Node `fetch` или проектный HTTP-клиент, если так безопаснее.
71
-
72
- Проверяй:
73
- - успешный status code и ключевые поля ответа;
74
- - корректную ошибку для неверного ввода, отсутствующих прав или несуществующей сущности, если это относится к задаче;
75
- - отсутствие явных server errors, stack traces и утечек секретов в ответе.
113
+ ### 6. Выполнить проверки
114
+ Иди по областям матрицы. Для каждого сценария сохраняй воспроизводимый способ проверки и фактический результат.
76
115
 
77
- Секретные headers и cookies в отчёт не вставляй: пиши `<redacted>`.
116
+ - **API.** Выполняй реальные запросы, предпочитая воспроизводимые команды `curl`. Секретные headers и cookies пиши как `<redacted>`.
117
+ - **База.** После каждого сценария, который меняет данные, смотри в базу запросом и сверяй значения с контрактом. Схему сверяй отдельно от данных. Откат миграции проверяй только по подтверждению пользователя и только если состояние можно восстановить.
118
+ - **Консоль.** Запускай команды в тестовом окружении и проверяй не только вывод, но и эффект.
119
+ - **Фронт.** Открывай страницу в браузере и проверяй фактический UI, а не только DOM-текст. Скриншоты сохраняй, если инструмент это поддерживает и они подтверждают результат или баг: рядом с отчётом или в `docs/artifacts/manual-tests/assets/`.
120
+ - **Алгоритмы.** Для каждой ветки укажи, каким входом ты её вызвал и в каком состоянии система оказалась.
78
121
 
79
- ### 6. Проверить фронт
80
- Для фронтовых сценариев открой страницу в браузере. Если доступен Playwright, используй его для навигации, кликов, ввода и проверок. Если доступен browser plugin или другой инструмент браузерной автоматизации — используй его. Проверяй фактический UI, а не только DOM-текст.
81
-
82
- Проверяй:
83
- - страница загружается без критических console/network errors;
84
- - основной сценарий пользователя проходит до ожидаемого результата;
85
- - видимые состояния ошибок, пустых данных или невалидного ввода, если они относятся к задаче;
86
- - текст и элементы управления не ломаются на очевидном desktop/mobile viewport, если менялась вёрстка.
87
-
88
- Скриншоты сохраняй только если инструмент это поддерживает и они помогают подтвердить результат или баг. Складывай их рядом с отчётом или в подпапку `docs/artifacts/manual-tests/assets/`.
122
+ Если область нельзя проверить, не заменяй её чтением кода: ставь `? blocked` и пиши, чего конкретно не хватает.
89
123
 
90
124
  ### 7. Сохранить отчёт
91
125
  Сохрани отчёт в `docs/artifacts/manual-tests/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
@@ -93,8 +127,9 @@ description: 'Проводит ручную smoke/acceptance-проверку и
93
127
  ```markdown
94
128
  ---
95
129
  date: <YYYY-MM-DD HH:MM>
130
+ depth: <full | smoke>
96
131
  source: <text | git diff HEAD | docs/artifacts/plans/... | docs/artifacts/reviews/...>
97
- target: <api | frontend | fullstack | other>
132
+ target: <api | frontend | fullstack | cli | other>
98
133
  status: <passed | failed | blocked>
99
134
  ---
100
135
 
@@ -111,16 +146,34 @@ status: <passed | failed | blocked>
111
146
  |---|---|
112
147
  | Команды запуска | `<command>` |
113
148
  | URL / endpoint | `<url или endpoint>` |
149
+ | База | `<как проверялась>` |
114
150
  | Авторизация | `<не нужна | тестовый пользователь | уже настроена | blocked>` |
115
151
 
152
+ ## Покрытие
153
+ | Область | Статус | Комментарий |
154
+ |---|---|---|
155
+ | API | ✓ / ✗ / — / ? | <что проверено или почему нет> |
156
+ | База данных | | |
157
+ | Консольные команды | | |
158
+ | Интерфейс | | |
159
+ | Алгоритмы | | |
160
+ | Фон и интеграции | | |
161
+ | Права и роли | | |
162
+ | Конфигурация | | |
163
+ | Логи и ошибки | | |
164
+ | Регрессии рядом | | |
165
+
116
166
  ## Чеклист
117
- | # | Сценарий | Способ проверки | Результат | Заметки |
118
- |---|----------|-----------------|-----------|---------|
119
- | 1 | ... | `curl ...` / Playwright / browser | ✓ / ✗ / ? | ... |
167
+ | # | Область | Сценарий | Способ проверки | Результат | Заметки |
168
+ |---|---------|----------|-----------------|-----------|---------|
169
+ | 1 | API | ... | `curl ...` / SQL / Playwright / команда | ✓ / ✗ / ? | ... |
120
170
 
121
171
  ## Найденные проблемы
122
172
  <если нет — «Явных проблем не найдено»; если есть — список с воспроизведением и фактическим/ожидаемым результатом>
123
173
 
174
+ ## Не проверено
175
+ <области и пункты артефакта, оставшиеся без фактической проверки, с причиной; если таких нет — «нет»>
176
+
124
177
  ## Артефакты
125
178
  <ссылки на скриншоты, логи или «Нет»>
126
179
 
@@ -128,16 +181,19 @@ status: <passed | failed | blocked>
128
181
  <passed / failed / blocked и короткое объяснение относительно выполненной задачи>
129
182
  ```
130
183
 
131
- Если найден баг, статус отчёта `failed`. Если проверка невозможна из-за окружения, авторизации, отсутствующих зависимостей или непонятного риска, статус `blocked`.
184
+ `passed` ставится только когда все применимые области закрыты фактической проверкой и проблем нет. Найден баг — `failed`. Есть незакрытая область или проверка невозможна из-за окружения, авторизации, зависимостей или риска — `blocked`, даже если остальное прошло.
132
185
 
133
186
  ### 8. Финал
134
- Короткое сообщение: путь к отчёту, итог `passed` / `failed` / `blocked`, какие сценарии реально проверены, какие процессы остановлены, состояние git («не закоммичено»). Если итог `failed` или `blocked` — предложи дальше `eda-fix`. Если итог `passed` — предложи дальше `eda-review` или `eda-commit`.
187
+ Короткое сообщение: путь к отчёту, итог `passed` / `failed` / `blocked`, глубина, какие области закрыты и какие нет, какие процессы остановлены, состояние git («не закоммичено»). Если итог `failed` или `blocked` — предложи дальше `eda-fix`. Если итог `passed` — предложи дальше `eda-review` или `eda-commit`.
135
188
 
136
189
  ## Чего НЕ делать
137
190
  - Править код, конфиги, миграции, seed-данные или документацию проекта, кроме отчёта в `docs/artifacts/manual-tests/`.
138
191
  - Писать или обновлять unit/e2e/autotests. Это работа `eda-fix`, `eda-plan-execute` или отдельной задачи.
192
+ - Сводить проверку по плану к smoke-проходу основного сценария.
193
+ - Закрывать область чтением кода, ссылкой на автотесты или словами «по плану должно работать».
194
+ - Ставить `passed`, пока хотя бы одна применимая область не закрыта фактической проверкой.
139
195
  - Устанавливать Playwright, браузеры, npm-пакеты, docker images или системные зависимости без явного подтверждения.
140
- - Подменять ручную проверку запуском `npm test` без фактического прохождения API/UI-сценария.
196
+ - Подменять ручную проверку запуском `npm test` без фактического прохождения сценария.
141
197
  - Проверять production или staging с изменением данных без подтверждения пользователя.
142
198
  - Сохранять секреты, cookies, токены или passwords в отчёт.
143
199
  - Коммитить, пушить, создавать PR или отправлять ревью.
package/skills/eda-orhestra/SKILL.md CHANGED
@@ -11,11 +11,12 @@ description: 'Выполняет настраиваемую цепочку `eda-
11
11
 
12
12
  Прочитай только раздел `orhestra` из `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее любого поля настроек.
13
13
 
14
- Поддерживается только `version: 3`. При другой версии, отсутствующем `orhestra.steps` или невалидном значении используй дефолты ниже; настройки старого формата не применяй. Дефолт режима: `orhestra.mode: automatic`.
14
+ Поддерживается только `version: 3`. При другой версии, отсутствующем `orhestra.steps` или невалидном значении используй дефолты ниже; настройки старого формата не применяй. Дефолты: `orhestra.mode: automatic`, `orhestra.execution: subagents`.
15
15
 
16
16
  ```yaml
17
17
  orhestra:
18
18
  mode: automatic
19
+ execution: subagents
19
20
  steps:
20
21
  - id: plan
21
22
  skill: eda-plan
@@ -48,6 +49,7 @@ orhestra:
48
49
  Правила схемы:
49
50
 
50
51
  - `mode`: только `automatic` или `manual`; дефолт `automatic`.
52
+ - `execution`: `subagents`, `single` или `single_propagated`; дефолт `subagents`.
51
53
  - `steps`: упорядоченный непустой список. Выполняй сверху вниз только элементы с `enabled: true`; отсутствующий `enabled` считай `true`.
52
54
  - `id`: уникальное непустое имя шага для ссылок из `on_failure.then`.
53
55
  - `skill`: имя установленного `eda-*`-скила. Не разрешай `eda-orhestra`, `eda-aim`, `eda-commit`, `eda-send-review`, `eda-worktree` и `eda-merge-worktree`.
@@ -63,7 +65,9 @@ orhestra:
63
65
 
64
66
  ## Вход из сообщения пользователя
65
67
 
66
- Сохрани весь текст рядом с вызовом в `$USER_REQUEST`. Извлеки задачу, пути к готовым артефактам, режим и разовые изменения цепочки.
68
+ Сохрани весь текст рядом с вызовом в `$USER_REQUEST`. Извлеки задачу, пути к готовым артефактам, режим вопросов, режим исполнения и разовые изменения цепочки.
69
+
70
+ Явные `subagents`, `single` или `single_propagated` рядом с вызовом `eda-orhestra` задают `$EXECUTION` только для текущего запуска и важнее настроек. Поддерживай также формулировки «одним агентом» для `single` и «одним агентом с передачей» для `single_propagated`. Не принимай режим, явно адресованный отдельному шагу, за режим самого оркестратора.
67
71
 
68
72
  Поддерживай естественные overrides: `без полировки плана`, `без полировки кода`, `полировка кода 2 итерации`, `без ручных тестов`, `только plan и execute`, `plan-polish threshold 95 limit 3`, `для manual-test <args>`. Явное перечисление порядка заменяет порядок из настроек; локальное включение, отключение или параметры меняют только названный шаг. Фразу `полировка кода N итераций` нормализуй в `limit N` внутри `args` шага `eda-polish`; аналогичную фразу о плане — в `args` шага `eda-plan-polish`. Не принимай слово из описания самой задачи за override без явной связи с цепочкой.
69
73
 
@@ -71,10 +75,10 @@ orhestra:
71
75
 
72
76
  ## Подготовка цепочки
73
77
 
74
- 1. Нормализуй настройки и overrides в `$STEPS` с `id`, `skill`, `enabled` и `args`.
78
+ 1. Определи `$EXECUTION` по явному режиму оркестратора, затем по `orhestra.execution`, иначе `subagents`; нормализуй настройки и overrides в `$STEPS` с `id`, `skill`, `enabled` и `args`.
75
79
  2. Проверь уникальность id, наличие скилов, `on_failure`-инварианты и положительные числовые лимиты. Неизвестный id в `on_failure.then`, запрещённый скилл, handler без повторного manual-test, пустая активная цепочка или отсутствующий установленный скилл — `blocked: некорректная конфигурация orhestra` с точным полем.
76
80
  3. Не исправляй подозрительный порядок молча. Если шаг очевидно требует ещё не созданный артефакт, в automatic остановись только когда вход нельзя безопасно получить из `$USER_REQUEST` или предыдущих результатов; в manual задай один вопрос о порядке или входе.
77
- 4. Сформируй для каждого шага итоговый ввод: `$USER_REQUEST` + пути ко всем артефактам предыдущих шагов + `args`.
81
+ 4. Сформируй для каждого шага итоговый ввод: задача из `$USER_REQUEST` без orchestration-only указания `$EXECUTION` + пути ко всем артефактам предыдущих шагов + `args`. Явно адресованный режим отдельного шага сохрани.
78
82
  5. Прямые параметры текущего вызова всегда ставь выше противоречащих `args` и настроек.
79
83
 
80
84
  ## Режимы и вопросы
@@ -104,15 +108,14 @@ orhestra:
104
108
  ## Вызов вложенных скилов
105
109
 
106
110
  1. Загружай установленный `SKILL.md` каждого шага как источник правды. Не копируй его процедуру в этот скилл.
107
- 2. Каждый активный шаг запускай в отдельном изолированном субагенте. Это обязательно и для составных скилов с собственными субагентами, включая `eda-plan`, `eda-plan-polish`, `eda-polish` и `eda-review`.
108
- 3. Изоляция означает свежий контекст без наследования истории текущего диалога. Передавай субагенту только рабочую директорию, имя скилла, подготовленный итоговый ввод и пути к нужным артефактам. В Codex используй `spawn_agent` с `fork_turns: "none"` или точный аналог; в Claude Code — новый `Agent` с самодостаточным task-сообщением.
109
- 4. Субагент шага сам загружает его `SKILL.md`, выполняет весь контракт скилла и при необходимости запускает его штатных нативных субагентов. Основной оркестратор только готовит ввод, передаёт ответы человека, проверяет статус и связывает артефакты; содержательную работу этапа он не выполняет.
110
- 5. Каждый повтор шага и каждый `on_failure.skill` считай новым вызовом: запускай его в новом изолированном субагенте с полным актуальным входом.
111
- 6. Если чистый контекст, субагент этапа или нужная составному скилу вложенная делегация недоступны, остановись с `blocked: недоступна изоляция этапа`. Не выполняй этап основным агентом и не вводи новый CLI-fallback, которого нет в инструкции вызываемого скилла.
111
+ 2. В `single_propagated` добавь `single` к итоговому вводу только совместимых шагов `eda-plan-execute`, `eda-polish` и `eda-review`, если пользователь не задал этому шагу собственный режим. Не передавай его другим скилам: `eda-polish` уже передаст режим своему `eda-review`, а остальные продолжат по собственному контракту.
112
+ 3. В `subagents` каждый активный шаг, повтор и `on_failure.skill` запускай в отдельном изолированном субагенте. Передавай только рабочую директорию, имя скилла, итоговый ввод и пути к нужным артефактам. В Codex используй `spawn_agent` с `fork_turns: "none"` или точный аналог; в Claude Code — новый `Agent` с самодостаточным task-сообщением.
113
+ 4. В `single` и `single_propagated` выполняй контракт каждого активного шага, повтора и `on_failure.skill` сам в текущем контексте, строго последовательно. Не создавай для них верхнеуровневых субагентов; собственные правила вложенной делегации вызываемого скилла сохраняются.
114
+ 5. Не переключай `$EXECUTION` автоматически. В `subagents` при недоступной изоляции остановись с `blocked: недоступна изоляция этапа`; в single-режимах блокируйся только тогда, когда обязательная вложенная делегация недоступна по контракту самого шага.
112
115
 
113
116
  ## Технические остановки субагентов
114
117
 
115
- Техническую ошибку инструмента субагентов не смешивай со статусами `failed` и `blocked` содержательного контракта. Сохрани полный исходный текст ошибки и обработай её по причине:
118
+ В `subagents` техническую ошибку инструмента субагентов не смешивай со статусами `failed` и `blocked` содержательного контракта. Сохрани полный исходный текст ошибки и обработай её по причине:
116
119
 
117
120
  - лимит параллельности или отсутствие свободного слота — дождись уже запущенного этим workflow агента, при необходимости закрой завершённые потоки и повтори тот же запуск; если управляемых активных агентов нет, заверши `blocked: заняты слоты субагентов`;
118
121
  - лимит глубины вложения — не повторяй запуск и не выполняй этап сам; заверши `blocked: достигнут лимит глубины субагентов`, указав наблюдаемую и требуемую глубину;
@@ -148,13 +151,14 @@ orhestra:
148
151
 
149
152
  ## Финал
150
153
 
151
- Сообщи режим, фактически выполненную цепочку с args и лимитами, пропущенные шаги и причины, пути ко всем артефактам, последний review score при наличии, результат manual-test при наличии, число QA-циклов и состояние git «не закоммичено».
154
+ Сообщи режим вопросов, `$EXECUTION`, переданные вложенным шагам overrides, фактически выполненную цепочку с args и лимитами, пропущенные шаги и причины, пути ко всем артефактам, последний review score при наличии, результат manual-test при наличии, число QA-циклов и состояние git «не закоммичено».
152
155
 
153
156
  Успех означает, что все включённые шаги завершились по собственным контрактам. Если manual-test был включён, после последних изменений обязателен `passed`; если он отключён, явно напиши «ручные тесты пропущены настройкой». Если отключён `eda-plan-polish`, явно напиши «полировка плана пропущена настройкой». Если отключён `eda-polish`, явно напиши «полировка кода пропущена настройкой».
154
157
 
155
158
  ## Чего НЕ делать
156
159
 
157
- - Выполнять содержательную работу вместо настроенного скилла.
160
+ - Обходить или сокращать контракт настроенного скилла из-за выбранного режима исполнения.
161
+ - Передавать `single` скилам вне allowlist `eda-plan-execute`, `eda-polish`, `eda-review`.
158
162
  - Запускать отключённый или отсутствующий в цепочке шаг, кроме явно настроенного `on_failure.skill`.
159
163
  - Терять `args`, порядок или пути к артефактам при передаче.
160
164
  - Считать автоматические тесты заменой включённого `eda-manual-test`.
package/skills/eda-polish/SKILL.md CHANGED
@@ -9,7 +9,7 @@ description: 'Итеративно ревьюит и исправляет изм
9
9
 
10
10
  ## Вход из сообщения пользователя
11
11
 
12
- Текст рядом с вызовом скилла в текущем сообщении — главный вход. Разбери target, путь к плану, PR/ветку/diff/файл, лимит итераций и ограничения. Передавай в каждый `eda-review` разовые overrides проверок и моделей из запроса пользователя.
12
+ Текст рядом с вызовом скилла в текущем сообщении — главный вход. Разбери target, путь к плану, PR/ветку/diff/файл, лимит итераций и ограничения. Передавай в каждый `eda-review` разовый режим `subagents` или `single`, overrides проверок и моделей из запроса пользователя.
13
13
 
14
14
  Лимит по умолчанию — `5` итераций; пользователь может задать `limit N` положительным целым числом. Порога у цикла нет: устаревшие `threshold N`, `до 90` и `цель 90` не применяй и скажи об этом в финале.
15
15
 
@@ -52,6 +52,7 @@ description: 'Итеративно ревьюит и исправляет изм
52
52
  ```text
53
53
  Используй eda-review для <TARGET_CONTEXT>.
54
54
  План: <PLAN_FILE | none>.
55
+ Режим исполнения review: <single | subagents | из настроек>.
55
56
  Overrides проверок и моделей: <из запроса | none>.
56
57
  Ранее отклонённые находки: <предыдущий review file и fix report | none>.
57
58
  Верни путь к файлу, status, result, score, находки и coverage.
package/skills/eda-prepare-ai/SKILL.md CHANGED
@@ -15,7 +15,7 @@ description: 'Готовит проект к работе с AI: проекти
15
15
 
16
16
  1. **Не правишь код.** Меняй только `docs/rules.md`, `docs/arch.md`, `docs/references.md`, `docs/references/*.md`, `AGENTS.md` и `CLAUDE.md`; не ставь пакеты и не меняй конфиги.
17
17
  2. **Опирайся на проект.** Читай код, структуру, зависимости, команды, тесты, инфраструктуру, git-историю и существующие документы. Не генерируй универсальный шаблон.
18
- 3. **Разделяй документы по назначению.** Business-карточки задают подтверждённое целевое поведение и редактируются только через `eda-business`; `docs/rules.md` задаёт проверяемые обязанности и запреты при работе над проектом; `docs/arch.md` фиксирует устройство, границы и владение ответственностью; references показывают уже устоявшуюся форму реализации; `AGENTS.md` объясняет, что это за проект и где читать обязательную рамку. Архитектурное решение не становится правилом только потому, что его удалось сформулировать как запрет.
18
+ 3. **Разделяй документы по назначению.** Business-карточки задают подтверждённое целевое поведение и редактируются только через `eda-business`; `docs/rules.md` задаёт действия, запреты, команды проверки и требования к процессу, совместимости и безопасности; `docs/arch.md` фиксирует структуру исходного кода, назначение каталогов, модули и слои, ownership, зависимости, runtime/data-flow, данные и интеграции; references показывают уже устоявшуюся форму реализации; `AGENTS.md` объясняет, что это за проект и где читать обязательную рамку. У каждого факта должен быть ровно один документ-владелец: допустима ссылка на другой документ, но не вторая копия содержания даже в иной формулировке. Архитектурное решение не становится правилом только потому, что его удалось сформулировать как запрет.
19
19
  4. **Обновляй осмысленно.** Сохраняй актуальное, исправляй неверное, удаляй устаревшее и перестраивай документ настолько сильно, насколько требует проект. Не спрашивай отдельно, что делать с каждым существующим файлом.
20
20
  5. **Не выдавай предположение за факт.** Значимые неподтверждённые архитектурные решения предложи пользователю; после выбора зафиксируй принятый вариант.
21
21
  6. **Предлагай экстремальный профиль проверок.** Не ограничивайся уже установленными командами или базовыми lint/test. Пройди весь каталог ниже, предложи все применимые проверки и объясни каждое `не применимо`; в документацию переноси только подтверждённые правила.
@@ -125,20 +125,29 @@ description: 'Готовит проект к работе с AI: проекти
125
125
  В `docs/rules.md` уместны:
126
126
 
127
127
  - обязательные команды и момент их запуска;
128
- - действующие соглашения об именовании, формате, размещении и совместимости;
128
+ - действующие соглашения об именовании, формате и совместимости;
129
129
  - требования к изменениям, например обязательная миграция при изменении схемы или обновление контракта при изменении публичного API;
130
130
  - точечные запреты небезопасных конструкций, бесконтрольных подавлений, утечки секретов и персональных данных;
131
131
  - строгие режимы уже внедрённых инструментов.
132
132
 
133
+ Пути допустимы в `docs/rules.md` только как операнды точных команд или указатели на конфиги и создаваемые артефакты. Не описывай в `docs/rules.md` топологию исходного кода, назначение каталогов, размещение компонентов или границы модулей.
134
+
133
135
  Не помещай в `docs/rules.md`:
134
136
 
135
137
  - выбор архитектурного подхода, слоёв, модулей и CQRS;
138
+ - дерево и топологию исходного кода, назначение каталогов и размещение компонентов;
136
139
  - владение данными и ответственностью, направления зависимостей, transaction boundaries, persistence boundaries, trust boundaries и runtime/data-flow;
137
140
  - решение, в каком слое выполняются валидация, преобразование типов, авторизация или управление транзакцией;
138
141
  - форму controller, handler, repository, DTO, entity, теста, атрибута или другого компонента;
139
142
  - желаемое будущее состояние, рекомендации и правила для ещё не внедрённых инструментов.
140
143
 
141
- Если утверждение определяет, **где** находится ответственность или **какая часть системы** может зависеть от другой, запиши его в `docs/arch.md`, даже если его можно переписать как «не вызывай X из Y». Если утверждение показывает, **как именно выглядит код**, оно относится к применимой reference-карточке. Не дублируй одно решение в нескольких документах.
144
+ Если утверждение определяет, **где** находится ответственность или **какая часть системы** может зависеть от другой, запиши его в `docs/arch.md`, даже если его можно переписать как «не вызывай X из Y». Если утверждение показывает, **как именно выглядит код**, оно относится к применимой reference-карточке. Если утверждение задаёт **целевое поведение продукта**, оно относится к применимой business-карточке. При дубле перенеси утверждение к единственному владельцу и удали пересказ из остальных документов; не сохраняй вторую копию даже другими словами.
145
+
146
+ Пограничные случаи разделяй так:
147
+
148
+ - запрет зависимости `X → Y` хранится в `docs/arch.md`; обязательный запуск проверки границ хранится в `docs/rules.md` без пересказа самой границы;
149
+ - требование добавить миграцию при изменении схемы хранится в `docs/rules.md`; владение данными и расположение persistence-компонентов — в `docs/arch.md`;
150
+ - путь к конфигу или каталогу артефактов может быть операндом рабочего правила, но путь исходного компонента и его место в системе описываются только в `docs/arch.md`.
142
151
 
143
152
  Используй эту границу для типичных спорных тем:
144
153
 
@@ -164,6 +173,8 @@ description: 'Готовит проект к работе с AI: проекти
164
173
 
165
174
  Опиши устройство проекта, не повторяя рабочие правила из `docs/rules.md`. Документ должен позволять понять, где находится нужная часть системы, за что она отвечает и как связана с остальными.
166
175
 
176
+ `docs/arch.md` не должен содержать команды, чек-листы разработки, настройки линтеров и других инструментов или иные рабочие правила. Если архитектурную границу проверяет конкретная команда, в `docs/arch.md` оставь только саму границу, а требование и момент запуска команды запиши в `docs/rules.md` без пересказа границы.
177
+
167
178
  Включи релевантные проекту сведения:
168
179
  - выбранный архитектурный подход, например модульный монолит, слоистая архитектура или набор сервисов, и коротко почему он подходит проекту;
169
180
  - дерево основных папок с назначением каждой значимой части;
@@ -193,7 +204,7 @@ description: 'Готовит проект к работе с AI: проекти
193
204
 
194
205
  Индекс содержит ссылки только на карточки. В каждой карточке должны быть:
195
206
 
196
- - назначение и границы ответственности компонента;
207
+ - назначение эталона и показываемая форма реализации без пересказа архитектурных границ компонента;
197
208
  - условия, при которых пример применим;
198
209
  - один минимальный, законченный и синтаксически цельный пример в fenced code block с указанием языка;
199
210
  - короткий разбор элементов примера, которые нужно повторять;
@@ -237,9 +248,10 @@ description: 'Готовит проект к работе с AI: проекти
237
248
 
238
249
  Убедись, что:
239
250
  - `docs/rules.md` содержит только лаконичные действующие правила;
240
- - каждое правило задаёт проверяемое действие или запрет, а архитектурные границы не продублированы в форме императива;
241
- - `docs/arch.md` объясняет подход, структуру папок, части системы и их связи без повторения правил;
251
+ - каждое правило задаёт проверяемое действие или запрет, пути используются только как операнды команд или указатели на конфиги и артефакты, а топология исходного кода и архитектурные границы не продублированы в форме императива;
252
+ - `docs/arch.md` объясняет подход, структуру папок, части системы и их связи без команд, чек-листов разработки, tooling-политик и повторения правил;
242
253
  - `docs/references.md` ссылается на все актуальные карточки и не содержит самих примеров;
254
+ - reference-карточки описывают форму реализации, business-карточки — целевое поведение, а архитектурные факты из `docs/arch.md` в них не пересказаны;
243
255
  - существующий `docs/business.md` учтён как вход, не изменён этим скилом и указан в `AGENTS.md`;
244
256
  - каждая карточка самодостаточна, содержит законченный пример кода и не содержит ссылок или неподтверждённых элементов;
245
257
  - для нового проекта без нескольких устойчивых реализаций не созданы выдуманные reference-карточки;
@@ -250,7 +262,8 @@ description: 'Готовит проект к работе с AI: проекти
250
262
  - выбранные инструменты имеют максимальный применимый строгий профиль, а каждое ослабление явно обосновано;
251
263
  - для нового проекта требования, стек и архитектурные драйверы взяты из стартового документа, а архитектура и правила спроектированы внутри `eda-prepare-ai`;
252
264
  - AI-скилы, роли и MCP разделены на уже доступные и требующие отдельного внедрения;
253
- - документы не противоречат проекту и друг другу.
265
+ - у каждого факта есть ровно один документ-владелец, а остальные документы при необходимости только ссылаются на него без пересказа;
266
+ - между документами нет дублей, архитектурных путей в `docs/rules.md`, императивных рабочих инструкций в `docs/arch.md` и противоречий с проектом или друг с другом.
254
267
 
255
268
  ### 13. Финал
256
269