@gian-tiaga/eda 3.4.0 → 3.5.0

package/README.md

@@ -55,7 +55,7 @@ eda update-all ~/Code
 | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или плану. Перед правками читает правила, архитектуру и только применимые карточки, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/artifacts/fixes/` |
 | `eda-review` | Оркестрирует отдельные read-only проверки корректности, архитектуры, правил, references, business-правил, плана, качества, тестов, безопасности, производительности, frontend/UI/UX, API, БД, документации и предыдущих ревью. Сохраняет только доказанные дефекты, которые обязательно исправить; косметические и спекулятивные предложения отбрасывает. Любая находка даёт `changes-required`, а чистое ревью — `clean` и 100/100. Без аргументов ревьюит `git diff HEAD` | `docs/artifacts/reviews/` |
 | `eda-fix-by-review` | Применяет все находки из ревью с учётом правил, архитектуры и применимых карточек. Спрашивает только при неоднозначности, конфликте, расширении scope или рискованном действии. В конце ссылается на отчёт прямо в файле ревью | `docs/artifacts/review-fixes/` |
-| `eda-manual-test` | Делает ручную smoke/acceptance-проверку после изменений: основной чеклист строит по выполненной задаче и связанному плану/issue/review/fix-отчёту, затем сверяет фактический diff. Применимая business-карточка может добавить только относящийся к задаче инвариант или сценарий; несвязанные карточки не загружаются. Не правит код, не пишет автотесты и не коммитит | `docs/artifacts/manual-tests/` |
+| `eda-manual-test` | Делает ручную проверку после изменений. По умолчанию проверка полная: разбирает план или другой артефакт по разделам, дополняет его фактическим `git diff HEAD` и закрывает матрицу областей — API, база данных, консольные команды, интерфейс, алгоритмы, фон и интеграции, права и роли, конфигурация, логи, регрессии рядом. Область нельзя закрыть чтением кода или зелёными автотестами; незакрытая область даёт `blocked`. Быстрый smoke включается настройкой `manual-test.depth` или словом в запросе. Применимая business-карточка может добавить только относящийся к задаче инвариант или сценарий. Не правит код, не пишет автотесты и не коммитит | `docs/artifacts/manual-tests/` |
 | `eda-polish` | Оркестрирует доводку изменений: запускает полное `eda-review`, затем `eda-fix-by-review` и повторяет цикл до `clean` и отсутствия находок либо до лимита 5 итераций. Все находки исправляются, score остаётся справочным. Каждый шаг идёт в изолированном нативном субагенте. Не коммитит | `docs/artifacts/reviews/`, `docs/artifacts/review-fixes/` |
 | `eda-send-review` | На `sonnet` / `gpt-5.6-terra` отправляет ревью на GitHub PR через `gh` всегда в едином формате: общий комментарий-сводка плюс комментарии к строкам кода. Без явно указанного типа использует `comment`; `approve` и `request-changes` берёт только из контекста текущего вызова. По настройке может скрыть предыдущие сводки eda-send-review и зарезолвить их inline-треды. По умолчанию шлёт все пункты. Claude-модель закрепляется при установке; Codex-модель хранится как рекомендуемый будущий override | (комментарий в PR) |
 | `eda-commit` | Работает как лёгкий оркестратор одного `haiku` / `gpt-5.6-luna` агента: тот сам собирает git-контекст, делит выбранный состав на логические коммиты, пишет сообщения, точечно коммитит и выполняет явно заданные push/PR/merge-действия. С явным контекстом охватывает указанный состав; без контекста берёт все tracked-изменения и содержательные untracked-файлы, кроме очевидных кэшей и локальных служебных артефактов. В Claude Code сам оркестратор закреплён за `haiku`; в Codex остаётся на активной модели сессии из-за отсутствия per-skill override. При вероятном секрете агент блокируется до индексации затронутой группы. После любого push всегда возвращает ссылку — на существующий PR или на его создание — и спрашивает, создавать ли PR, если его нет. Если продолжение не задано, предлагает применимые варианты | (git, опционально GitHub PR) |
@@ -139,6 +139,7 @@ eda update-all ~/Code
 | `eda-plan-review` | `threshold N` | Разово меняет долю закрытых пунктов, при которой план считается готовым | Для самостоятельного аудита готового плана |
 | `eda-plan-execute` | `subagents` / `single` / `auto` | Разово меняет, где выполняются фазы, поверх `plan-execute.mode` | `single` для небольшого плана в одном контексте, `subagents` для большого или тяжёлого |
 | `eda-plan-polish` | `threshold N`, `limit N` | Меняет gate и максимальное число подтверждающих review-итераций | Для доводки ответственных планов перед `eda-plan-execute` |
+| `eda-manual-test` | `full` / `полная проверка`, `smoke` / `быстро` | Разово меняет глубину ручной проверки поверх `manual-test.depth` | `smoke` для короткой правки, `full` — когда нужно закрыть все области после плана |
 
 ---
 
@@ -237,6 +238,13 @@ plan-execute:
   # subagents — каждая фаза в отдельном субагенте, single — весь план одним контекстом, auto — решает по плану.
   mode: auto
 
+manual-test:
+  # Глубина ручной проверки в eda-manual-test.
+  # full — закрыть все применимые области: API, база, консольные команды, интерфейс, алгоритмы, фон, права, конфигурацию, логи и регрессии рядом.
+  # smoke — только запуск и основной сценарий изменённой области.
+  # full | smoke | ask_each_time
+  depth: full
+
 review:
   # Каждая проверка имеет собственный режим запуска и модели для обеих сред.
   agents:
@@ -386,6 +394,7 @@ discover-automations:
 - `plan-review.threshold` — доля закрытых пунктов чек-листа для статуса `ready`, default `100`. Отдельных агентов у `plan-review` больше нет: проверку целиком делает один субагент.
 - `plan-polish.limit` — максимальное число подтверждающих review-итераций; default `2`. Цикл останавливается раньше, если score перестал расти.
 - `plan-execute.mode` — где `eda-plan-execute` выполняет фазы: `subagents` — каждая фаза в отдельном изолированном субагенте с независимой проверкой, `single` — весь план одним контекстом без субагентов, `auto` — выбор по плану; default `auto`. Явный режим в вызове имеет приоритет.
+- `manual-test.depth` — глубина ручной проверки в `eda-manual-test`: `full` — закрыть все применимые области матрицы покрытия, `smoke` — только запуск и основной сценарий изменённой области, `ask_each_time` — спрашивать каждый раз; default `full`. Явная глубина в вызове имеет приоритет.
 - `review.agents.<check>.mode` — запускать проверку всегда, автоматически по контексту или отключить.
 - `review.agents.<check>.model.claude` и `.codex` — модель конкретной проверки в соответствующей среде.
 - `eda-review` не делит находки по обязательности: каждый принятый пункт требует исправления, а предложения без доказанного практического дефекта отбрасываются. Score остаётся экспертной оценкой серьёзности; любая находка блокирует `clean` независимо от score.
@@ -447,7 +456,7 @@ plan-polish = специализированный plan-review ─> plan-review-
 discover-automations может запускаться от review, fix-by-review или fix.
 ```
 
-`eda-manual-test` обычно ставится после `eda-plan-execute`, `eda-fix` или `eda-fix-by-review`, чтобы руками проверить API/UI перед ревью или коммитом.
+`eda-manual-test` обычно ставится после `eda-plan-execute`, `eda-fix` или `eda-fix-by-review`, чтобы руками проверить API, базу, консольные команды, интерфейс и алгоритмы перед ревью или коммитом.
 
 Использовать всю цепочку не обязательно — каждый скил самодостаточен. Для полного прохода одной задачи можно вызвать `eda-orhestra automatic <задача>` или `eda-orhestra manual <задача>`. Разовые варианты: `eda-orhestra automatic без полировки плана <задача>`, `eda-orhestra полировка кода 2 итерации <задача>`, `eda-orhestra без ручных тестов <задача>`. Постоянный порядок и аргументы задаются в `orhestra.steps`. Новый проект можно начать с `eda-new-project`; существующий — с `eda-prepare-ai`, `eda-roadmap`, `eda-explore`, или сразу с `eda-plan-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны. Для параллельной работы есть `eda-worktree`, а для возврата ветки из worktree в текущую ветку — `eda-merge-worktree`.
 

package/lib/install.js

@@ -277,6 +277,9 @@ const DEFAULT_SETTINGS = {
   planExecute: {
     mode: 'auto'
   },
+  manualTest: {
+    depth: 'full'
+  },
   review: {
     agents: DEFAULT_REVIEW_AGENTS
   },
@@ -295,6 +298,7 @@ const SETTINGS_SECTION_NAMES = [
   'plan-review',
   'plan-polish',
   'plan-execute',
+  'manual-test',
   'review',
   'send-review',
   'discover-automations'
@@ -396,6 +400,20 @@ const PLAN_SIZE_CHOICES = [
     name: 'Спрашивать размер плана каждый раз'
   }
 ];
+const MANUAL_TEST_DEPTH_CHOICES = [
+  {
+    value: 'full',
+    name: 'Полная проверка всех областей: API, база, консоль, интерфейс, алгоритмы'
+  },
+  {
+    value: 'smoke',
+    name: 'Только smoke: запуск и основной сценарий изменённой области'
+  },
+  {
+    value: 'ask_each_time',
+    name: 'Спрашивать глубину проверки каждый раз'
+  }
+];
 const DECISION_MODE_CHOICES = [
   {
     value: 'recommend_and_ask',
@@ -734,7 +752,8 @@ export async function askSettings({
     ['plan', 'plan.loggingStrategy', settings.plan, 'loggingStrategy', 'Какую стратегию логирования eda-plan использовать по умолчанию?', LOGGING_STRATEGY_CHOICES],
     ['plan-review', 'planReview.threshold', settings.planReview, 'threshold', 'Какой порог готовности использовать в eda-plan-review?', PLAN_REVIEW_THRESHOLD_CHOICES],
     ['plan-polish', 'planPolish.limit', settings.planPolish, 'limit', 'Сколько review-итераций разрешить eda-plan-polish?', PLAN_POLISH_LIMIT_CHOICES],
-    ['plan-execute', 'planExecute.mode', settings.planExecute, 'mode', 'Как eda-plan-execute должен выполнять фазы по умолчанию?', PLAN_EXECUTE_MODE_CHOICES]
+    ['plan-execute', 'planExecute.mode', settings.planExecute, 'mode', 'Как eda-plan-execute должен выполнять фазы по умолчанию?', PLAN_EXECUTE_MODE_CHOICES],
+    ['manual-test', 'manualTest.depth', settings.manualTest, 'depth', 'Какую глубину ручной проверки использовать в eda-manual-test по умолчанию?', MANUAL_TEST_DEPTH_CHOICES]
   ];
   for (const [section, key, target, property, message, choices] of scalarPrompts) {
     if (!requestedSections.has(section) || !shouldAsk(key)) continue;
@@ -1176,6 +1195,14 @@ function migrateSettingsContent(content) {
     value => { settings.planExecute.mode = value; }
   );
 
+  const manualTest = objectValue(raw['manual-test']);
+  transfer(
+    'manualTest.depth',
+    manualTest.depth,
+    oneOf(['full', 'smoke', 'ask_each_time']),
+    value => { settings.manualTest.depth = value; }
+  );
+
   const review = objectValue(raw.review);
   transferAgentSettings({
     rawAgents: objectValue(review.agents),
@@ -1400,6 +1427,13 @@ plan-execute:
   # subagents — каждая фаза в отдельном субагенте, single — весь план одним контекстом, auto — решает по плану.
   mode: ${settings.planExecute.mode}
 
+manual-test:
+  # Глубина ручной проверки в eda-manual-test.
+  # full — закрыть все применимые области: API, база, консольные команды, интерфейс, алгоритмы, фон, права, конфигурацию, логи и регрессии рядом.
+  # smoke — только запуск и основной сценарий изменённой области.
+  # full | smoke | ask_each_time
+  depth: ${settings.manualTest.depth}
+
 review:
   # Каждая проверка имеет собственный режим запуска и модели для обеих сред.
   agents:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "3.4.0",
+  "version": "3.5.0",
   "description": "Пакет скилов и специализированных агентов eda-* для Claude Code и Codex CLI",
   "type": "module",
   "bin": {

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

@@ -1,30 +1,50 @@
 ---
 name: eda-manual-test
-description: 'Проводит ручную smoke/acceptance-проверку изменённого API или интерфейса и сохраняет отчёт.'
+description: 'Проводит ручную проверку изменений — API, база, консольные команды, интерфейс и алгоритмы — и сохраняет отчёт.'
 ---
 
 # Скил: Ручное тестирование (eda-manual-test)
 
-Делаешь ручную smoke/acceptance-проверку уже сделанных изменений. Проверяешь не «что тесты зелёные», а что пользовательский или API-сценарий реально работает: страница открывается, действие проходит, endpoint отвечает, ошибки выглядят ожидаемо. Сохраняешь QA-отчёт. Код не правишь.
+Делаешь ручную проверку уже сделанных изменений. Проверяешь не «что тесты зелёные», а что всё реально работает: endpoint отвечает, в базе появились нужные записи, команда отрабатывает, страница открывается, алгоритм проходит по всем веткам. Сохраняешь QA-отчёт. Код не правишь.
 
 ## Вход из сообщения пользователя
 
 Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: URL, endpoint, сценарий, план, ревью, issue, ветку, ограничение по окружению, логин/роль без секретов и прямые указания.
 
-Если входа достаточно, продолжай без вопроса. Если входа нет, построй минимальный smoke-чеклист по незакоммиченному `git diff HEAD`, релевантному коду и документации проекта. `AskUserQuestion` задавай только если цель противоречива, найдено несколько равных окружений/URL, нужна авторизация без доступных тестовых данных или есть риск выполнить разрушительное действие. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+Если входа достаточно, продолжай без вопроса. Если входа нет, построй чеклист по незакоммиченному `git diff HEAD`, релевантному коду и документации проекта; глубину это не меняет. `AskUserQuestion` задавай только если цель противоречива, найдено несколько равных окружений/URL, нужна авторизация без доступных тестовых данных или есть риск выполнить разрушительное действие. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Режим запуска
+
+Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
+
+Поддерживается только `version: 3`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт `full`; настройки старого формата не применяй.
+
+| Настройка | Значения | Аргументы в сообщении |
+|---|---|---|
+| `manual-test.depth` | `full`, `smoke`, `ask_each_time` | `full`, `полная проверка`; `smoke`, `быстро`, `коротко` |
+
+Если итоговое значение `ask_each_time`, задай блокирующий вопрос о глубине, кроме случая, когда пользователь уже выбрал её в текущем сообщении.
+
+| Глубина | Что проверяется |
+|---|---|
+| `full` | все применимые области матрицы покрытия целиком, по каждому пункту артефакта и diff |
+| `smoke` | запуск, основной happy path изменённой области и 1–2 негативных сценария |
+
+`full` — глубина по умолчанию. Отсутствие плана её не снижает: без артефакта области определяются по `git diff HEAD` и всё равно закрываются целиком. Сузить проверку до главного сценария можно только по явному указанию пользователя или настройке. Полнота считается по областям и пунктам, а не по времени и не по числу шагов.
 
 ## Главные правила
 
 1. **Ручная проверка, не разработка.** Не правь код, не пиши и не обновляй автотесты, не меняй конфиги, не коммить и не пушь.
-2. **Smoke по умолчанию.** Проверь запуск, основной happy path изменённой области и 1–2 негативных или edge-сценария, которые естественно следуют из задачи.
-3. **API проверяй запросами.** Используй `curl`, встроенный HTTP-клиент, Node `fetch` или проектные scripts. Фиксируй method, URL, важные headers без секретов, body, status code и ключевые поля ответа.
-4. **Фронт проверяй браузером.** Если в проекте есть Playwright — используй Playwright. Если Playwright не установлен, используй доступную browser automation хост-агента. Если браузерной автоматизации нет — спроси через `AskUserQuestion`; не устанавливай зависимости молча.
-5. **Серверы поднимай сам, если это очевидно.** Определи команды по `package.json`, README, docker compose, Makefile или локальным инструкциям. Останавливай только процессы, которые сам запустил.
-6. **Секреты не трогай.** Используй только уже доступные локальные `.env`, тестовые аккаунты и настройки. Не проси пользователя прислать секреты в чат и не печатай токены, cookies, passwords, API keys или Authorization headers в отчёт.
-7. **Разрушительное подтверждай.** Реальные платежи, удаление данных, отправку email/SMS/push, изменение production/staging-данных, миграции, очистку БД и похожие действия выполняй только после `AskUserQuestion`.
-8. **Проверяй фактическое поведение.** Не ограничивайся чтением кода. Если сценарий нельзя выполнить, зафиксируй `blocked` и конкретную причину.
-9. **Отчёт обязателен.** Сохрани результат в `docs/artifacts/manual-tests/`, даже если проверка заблокирована или нашла баги.
-10. **Задача важнее дополнительного контекста.** Основной чеклист строй по выполненной задаче: текущему сообщению и явно связанному плану, issue, review или fix-отчёту. Business-карточки подключай только после определения target и только для непосредственно затронутого поведения.
+2. **В `full` закрываешь каждую область.** У области либо результат фактической проверки, либо явная причина, почему она не затрагивается или заблокирована. Пустых и молча пропущенных областей быть не может.
+3. **Проверяй фактическое поведение.** Чтение кода, зелёный `npm test` и «должно работать по плану» проверкой не считаются. Если сценарий нельзя выполнить, зафиксируй `blocked` и конкретную причину.
+4. **API проверяй запросами.** Используй `curl`, встроенный HTTP-клиент, Node `fetch` или проектные scripts. Фиксируй method, URL, важные headers без секретов, body, status code и ключевые поля ответа.
+5. **Базу проверяй запросами к базе.** Используй psql/mysql/sqlite-клиент, ORM-консоль или проектные скрипты. Проверяй реальные строки, а не ответ API.
+6. **Фронт проверяй браузером.** Если в проекте есть Playwright — используй Playwright. Если Playwright не установлен, используй доступную browser automation хост-агента. Если браузерной автоматизации нет — спроси через `AskUserQuestion`; не устанавливай зависимости молча.
+7. **Серверы поднимай сам, если это очевидно.** Определи команды по `package.json`, README, docker compose, Makefile или локальным инструкциям. Останавливай только процессы, которые сам запустил.
+8. **Секреты не трогай.** Используй только уже доступные локальные `.env`, тестовые аккаунты и настройки. Не проси пользователя прислать секреты в чат и не печатай токены, cookies, passwords, API keys или Authorization headers в отчёт.
+9. **Разрушительное подтверждай.** Реальные платежи, удаление данных, отправку email/SMS/push, изменение production/staging-данных, откат миграций, очистку БД и похожие действия выполняй только после `AskUserQuestion`.
+10. **Отчёт обязателен.** Сохрани результат в `docs/artifacts/manual-tests/`, даже если проверка заблокирована или нашла баги.
+11. **Задача важнее дополнительного контекста.** Основной чеклист строй по выполненной задаче: текущему сообщению и явно связанному плану, issue, review или fix-отчёту. Business-карточки подключай только после определения target и только для непосредственно затронутого поведения.
 
 ## Интерактивные вопросы
 
@@ -36,56 +56,70 @@ description: 'Проводит ручную smoke/acceptance-проверку и
 
 ## Этапы
 
-### 1. Определить цель проверки
-Разбери вход пользователя и зафиксируй `$TASK_CONTEXT`: что было сделано и какие результаты пользователь ожидает проверить. Если указан файл плана, ревью, research, issue, fix-отчёт или другой артефакт — прочитай его. Это главный источник сценариев и критериев. Если входа нет, изучи `git diff HEAD`, изменённые файлы, README и релевантные роуты/страницы/компоненты.
+### 1. Определить цель и глубину
+Разбери вход пользователя и зафиксируй `$TASK_CONTEXT`: что было сделано и какие результаты пользователь ожидает проверить. Если указан файл плана, ревью, research, issue, fix- или execution-отчёт — прочитай его целиком. Это главный источник сценариев и критериев. Если входа нет, изучи `git diff HEAD`, изменённые файлы, README и релевантные роуты/страницы/компоненты.
 
-Определи `$TEST_TARGET`: `api`, `frontend`, `fullstack` или `other`. Если цель всё ещё неоднозначна и можно проверить не то окружение или не тот сценарий — спроси через `AskUserQuestion`.
+Определи глубину по разделу «Режим запуска» и `$TEST_TARGET`: `api`, `frontend`, `fullstack`, `cli` или `other`. Если цель всё ещё неоднозначна и можно проверить не то окружение или не тот сценарий — спроси через `AskUserQuestion`.
 
 ### 2. Прочитать рамку проекта
-Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Найди команды запуска, тестовые URL, API-контракты, seed/test users и ограничения окружения в README, package scripts, docker compose, Makefile, OpenAPI/Swagger/Postman-файлах и существующих e2e-тестах.
+Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Найди команды запуска, тестовые URL, API-контракты, миграции, консольные команды, seed/test users и ограничения окружения в README, package scripts, docker compose, Makefile, OpenAPI/Swagger/Postman-файлах и существующих e2e-тестах.
 
-После определения `$TASK_CONTEXT` и фактически изменённого поведения прочитай `docs/business.md`, если индекс существует. По описаниям выбери только карточки, которые прямо относятся к проверяемой задаче. Если таких карточек нет, продолжай без business-контекста и без предупреждения. Не открывай остальные карточки и не расширяй ими smoke-проверку.
+После определения `$TASK_CONTEXT` и фактически изменённого поведения прочитай `docs/business.md`, если индекс существует. По описаниям выбери только карточки, которые прямо относятся к проверяемой задаче. Если таких карточек нет, продолжай без business-контекста и без предупреждения. Не открывай остальные карточки.
 
 Если ожидаемый результат задачи противоречит применимой business-карточке, не выбирай правильный вариант самостоятельно. До неоднозначного сценария покажи конфликт и через `AskUserQuestion` спроси: проверять изменённую задачу как новое правило или сначала пересогласовать карточку через `eda-business`. В неинтерактивном режиме зафиксируй `blocked` с этим вопросом.
 
 Не устанавливай Playwright, браузеры, пакеты, docker images или системные зависимости молча. Если без этого проверка невозможна — спроси через `AskUserQuestion` или зафиксируй `blocked` в неинтерактивном режиме.
 
-### 3. Составить smoke-чеклист
-Составь короткий чеклист:
-- запуск приложения или API;
-- явные acceptance criteria и сценарии выполненной задачи;
-- основной happy path изменённой области;
-- 1–2 негативных или edge-сценария, которые следуют из задачи;
-- для фронта: console errors, network errors и видимые regressions на основной странице;
-- для API: status code, схема/ключевые поля ответа, обработка неверного ввода или прав доступа, если это относится к задаче.
+### 3. Разложить задачу на сценарии
+Если дан план или другой артефакт, разбери его по разделам и переведи каждый пункт в проверяемый сценарий. Ни один раздел не остаётся без сценариев.
 
-Применимая business-карточка может добавить важный инвариант, ожидаемый результат или один релевантный негативный сценарий, который задача не сформулировала явно. Она не заменяет критерии задачи и не требует тестировать всю предметную область. Не расширяй проверку до полного exploratory QA, если пользователь не попросил.
-
-### 4. Запустить окружение
-Если приложение ещё не запущено и команды очевидны, запусти нужные dev/API-серверы. Дождись готовности по логам, healthcheck, открытому порту или успешному запросу. Если порт занят, проверь, подходит ли уже запущенный сервис; если нет — спроси или выбери очевидный альтернативный порт только когда проект это поддерживает.
+| Раздел артефакта | Что из него обязательно проверить |
+|---|---|
+| Задача, критерии готовности | каждый заявленный результат — отдельным сценарием |
+| Целевой алгоритм | каждый путь от входного события до финального состояния, включая ошибочные ветки |
+| Контракты: Данные и БД | каждую таблицу, поле, связь, индекс, unique и миграцию |
+| Контракты: API и внешние контракты | каждый новый и изменённый endpoint, событие, очередь, внешний вызов |
+| Фазы выполнения | `Результат` и `Проверка` каждой фазы |
+| Тесты | сценарии из плана, выполненные руками, а не запуском автотестов |
+| Логирование | что пишется в лог по сценарию и что писать запрещено |
+| Документация и эксплуатация | новые env, миграции, консольные команды, шаги релиза |
+| Принятые решения | видимые последствия решения в работающей системе |
+
+Дополни сценариями из фактического `git diff HEAD`: изменения, которых нет в артефакте, тоже проверяются. Если артефакта нет, весь набор сценариев строится по diff тем же способом — по затронутым endpoints, миграциям, командам, экранам и ветвлениям кода. Применимая business-карточка может добавить важный инвариант или релевантный негативный сценарий. Она не заменяет критерии задачи и не требует тестировать всю предметную область.
+
+### 4. Собрать матрицу покрытия
+Для `full` пройди все области. Каждая получает статус `✓ проверено`, `✗ провалено`, `— не затрагивается` с причиной или `? blocked` с причиной.
+
+| Область | Что проверяется |
+|---|---|
+| API | все новые и затронутые endpoints: успешный ответ и его поля, валидация неверного ввода, права и auth, несуществующая сущность, коды ошибок, обратная совместимость старых клиентов |
+| База данных | миграции применяются без ошибок; схема совпадает с планом (таблицы, колонки, типы, nullable, default, связи, индексы, unique); после сценария появились, обновились и удалились именно те строки с теми значениями; связанные записи и каскады; нет дублей и осиротевших записей; старые данные читаются |
+| Консольные команды | каждая новая и изменённая команда: запуск с аргументами, поведение без аргументов, exit code, вывод, эффект в базе, повторный запуск |
+| Интерфейс | каждый новый и изменённый экран: основной сценарий до результата, состояния загрузки, пустых данных, ошибки и успеха, валидация форм, видимость по ролям, отсутствие console/network errors, вёрстка на desktop и mobile, если менялась |
+| Алгоритмы | сквозной проход по целевому алгоритму: каждая ветка условий, переход состояний, граничные значения, ошибочные пути и откаты |
+| Фон и интеграции | очереди, воркеры, cron, вебхуки, письма и уведомления, события между модулями: задача ставится, выполняется и даёт ожидаемый эффект |
+| Права и роли | что доступ есть у кого положено и его нет у остальных — на API и в интерфейсе |
+| Конфигурация | новые env-переменные и настройки: значение по умолчанию, поведение при отсутствии и при выключенной фиче |
+| Логи и ошибки | по сценарию пишутся ожидаемые записи с нужными полями; в логах и ответах нет секретов и stack traces наружу |
+| Регрессии рядом | соседние сценарии, которые используют изменённый код или таблицы, продолжают работать |
+
+В `smoke` глубоко проверяется только основной сценарий изменённой области; остальные области помечаются `— не проверялось в smoke`.
+
+### 5. Запустить окружение
+Если приложение ещё не запущено и команды очевидны, запусти нужные dev/API-серверы, воркеры и базу. Дождись готовности по логам, healthcheck, открытому порту или успешному запросу. Если порт занят, проверь, подходит ли уже запущенный сервис; если нет — спроси или выбери очевидный альтернативный порт только когда проект это поддерживает.
 
 Фиксируй команды запуска в черновике отчёта. Не заверши свой ответ, пока запущенные тобой процессы, нужные только для проверки, ещё работают.
 
-### 5. Проверить API
-Для API-сценариев выполни реальные запросы. Предпочитай воспроизводимые команды `curl`, но можно использовать Node `fetch` или проектный HTTP-клиент, если так безопаснее.
-
-Проверяй:
-- успешный status code и ключевые поля ответа;
-- корректную ошибку для неверного ввода, отсутствующих прав или несуществующей сущности, если это относится к задаче;
-- отсутствие явных server errors, stack traces и утечек секретов в ответе.
+### 6. Выполнить проверки
+Иди по областям матрицы. Для каждого сценария сохраняй воспроизводимый способ проверки и фактический результат.
 
-Секретные headers и cookies в отчёт не вставляй: пиши `<redacted>`.
+- **API.** Выполняй реальные запросы, предпочитая воспроизводимые команды `curl`. Секретные headers и cookies пиши как `<redacted>`.
+- **База.** После каждого сценария, который меняет данные, смотри в базу запросом и сверяй значения с контрактом. Схему сверяй отдельно от данных. Откат миграции проверяй только по подтверждению пользователя и только если состояние можно восстановить.
+- **Консоль.** Запускай команды в тестовом окружении и проверяй не только вывод, но и эффект.
+- **Фронт.** Открывай страницу в браузере и проверяй фактический UI, а не только DOM-текст. Скриншоты сохраняй, если инструмент это поддерживает и они подтверждают результат или баг: рядом с отчётом или в `docs/artifacts/manual-tests/assets/`.
+- **Алгоритмы.** Для каждой ветки укажи, каким входом ты её вызвал и в каком состоянии система оказалась.
 
-### 6. Проверить фронт
-Для фронтовых сценариев открой страницу в браузере. Если доступен Playwright, используй его для навигации, кликов, ввода и проверок. Если доступен browser plugin или другой инструмент браузерной автоматизации — используй его. Проверяй фактический UI, а не только DOM-текст.
-
-Проверяй:
-- страница загружается без критических console/network errors;
-- основной сценарий пользователя проходит до ожидаемого результата;
-- видимые состояния ошибок, пустых данных или невалидного ввода, если они относятся к задаче;
-- текст и элементы управления не ломаются на очевидном desktop/mobile viewport, если менялась вёрстка.
-
-Скриншоты сохраняй только если инструмент это поддерживает и они помогают подтвердить результат или баг. Складывай их рядом с отчётом или в подпапку `docs/artifacts/manual-tests/assets/`.
+Если область нельзя проверить, не заменяй её чтением кода: ставь `? blocked` и пиши, чего конкретно не хватает.
 
 ### 7. Сохранить отчёт
 Сохрани отчёт в `docs/artifacts/manual-tests/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
@@ -93,8 +127,9 @@ description: 'Проводит ручную smoke/acceptance-проверку и
 ```markdown
 ---
 date: <YYYY-MM-DD HH:MM>
+depth: <full | smoke>
 source: <text | git diff HEAD | docs/artifacts/plans/... | docs/artifacts/reviews/...>
-target: <api | frontend | fullstack | other>
+target: <api | frontend | fullstack | cli | other>
 status: <passed | failed | blocked>
 ---
 
@@ -111,16 +146,34 @@ status: <passed | failed | blocked>
 |---|---|
 | Команды запуска | `<command>` |
 | URL / endpoint | `<url или endpoint>` |
+| База | `<как проверялась>` |
 | Авторизация | `<не нужна | тестовый пользователь | уже настроена | blocked>` |
 
+## Покрытие
+| Область | Статус | Комментарий |
+|---|---|---|
+| API | ✓ / ✗ / — / ? | <что проверено или почему нет> |
+| База данных | | |
+| Консольные команды | | |
+| Интерфейс | | |
+| Алгоритмы | | |
+| Фон и интеграции | | |
+| Права и роли | | |
+| Конфигурация | | |
+| Логи и ошибки | | |
+| Регрессии рядом | | |
+
 ## Чеклист
-| # | Сценарий | Способ проверки | Результат | Заметки |
-|---|----------|-----------------|-----------|---------|
-| 1 | ... | `curl ...` / Playwright / browser | ✓ / ✗ / ? | ... |
+| # | Область | Сценарий | Способ проверки | Результат | Заметки |
+|---|---------|----------|-----------------|-----------|---------|
+| 1 | API | ... | `curl ...` / SQL / Playwright / команда | ✓ / ✗ / ? | ... |
 
 ## Найденные проблемы
 <если нет — «Явных проблем не найдено»; если есть — список с воспроизведением и фактическим/ожидаемым результатом>
 
+## Не проверено
+<области и пункты артефакта, оставшиеся без фактической проверки, с причиной; если таких нет — «нет»>
+
 ## Артефакты
 <ссылки на скриншоты, логи или «Нет»>
 
@@ -128,16 +181,19 @@ status: <passed | failed | blocked>
 <passed / failed / blocked и короткое объяснение относительно выполненной задачи>
 ```
 
-Если найден баг, статус отчёта `failed`. Если проверка невозможна из-за окружения, авторизации, отсутствующих зависимостей или непонятного риска, статус `blocked`.
+`passed` ставится только когда все применимые области закрыты фактической проверкой и проблем нет. Найден баг — `failed`. Есть незакрытая область или проверка невозможна из-за окружения, авторизации, зависимостей или риска — `blocked`, даже если остальное прошло.
 
 ### 8. Финал
-Короткое сообщение: путь к отчёту, итог `passed` / `failed` / `blocked`, какие сценарии реально проверены, какие процессы остановлены, состояние git («не закоммичено»). Если итог `failed` или `blocked` — предложи дальше `eda-fix`. Если итог `passed` — предложи дальше `eda-review` или `eda-commit`.
+Короткое сообщение: путь к отчёту, итог `passed` / `failed` / `blocked`, глубина, какие области закрыты и какие нет, какие процессы остановлены, состояние git («не закоммичено»). Если итог `failed` или `blocked` — предложи дальше `eda-fix`. Если итог `passed` — предложи дальше `eda-review` или `eda-commit`.
 
 ## Чего НЕ делать
 - Править код, конфиги, миграции, seed-данные или документацию проекта, кроме отчёта в `docs/artifacts/manual-tests/`.
 - Писать или обновлять unit/e2e/autotests. Это работа `eda-fix`, `eda-plan-execute` или отдельной задачи.
+- Сводить проверку по плану к smoke-проходу основного сценария.
+- Закрывать область чтением кода, ссылкой на автотесты или словами «по плану должно работать».
+- Ставить `passed`, пока хотя бы одна применимая область не закрыта фактической проверкой.
 - Устанавливать Playwright, браузеры, npm-пакеты, docker images или системные зависимости без явного подтверждения.
-- Подменять ручную проверку запуском `npm test` без фактического прохождения API/UI-сценария.
+- Подменять ручную проверку запуском `npm test` без фактического прохождения сценария.
 - Проверять production или staging с изменением данных без подтверждения пользователя.
 - Сохранять секреты, cookies, токены или passwords в отчёт.
 - Коммитить, пушить, создавать PR или отправлять ревью.