# Authenticated Staging Pass

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

Этот документ описывает тот кусок Community staging smoke, который нельзя честно закрыть одними `curl` и unauthenticated route checks.

Он покрывает:

- login/logout;
- UI shell после входа;
- `Secrets -> Auth Profiles -> Wizard -> Test run`;
- `REST` smoke через UI и MCP.

Использовать вместе с:

- [deploy-and-staging-smoke.md](deploy-and-staging-smoke.md)
- [staging-regression-notes.md](staging-regression-notes.md)
- [manual-regression-checklist.md](manual-regression-checklist.md)

## 2. Что нужно заранее

- свежий deploy уже прошел helper smoke:
  - `just staging-smoke https://<domain>`
- Community deploy был собран из `deploy/community/docker-compose.yml`
- automated browser-authenticated smoke при необходимости запускается так:
  - `CRANK_STAGING_ADMIN_EMAIL=... CRANK_STAGING_ADMIN_PASSWORD=... just authenticated-staging-smoke https://<domain>`
- известны bootstrap admin credentials;
- на стенде есть demo data или подготовленный disposable workspace;
- браузер открыт с devtools, чтобы фиксировать network и console findings.

## 3. Канонический проход

Перед ручным проходом можно прогнать automated baseline:

```bash
export CRANK_STAGING_ADMIN_EMAIL=owner@example.com
export CRANK_STAGING_ADMIN_PASSWORD=secret
just authenticated-staging-smoke https://<domain>
```

После завершения прохода добавьте результат в [staging-regression-notes.md](staging-regression-notes.md) вручную по шаблону ниже.

### 3.1. Login and shell

1. Открыть `/login`
2. Проверить:
   - invalid login -> корректная ошибка;
   - valid login -> redirect на `/`;
   - нет redirect loop;
   - password-only note видна;
3. После входа проверить:
   - current workspace в navbar;
   - user identity;
   - language switch;
   - logout.

### 3.2. Core UI pages

После повторного входа открыть:

- `/`
- `/agents`
- `/api-keys`
- `/secrets`
- `/logs`
- `/usage`
- `/workspace-setup`
- `/settings`
- `/wizard/`

Для каждой страницы зафиксировать:

- `status: passed | partial | failed`
- есть ли console errors;
- есть ли failing XHR или fetch;
- есть ли broken layout.

### 3.3. Secrets and auth profiles

1. Открыть `/secrets`
2. Создать disposable `token` secret
3. При необходимости создать еще:
   - `header`
   - `username_password`
4. Проверить:
   - list/update timestamps;
   - rotate;
   - delete;
   - usage references

### 3.4. Wizard auth flow

1. Открыть `/wizard/`
2. На шаге 2:
   - выбрать `No auth`;
   - выбрать existing auth profile;
   - создать quick secret;
   - создать quick auth profile;
3. Сохранить upstream
4. Дойти до `Test run`
5. Подтвердить, что:
   - нет `${secrets.*}`;
   - upstream сохраняется;
   - test run отрабатывает с `auth_profile_ref`.

### 3.5. REST protocol smoke

Использовать:

- [public-smoke-targets.md](public-smoke-targets.md)

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

- `REST`

Порядок:

1. создать или открыть operation;
2. выполнить `Test run`;
3. publish;
4. привязать к agent;
5. выполнить MCP smoke:
   - `tools/list`
   - `tools/call`

## 4. Что нужно занести в staging notes

По итогам authenticated pass в [staging-regression-notes.md](staging-regression-notes.md) обязательно добавить:

- deploy commit;
- кто проходил smoke;
- что именно проверено;
- что прошло;
- findings с severity;
- infra notes;
- explicit status для:
  - auth;
  - secrets/auth profiles;
  - wizard;
  - REST;
  - MCP smoke.

## 5. Готовый блок для вставки

```md
## YYYY-MM-DD HH:MM TZ — rmcp.itexp.me (authenticated pass)

- deploy commit: `<sha>`
- checked by: `<name>`
- smoke status: `passed | partial | failed`
- scope:
  - auth
  - ui shell
  - operations
  - wizard
  - agents
  - api keys
  - secrets
  - logs
  - usage
  - rest smoke
  - mcp smoke

### Passed

- login/logout completed
- shell pages open after auth
- secrets/auth profile flow status: `<passed|partial|failed>`
- REST smoke: `<passed|partial|failed>`
- MCP smoke: `<passed|partial|failed>`

### Findings

- none

### Infra notes

- ...

### Follow-up

- ...
```

## 6. Почему automated smoke недостаточно

Скрипт [scripts/authenticated-staging-smoke.sh](../scripts/authenticated-staging-smoke.sh) полезен как быстрый sanity check, но он:

- проверяет только минимальный browser flow;
- не создает реальный disposable operation;
- не заменяет ручной `REST -> publish -> MCP call` проход;
- не должен отмечаться как `passed`, пока результаты не занесены в [staging-regression-notes.md](staging-regression-notes.md).