Staging Regression Notes

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

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

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

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

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

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

Каждый deploy или ручной regression pass должен добавляться новым блоком в начало документа.

На один блок фиксировать:

дата и время;
окружение;
commit/tag/image;
кто запускал pass;
какие smoke steps прошли;
какие дефекты подтверждены;
какие наблюдения являются только инфраструктурными;
какие 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
  - streaming
  - 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;
streaming session/job inconsistency.

Не считать product finding

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

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

6. Open follow-up inventory

Пока документ создается как шаблон, без зафиксированных staging defects.

Первый реальный проход должен заполнить минимум:

auth/login status;
clean routes status;
Secrets -> Auth Profiles -> Wizard -> Test run статус;
REST, GraphQL, gRPC smoke results;
streaming pages status;
WebSocket/SOAP note:
- not exercised
- или failed/passed с причиной.

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

На момент создания документа:

automated baseline локально зеленый;
канонический post-deploy smoke runbook существует;
staging findings еще не занесены.

4.1 KiB Raw Blame History Unescape Escape