4.7 KiB
4.7 KiB
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.mepassed.- public routes returned
200://login/agents/secrets/wizard//mcp/health
/api/auth/sessionreturned401withapplication/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 по реальному состоянию стенда.
Использовать вместе с:
2. Как вести записи
Добавлять новую запись сверху документа.
В каждой записи обязательно фиксировать:
- какой deploy проверялся;
- кто проводил проверку;
- какой scope реально покрыт;
- какие findings найдены;
- какие follow-up fixes нужны.
Если замечание исправлено, не удалять его из истории, а отметить:
status: fixedfixed_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 уровня:
criticaldeploy unusable, login broken, MCP unavailable, data corruption riskhighprimary 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;
- заранее известные
plannedcapability 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 еще не занесен.