Открытая регистрация практика

Решение

Практик использует тот же e-mail OTP и ту же учётную запись, что и обычный пользователь. После входа пользователь вызывает POST /api/v1/me/practitioner-profile. Отдельного типа пользователя, отдельной сессии и публичного неаутентифицированного регистрационного endpoint нет.

Верификация личности, квалификации и документов не входит в текущую задачу. Поэтому успешно созданный профиль сразу доступен в каталоге и принимает заявки.

API-контракт

Запрос требует bearer access token:

{
    "publicSlug": "anna-ivanova",
    "displayName": "Анна Иванова",
    "bio": "Астролог-консультант",
    "experienceYears": 5
}

Обязательны непустые publicSlug, displayName и bio. publicSlug нормализуется в lower-case и допускает только латинские буквы, цифры и одиночные дефисы; experienceYears — необязательное целое число от 0 включительно.

Первое создание отвечает 201. Повторный запрос того же пользователя идемпотентен: отвечает 200 существующим профилем и не перезаписывает его данными повторного запроса. Занятый другим профилем slug отвечает 409 PRACTITIONER_SLUG_CONFLICT, невалидные поля — 400 INVALID_PRACTITIONER_PROFILE.

Транзакция регистрации

В одной database transaction необходимо:

1. Создать practitioner_profiles со связанным user_id, status = APPROVED, approved_at = now() и accepting_requests = true.
2. Добавить (user_id, PRACTITIONER) в user_roles, не удаляя (user_id, CLIENT).
3. Вернуть профиль вместе с актуальным набором ролей пользователя.

Текущее значение APPROVED используется как существующий технический признак публикации в каталоге. Оно не означает, что платформа проверила практика. Переименование enum в ACTIVE или PUBLISHED не входит в эту задачу, поскольку потребовало бы отдельной миграции и изменения существующего consultation flow.

Авторизация и поведение после регистрации

Access token содержит идентификатор сессии, а роли читаются из БД при каждом аутентифицированном запросе. Поэтому перевыпуск токена после добавления PRACTITIONER не нужен. Существующие проверки каталога и владения заявками должны работать без изменений: каталог требует связанного user с ролью PRACTITIONER, а принять или отклонить заявку может только user, связанный с выбранным practitioner-профилем.

Реализация

• добавить practitioner Prisma-service с транзакционным методом регистрации;
• добавить аутентифицированный route POST /me/practitioner-profile и OpenAPI-описание;
• подключить router в composition root;
• преобразовать unique-конфликт public_slug в стабильную доменную ошибку;
• покрыть тестами успешное создание, сохранение роли CLIENT, повторный запрос, конфликт slug, валидацию и отсутствие авторизации;
• выполнить build, lint/format и тесты.

Изменения Prisma schema не требуются: необходимые модели, enum и ограничения уже существуют.