# Ручной regression checklist

## 1. Назначение

Этот документ фиксирует post-integration baseline для Community UI, auth, secrets и REST/MCP slices.

Цель:

- дать воспроизводимый regression pass после крупных вертикальных срезов;
- отделить автоматический baseline от ручного smoke на стенде;
- не заставлять следующего агента заново собирать сценарии по всему проекту.

## 2. Автоматический baseline

Локальный regression baseline на `2026-04-07`:

- `cargo check --workspace` -> passed;
- `cd apps/ui && npm run e2e` -> `11 passed`;
- e2e стек поднимает:
  - `postgres`;
  - `admin-api`;
  - `mcp-server`;
  - локальный UI proxy.

Покрытые автоматикой сценарии:

- login;
- operations catalog;
- agents;
- api keys;
- logs;
- usage;
- workspace/settings;
- wizard;
- REST draft/test/publish flow.

## 3. Когда запускать этот pass

Запускать обязательно после изменений в:

- auth/session;
- workspace switching;
- operations/wizard;
- agents;
- secrets/auth profiles;
- MCP transport;
- deploy routing/UI routes.

## 4. Обязательные команды перед ручным проходом

```bash
cargo check --workspace
cd apps/ui && npm run e2e
```

Если одна из команд не проходит, ручной regression pass не считается завершенным.

## 5. Ручной smoke checklist

### 5.1. Auth и shell

- открыть `/login`;
- проверить, что страница не зацикливается на redirect;
- проверить invalid login;
- войти bootstrap admin-пользователем;
- убедиться, что после входа открывается `/`;
- проверить logout;
- войти повторно;
- проверить header identity;
- проверить language switch;
- проверить workspace switch в navbar.

### 5.2. Operations

- открыть `/`;
- убедиться, что demo operations загружены;
- проверить search;
- проверить protocol/category/agent filters;
- открыть edit существующей operation;
- убедиться, что delete доступен только never-published Draft, а Published предлагает archive с подтверждением;
- открыть одну Operation в двух вкладках, сохранить обе и проверить, что вторая получает localized stale recovery без потери local edits;
- проверить success/error toasts;
- проверить clean routes без `/html/...`.

### 5.3. Wizard

- открыть `/wizard/`;
- убедиться, что доступна только `REST` protocol card;
- для нового upstream проверить режимы auth:
  - `No auth`
  - `Use existing auth profile`
  - `Create auth profile now`
- создать quick secret из wizard;
- создать quick auth profile из wizard;
- сохранить upstream;
- убедиться, что `execution_config.auth_profile_ref` попадает в draft/test flow;
- проверить sample upload;
- проверить YAML export/import;
- проверить `Test run`;
- проверить, что Test run показывает безопасные Request ID и Trace ID с copy controls;
- проверить `Publish`, затем edit: Published vN остаётся неизменной, новая правка становится Draft vN+1;
- экспортировать Published vN как YAML v2, выполнить semantic no-op и changed upsert; previous Published Version не должна меняться;
- архивировать Operation и проверить, что существующий published Agent по-прежнему list/call pinned vN, а новая binding отклоняется.

### 5.4. Agents

- открыть `/agents`;
- проверить cards и lifecycle badges;
- открыть drawer;
- проверить bindings;
- создать или обновить agent;
- проверить publish/unpublish/archive flow;
- проверить copy MCP endpoint.

### 5.5. API Keys

- открыть `/api-keys`;
- создать MCP client key;
- убедиться, что raw key показывается один раз;
- проверить copy;
- закрыть reveal modal и убедиться, что raw key очищен из интерфейса;
- проверить revoke и убедиться, что существующая MCP session теряет доступ без restart;
- проверить delete revoked key: metadata остаётся со статусом `deleted`, raw/hash не отображаются;
- создать approval key с `allowed_origins`;
- проверить, что approval запрос с чужим `Origin` отклоняется.
- создать Operation с human approval, вызвать Tool дважды с одинаковыми
  аргументами и разными control-token: должна остаться одна pending заявка;
- убедиться, что pending approval summary показывает Agent/Operation Version,
  expiry и безопасные параметры без raw token/secret;
- подтвердить заявку и повторить approve: второй запрос должен вернуть terminal
  status без повторного upstream side effect.
- проверить `last_used_at` после реального machine-auth вызова при необходимости.

### 5.6. Secrets

- открыть `/secrets`;
- проверить list/create/rotate/delete;
- создать:
  - `token`;
  - `username_password`;
  - `header`;
  - `generic`;
- убедиться, что plaintext не возвращается после create/rotate;
- проверить usage references через auth profiles;
- проверить, что удаление Secret, используемого Auth Profile, возвращает `409 secret_referenced_by_auth_profile`;
- проверить, что rotation Secret меняет credential для следующего Wizard Test run без изменения Auth Profile/Operation refs;
- проверить audit/log evidence: нет plaintext, ciphertext, hash или raw key;
- проверить, что wizard quick-create синхронизируется с этой страницей.

### 5.7. Logs и Usage

- открыть `/logs`;
- проверить loading/error/empty states;
- проверить фильтры period, explicit UTC window, status, outcome group, level/search и кнопку Load more;
- открыть detail expansion и убедиться, что видны Request ID, Trace ID и точная Operation Version, но нет raw секретов;
- экспортировать CSV из Logs и проверить, что выбранные фильтры применились без page-limit обрезки;
- открыть `/usage`;
- проверить summary cards;
- проверить timeline chart;
- проверить outcome groups `success`, `upstream`, `client`, `schema`, `crank`;
- проверить server-side CSV export из `/usage/export.csv`, а не client-side snapshot браузера.

### 5.8. Workspace и Settings

- открыть `/workspace-setup`;
- проверить редактирование имени, slug, описания и цвета единственного workspace;
- проверить, что интерфейса приглашений, ролей и управления пользователями нет;
- проверить export workspace;
- проверить, что delete workspace не отображается;
- открыть `/settings`;
- проверить profile update;
- проверить password change.

### 5.9. Getting Started: протокол usability для пяти участников

Этот протокол является планом сбора ручного evidence, а не заявлением о
пройденном исследовании. Выполнять его на пяти независимых участниках с fresh
self-hosted installation и отдельным новым Admin account для каждого прогона.
Участнику нельзя помогать документацией, исходным кодом, поиском по репозиторию
или подсказками оператора; разрешён только сам продукт и нормальное MCP client
окружение.

Для каждого участника:

- запустить таймер с первого authenticated рендера protected Admin UI;
- использовать Getting Started, создать manual REST Operation, выполнить test,
  publish, создать/publish Agent и один MCP client key;
- сохранить key только через one-time reveal <!-- community-scope: allow=one-time-token -->, выполнить публичные
  `initialize`, `notifications/initialized`, `tools/list`, `tools/call` по
  canonical endpoint;
- остановить таймер после server-authoritative `first_call` с Agent/key/Tool,
  Request ID и Trace ID в snapshot/Invocation History;
- проверить, что refresh/resume не раскрывает raw key, а revoke предлагает
  deliberate recovery без автоматического создания дубликата;
- зафиксировать завершение, duration, все recovery/error states и факт
  eligibility отдельно от completion. Не записывать bearer, payload, URL
  частного контура или скриншоты с секретами.

Цель — median времени от первого authenticated render до authoritative first
call не более 15 минут. Незавершивший участник цензурируется на 30-й минуте, но
остаётся в conversion denominator; eligibility denominator и completion
numerator публикуются раздельно. До фактического пятиучастникового запуска
результат этого протокола остаётся `not_run`, а не `pass`.

## 6. Protocol smoke pass

Для smoke-проверки MCP использовать готовый public target из [public-smoke-targets.md](public-smoke-targets.md).

Обязательный кейс:

- REST: [Frankfurter examples](../examples/frankfurter/README.md)

## 7. Acceptance criteria

Regression pass считается завершенным, если одновременно выполнены условия:

- `cargo check --workspace` passed;
- Playwright suite passed;
- login/shell/manual navigation не ломаются;
- `Secrets -> Auth Profiles -> Wizard -> Test run` связка работает;
- public REST smoke target проходит;
- нет критичных UI regressions на clean routes, i18n и auth redirects.

## 8. Если что-то падает

- сначала фиксировать failing automated spec;
- потом чинить ручной smoke regression;
- после фикса повторять:
  - `cargo check --workspace`;
  - `cd apps/ui && npm run e2e`;
- только потом фиксировать результат в текущем рабочем трекере.