0024 — Onboarding организации после подтверждения email¶

Дата: 2026-08-24.
Статус: Принято пользователем; transport-путь live email gate уточнён решением 0025.
Ответственный: владелец проекта.

Контекст¶

Решения 0009 и 0011 связывали успешное подтверждение email с немедленным атомарным созданием Organization и Membership(owner). Решение 0018 позднее зафиксировало отдельное состояние подтверждённого пользователя без организации и маршрут /onboarding/organization. Эти формулировки определяли разный момент создания tenant-контекста.

На 2026-08-24 хостинг не подтвердил открытие SMTP-порта для DEV. Владелец временно пропустил live email-verification gate для продолжения локальной разработки, но не отменил обязательность подтверждения email. Решение 0025 позднее заменило ожидание SMTP-порта на Resend HTTPS transport; обязательность live gate не изменилась.

Решение¶

Последовательность самостоятельной регистрации¶

регистрация email/password
  -> подтверждение email
  -> /onboarding/organization
  -> атомарное создание рабочего контекста
  -> /home

Подтверждение email только открывает доступ к onboarding организации. Оно не создаёт tenant-записи автоматически.
Подтверждённый активный пользователь без завершённого onboarding направляется на /onboarding/organization.
Форма принимает только название организации и часовой пояс IANA. Browser может предложить часовой пояс, но пользователь подтверждает его перед отправкой.
Клиент не передаёт organizationId, роль, идентификатор модуля или системные статусы.
После успешного submit одна PostgreSQL-транзакция создаёт Organization, активный Membership текущего пользователя с ролью owner, активный OrganizationModule(today), AuditEvent и OutboxMessage.
Успешный результат ведёт на /home.
Placeholder-организация до подтверждения email не создаётся; название и часовой пояс до подтверждения email не собираются.

Доступ и повторяемость¶

Actor определяется только из server-side session и должен быть active, иметь подтверждённый email, не иметь platform role и ещё не завершить самостоятельный onboarding.
Операция идемпотентна и безопасна при конкурентных повторах: один пользователь получает один результат самостоятельного onboarding без дублирования организации, membership, entitlement, audit или outbox.
Повтор после успешного завершения возвращает уже созданный рабочий контекст и nextPath: /home.
На этом срезе OrganizationModule(today) подтверждает подключение модуля организации, но не открывает обычному пользователю /today. До появления MemberModuleAccess и today.view четырёхслойная проверка решения 0012 остаётся fail-closed.
Расширение пользователя до нескольких memberships сохраняется целевой моделью, но MVP показывает один активный организационный контекст. Дополнительное самостоятельное создание организаций этим endpoint не разрешается.

Ручное подтверждение SuperAdmin¶

Ручное подтверждение super_admin из решения 0011 меняет способ подтверждения email на super_admin_manual, но также направляет пользователя в /onboarding/organization и не создаёт организацию автоматически.
Само административное действие остаётся вне текущего среза до реализации обязательных причины, инициатора, времени и аудита.

Владение и контракт¶

Organization, Membership, onboarding application service и их Drizzle schema sources принадлежат общей capability platform/organizations.
packages/database остаётся общим техническим DB client и центральным migration runner/aggregator; бизнес-правила организации в него не переносятся.
HTTP contract публикуется через packages/contracts, а apps/api только регистрирует route и внедряет зависимости.
Канонический endpoint — POST /api/v1/organization с body { name, timeZone }; ответ сообщает created или already_completed, созданный рабочий контекст и nextPath: "/home".

Последствия¶

Настоящее решение заменяет момент создания Organization и Membership в решениях 0009 и 0011; остальные требования этих решений сохраняют силу.
GET /api/v1/access должен различать подтверждённого пользователя без организации и готовый рабочий контекст, не раскрывая tenant-данные из непроверенного клиентского идентификатора.
Audit и outbox создаются в транзакции; dispatcher, внешняя доставка, frontend onboarding, organization settings, billing и полный модульный доступ остаются отдельными срезами.
Для реализации обязательны migration, integration, rollback/atomicity и concurrency checks только на синтетических данных.
Временный пропуск live SMTP gate не разрешает обходить email verification в product code.
Владелец 2026-08-24 остановил реализацию этого backend-среза до ответа хостинга и успешной live-проверки SMTP и полного email-verification flow. Принятый контракт сохраняется как следующий шаг, но не активируется локальной подменой подтверждения.

Откат или замена¶

Возврат к автоматическому созданию tenant при подтверждении email, сбор данных организации до подтверждения, разрешение нескольких самостоятельных организаций или открытие /today без полного пересечения прав требует нового решения.