Backend-QA чеклист миграции на runes

Playwright mock-smoke (npm --prefix frontend run test:e2e) гоняет демо-сборку на mockApi — без реального бэкенда. Поэтому он покрывает загрузку, переключение экранов, модалки, ленивую загрузку админки, render-парити и i18n, но не покрывает пути, которым нужен живой бэкенд: авторизацию, завершение оплаты, сеть/401, сессионный токен, успех активации.

Этот чеклист — обязательная страховка для тех путей. Его можно прогонять руками против единого dev stand или постепенно автоматизировать поверх него. До появления dedicated full-stack E2E считайте ручной прогон обязательным перед закрытием фаз, которые трогают эти пути:

R2 — после миграции authStore / billingStore.
R3 — после перевода оболочки App.svelte на runes.
R4 — после перевода админки на runes и удаления componentApi: 4 / $set.

Каждый прогон фиксируй: дату, коммит (git rev-parse --short HEAD) и результат — в теле коммита, который закрывает фазу, или прямо в этом файле (таблица внизу).

Перед прогоном

Подними единый dev stand: npm run dev:stand:up.
Собери актуальные бандлы: npm --prefix frontend run build:webapp.
Открой mini-app из Telegram и через прямой webapp-URL (часть пунктов — про оба входа).
Открой DevTools → Console и Network. Любая красная ошибка в консоли = провал пункта.

Что можно автоматизировать

Автоматизация этих пунктов возможна и желательна. Она не была частью Playwright mock-smoke, потому что mock-smoke намеренно работает без backend и проверяет только быстрый UI-regression слой. Для реального QA нужен отдельный full-stack слой:

pytest/API тесты могут создавать платеж, затем отправлять локальный webhook провайдера и проверять подписку, платеж и activation-ack;
Playwright может работать против http://127.0.0.1:8082, используя dev-сессию или тестовый email-code login;
admin-save сценарии можно проверять через UI, а результат сверять через API или PostgreSQL.

Для стабильного CI-гейта нужно добавить reset фикстур, dev-only выдачу email code/session token и единые webhook fixtures для платежей. До этого чеклист остается источником сценариев, которые нужно переносить в автоматические тесты.

Авторизация (R2 / R3)

Вход по email-коду. Запросить код → письмо приходит → ввод верного кода пускает в приложение; неверный код показывает ошибку, не роняет экран.
Magic-link вход. Переход по ссылке из письма авторизует и приземляет на home.
Telegram mini-app авторизация. Запуск из Telegram авторизует без ручного ввода; initData валидируется бэкендом; таймаут SDK не вешает загрузку (есть фолбэк).
Сессионный токен переживает перезагрузку. F5 на любом экране оставляет залогиненным; токен и csrfToken восстанавливаются.
401 → ре-логин. Протух токен (или принудительно очищен) → следующий авторизованный запрос ведёт на экран входа, без зацикленных редиректов.
Привязка идентичности. Аккаунт с непривязанной identity показывает подсказку и проходит флоу привязки.

Оплата и активация (R3)

Покупка → успех активации. Выбрать тариф → провести оплату (тестовый провайдер) → диалог успеха активации показывается один раз и в правильном порядке (ack активации не дублируется и не теряется).
Смена тарифа. «Сменить тариф» → подтверждение → пересчёт/доплата отрабатывают; подписка обновляется без перезагрузки.
Автопродление. Тумблер автопродления сохраняется на бэкенде и переживает F5.
Отмена/ошибка оплаты. Прерванная оплата возвращает в исходное состояние без «висящих» модалок и ошибок в консоли.

Устройства (R3)

Отключение устройства. Disconnect реально дёргает бэкенд, строка пропадает, счётчик HWID-лимита обновляется корректно.

Сохранения в админке (R4)

Настройки. Изменить настройку в SettingsSection → Save → значение персистится (видно после F5), без потери реактивности после удаления $set.
Тарифы. Создать/отредактировать тариф (TariffEditorModal) → Save → изменения видны в списке и переживают перезагрузку.
Переводы. Отредактировать строку в TranslationsSection → Save → новый текст применяется в webapp.
Дататейблы после удаления watchAdminDatatable. Сортировка, пагинация и поиск в таблицах (Users/Payments/…) работают; данные не «застывают».
Реактивные props админки. После дропа componentApi: 4 обновление props из хоста (adminEntry.update(...)) применяется в смонтированном компоненте.

Журнал прогонов

Дата	Коммит	Фаза	Результат	Заметки