crank/docs/authenticated-staging-pass.md

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
• staging-regression-notes.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:

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

После завершения прохода готовый блок для staging-regression-notes.md можно сгенерировать так:

just staging-note-block <domain> <deploy-sha> "codex + operator"

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

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

• 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 обязательно добавить:

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

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

Этот же блок можно получить через:

just staging-note-block <domain> <deploy-sha> "codex + operator"

## 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 полезен как быстрый sanity check, но он:

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