План: единый identity вместо парных резолверов

Рабочий план, с которого начиналась унификация auth-флоу — зафиксирован здесь как пример проработки задачи до кода: контекст, подтверждённые решения, разбивка по файлам, риски. Реализация по этому плану завершена и описана в разделе «Авторизация» → техническая документация; этот документ больше не источник истины о текущем состоянии кода.

Контекст задачи

Поле ввода на фронте (AppEmailOrPhoneField) уже объединяло телефон и почту в одно поле, но бэкенд продолжал жить парами резолверов — registerByPhone/registerByEmail, loginByPhone/loginByEmail, confirmRegisterByPhone/confirmRegisterByEmail, requestPasswordRecoveryByPhone/ByEmail, confirmPasswordRecoveryByPhone/ByEmail, phoneCodeIsValid/emailTokenGetState — фронт сам вычислял, какую пару мутаций вызывать. Цель плана: один резолвер на действие (register, confirmRegister, login, requestPasswordRecovery, confirmPasswordRecovery, verificationPeek), канал определяет бэкенд по формату identity.

Дополнительно план вводил verificationId — непрозрачный подписанный JWT, выдаваемый при register/requestPasswordRecovery, который фронт носит с собой вместо повторной пересылки телефона/почты. Отдельно был учтён задел под будущий соцвход: OAuth — redirect+callback флоу, принципиально другой, поэтому сознательно не встраивался в verificationId/ VerificationChannel.

Подтверждённые решения (на момент планирования)

identity-поле с серверным авто-определением канала, без явного identity_type от фронта.
Имя session/event-поля: verificationId.
login тоже объединяется в один резолвер login(identity, password).
phoneCodeIsValid и emailTokenGetState объединяются в один query verificationPeek(verificationId, code?).
Старые парные резолверы удаляются полностью, без deprecated-обёрток — стиль проекта: чистый рефакторинг, не shim'ы.
После реализации — сгенерировать документ-спецификацию и добавить ссылку в CLAUDE.md.

Строго вне рамок (зафиксировано заранее)

secured-fields.resolver.ts (requestPhoneChange/confirmPhoneChange/ requestEmailChange/changeMyPass) и confirmEmail (CHANGE-подтверждение email) — эти CHANGE-флоу не переделывались, только должны были продолжать работать один-в-один, что гарантировалось сохранением сигнатур публичных методов VerificationService.

Известный риск, зафиксированный планом заранее

Обнаружено на этапе планирования

SMS-коды в Redis (apps/notify-service/src/services/storage.service.ts) хранятся по номеру телефона без TTL и без purpose-метки — устаревший код от REGISTER теоретически может подтвердить RECOVER для того же номера в окне до перезаписи. Решено не чинить в рамках этой задачи (notify-service вне рамок) — зафиксировано как рекомендация на будущее. Актуальность на текущий момент — см. техническую документацию по авторизации.

Верификация (план)

apps/user-service: npm run build (tsc) — ловит рассинхрон импортов DTO/резолверов на этапе компиляции.
./scripts/e2etest.sh user backend chat (development) — все три e2e-сьюта, поскольку backend/chat транзитивно зависят от login/register user-service через свои auth-helper.ts.
Ручная проверка фронта не требуется по умолчанию — полагаемся на e2e-гейт.

Итог

План реализован без существенных отклонений; итоговые архитектурные детали (карта файлов, финальная схема мутаций, статус e2e-гейта) — в технической документации раздела «Авторизация».