crank/docs/staging-regression-notes.md

Staging Regression Notes

2026-04-07 12:53 MSK — rmcp.itexp.me

• deploy commit: unknown
• checked by: codex + operator
• smoke status: partial
• scope:
  • auth
  • ui shell
  • mcp health
  • clean routes
  • legacy redirects

Passed

• bash scripts/staging-smoke.sh https://rmcp.itexp.me passed.
• public routes returned 200:
  • /
  • /login
  • /agents
  • /secrets
  • /wizard/
  • /mcp/health
• /api/auth/session returned 401 with application/json, not HTML fallback:
  • {"error":{"code":"unauthorized","message":"authentication required"}}
• legacy routes redirected correctly:
  • /html/login.html -> /login
  • /html/agents.html -> /agents
  • /html/wizard/ -> /wizard/

Findings

• none in this pass

Infra notes

• this pass covered only unauthenticated public or staging smoke;
• authenticated UI flows, MCP tool calls, secrets/auth-profile flows and REST smoke were not exercised in this entry.

Follow-up

• run a full authenticated browser smoke after the next deploy;
• record REST and MCP smoke results in the next entry.

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

Этот документ фиксирует результаты ручных проверок на staging или production-like окружении после deploy.

Он нужен для трех задач:

• хранить пост-деплойные замечания вне чата;
• отличать разовые сбои окружения от продуктовых регрессий;
• дать следующему агенту нормальный handoff по реальному состоянию стенда.

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

• deploy-and-staging-smoke.md
• manual-regression-checklist.md
• authenticated-staging-pass.md

Если нужно сгенерировать заготовку новой записи:

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

2. Как вести записи

Добавлять новую запись сверху документа.

В каждой записи обязательно фиксировать:

• какой deploy проверялся;
• кто проводил проверку;
• какой scope реально покрыт;
• какие findings найдены;
• какие follow-up fixes нужны.

Если замечание исправлено, не удалять его из истории, а отметить:

• status: fixed
• fixed_by: <commit>

3. Формат записи

Использовать такой шаблон:

## YYYY-MM-DD HH:MM TZ — <environment>

- 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

- ...

### Findings

1. `<severity>` `<short title>`
   - area: `<page/service>`
   - symptom: `...`
   - reproduction: `...`
   - expected: `...`
   - actual: `...`
   - status: `open | fixed | accepted`
   - fixed_by: `<sha or ->`

### Infra notes

- ...

### Follow-up

- ...

4. Severity model

Использовать только 4 уровня:

• critical deploy unusable, login broken, MCP unavailable, data corruption risk
• high primary flow broken, но система частично работает
• medium заметный UX или runtime дефект с обходным путем
• low косметика, wording, layout, docs mismatch

5. Что считать finding, а что нет

Считать finding

• broken routing;
• redirect loop;
• wrong auth/session behavior;
• page-level JS exception;
• incorrect MCP result;
• secret/auth profile flow mismatch;
• deploy route returning HTML instead of JSON.

Не считать product finding

• разовый сетевой timeout;
• локальный browser glitch без воспроизведения;
• внешний upstream outage из public REST smoke target;
• предупреждения, не влияющие на flow;
• заранее известные planned capability blocks.

Такие случаи писать в Infra notes, а не в Findings.

6. Open follow-up inventory

Следующий полный проход должен заполнить минимум:

• auth/login status;
• clean routes status;
• Secrets -> Auth Profiles -> Wizard -> Test run статус;
• REST smoke results;
• MCP smoke result.

7. Последняя актуальная запись

На данный момент:

• automated baseline локально зеленый;
• helper-based staging smoke на rmcp.itexp.me прошел;
• полный authenticated staging pass еще не занесен.