Перейти к основному содержимому

UC-REF-005. Авторизация: «Имя заполнено И регистрация ≥ 4 ч» → только лид, без связи (правило R3)

Назначение

Авторизация инвестора с реферальной ссылкой, когда пользователь уже зарегистрировался сам: имя заполнено И дата регистрации более 4 часов назад. Реферальная связь НЕ создаётся (вознаграждение рефереру не положено — пользователь пришёл в систему самостоятельно, INV-REF-003), но лид между агентом и инвестором создаётся на основе этой ссылки. Правило R3 AuthorizationSelfRegistered матрицы attach-rules.md. Связан с контекстом referral.

Metadata

ПолеЗначение
IDUC-REF-005
Контекстreferral (см. docs/06-services/referral/)
Типальтернативный (ветка триггера T2; основная ветка — UC-REF-004)
Статусdraft

Актор

ПолеЗначение
РольSystem (обработка события входа; m2m ACL Kafka на топик pin.identity.sign-ins.v1); инициатор — Инвестор с давно завершённой регистрацией
Permissions / scopepermission не применяется (system actor); доступ — ACL топика
Tenantлид-событие несёт AgentCompanyId = link.TenantId (ADR-0052); записей в referral не создаётся
Record-levelне применяется

Предусловие

  • Учётка инвестора существует; в реплике ReferralUserReplica: IsNameFilled = true И now() - RegisteredAt >= Referral:LazyRegistrationWindow (default 4 ч) — либо RegisteredAt = null (fail-closed, альтернатива A1).
  • Инвестор открыл реферальную ссылку агента/застройщика — cookie referralUrl жива (UC-REF-002).
  • Поле ReferrerUrl? в UserSignedInKafkaEvent доступно (решение 4 README.md).
  • Guard-ы G1–G4 attach-rules.md выполнены; владелец ссылки — Agent/DeveloperManager со Status = Active (иначе полный no-op, альтернатива A2).

Триггер

ПолеЗначение
ИсточникKafka event
Триггерящий элементСобытие UserSignedInKafkaEvent (топик pin.identity.sign-ins.v1), ReferrerUrl != null (триггер T2, ветка R3 attach-rules.md)

Основной Поток

Ниже — дельта R3 к общему алгоритму привязки (дом — attach-rules.md): связь и журнал не пишутся.

  1. Давно зарегистрированный инвестор (имя заполнено) открывает ссылку агента и входит в систему; identity публикует UserSignedInKafkaEvent с ReferrerUrl = slug (user-signed-in.md).
  2. Контекст и идемпотентность. Повтор отсекается по MessageId (записей в referral этот сценарий не делает, дедуп лида — на стороне CRM). Формат slug валиден; ссылка резолвится и не удалена (G1). Читаются: реплика пользователя (Type = Investor [G2], Status [G4], IsNameFilled, RegisteredAt); владелец ссылки; наличие активной связи — только для телеметрии выбора ветки (связь в R3 всё равно не создаётся).
  3. Выбор правила. IsNameFilled = true И время события - RegisteredAt >= Referral:LazyRegistrationWindow → правило R3 (INV-REF-003 SelfRegisteredNoBond: «пользователь зарегистрировался уже сам»). Связь НЕ создаётся; проверка INV-REF-002: владелец — Agent/DeveloperManager, owner.Status = Active → лид требуется.
  4. Без записей. Правило R3 ничего не пишет в referral — ни связь, ни журнал (в матрице «Журнал: нет»); след лида живёт в карточке CRM (referral-registration.md, раздел «Назначение»).
  5. Интеграционное событие. Публикуется только ReferralLeadAttachRequestedKafkaEvent (pin.referral.lead-attachments.v1, key = InvestorUserId; payload: InvestorUserId = event.UserId, AgentUserId = link.OwnerUserId, AgentCompanyId = link.TenantId, ReferralLinkId = link.Id, Channel = link.Channel, AppliedRule = R3, BondId = null — связи нет, RequestedAt = now()). Событие фиксируется согласованно; затем подтверждается (ack).
  6. Downstream. crm создаёт карточку лида «агент ↔ инвестор» (дедуп активной пары на стороне CRM — у пары одновременно один активный лид); rewards события НЕ получает — основания для выплат нет.

Альтернативные Потоки

A1. RegisteredAt = null в реплике (пользователь без RegisteredAt)

  1. Дата регистрации неизвестна (first-seen пришёл с Version > 1 до backfill) → окно 4 ч считается истёкшим (fail-closed, решение 5 README.md): работает то же правило R3. Поток не меняется.

A2. Владелец ссылки — не агент/застройщик

  1. INV-REF-002 не выполнен (модификатор R5): лид не запрашивается; связи по R3 тоже нет → полный no-op (structured log с исходом guard-а). Событие подтверждается. Завершение.

A3. У инвестора уже есть активная связь с другим агентом

  1. R3 связь всё равно не создаёт, активная связь с агентом A не трогается (INV-REF-001).
  2. Лид агенту B запрашивается — несколько агентов могут отслеживать одного инвестора. Поток не меняется.
  1. Каждый вход с ReferrerUrl снова публикует lead-событие с тем же бизнес-ключом (InvestorUserId, AgentUserId); CRM дедуплицирует — активная пара одна, дубль карточки не создаётся (attach-rules.md, «Дедупликация лидов»). Событие подтверждается.

Постусловие

  • В referral НЕ появилось ни ReferralBondEntity, ни записи журнала (getMyReferrer инвестора по-прежнему hasReferrer = false, если связи не было).
  • В CRM запрошена (или дедуплицирована) карточка лида «агент ↔ инвестор» с AppliedRule = R3, BondId = null.
  • rewards никаких событий не получил — выплат по этому сценарию не будет (INV-REF-003).

Возможные Ошибки

КодHTTPУсловиеПоведение
— (no-op, warning)— (Kafka consumer, HTTP нет)Guard G1–G4: битый slug, не инвестор, self-attach, blockedМетрика no-op guard-ов
— (полный no-op)Владелец не агент/застройщик (A2, R5/INV-REF-002)Событие подтверждается
retry consumer-аРеплика пользователя/владельца отсутствуетRetry
DLQ после исчерпания retryИнфраструктурный сбойRunbook referral-consumer-lag (README.md)

Доменные События

СобытиеКогда поднимаетсяSubscribers
Не поднимаются: агрегаты referral в этом сценарии не создаются и не мутируются

Kafka Интеграционные События

СобытиеTopicКогда публикуетсяConsumers
ReferralLeadAttachRequestedKafkaEventpin.referral.lead-attachments.v1Правило R3: владелец — Agent/DeveloperManager (шаг 5); BondId = nullcrm (карточка лида, дедуп активной пары)

Acceptance Criteria

#КритерийПроверка
AC1Вход с ReferrerUrl при IsNameFilled = true и регистрации 5 ч назад → связь НЕ создана, журнал пуст, lead-событие с AppliedRule = R3, BondId = nullинтеграционный тест
AC2getMyReferrer инвестора после сценария → hasReferrer = falseAPI-тест
AC3RegisteredAt = null → тот же исход R3 (fail-closed)тест реплики без RegisteredAt
AC4Владелец-инвестор → полный no-op: ни события, ни записейнегативный тест (см. также UC-REF-006)
AC5Повторный вход → повторное lead-событие; в CRM активная пара одна (дедуп)e2e с crm-стабом
AC6rewards не получает событий по R3проверка топика pin.referral.bonds.v1 пуст
AC7Активная связь с агентом A не изменяется при лиде агенту Bтест A3 (INV-REF-001)
AC8Владелец-агент со Status ∈ {Blocked, Archived} → лид не запрашивается (guard owner.Status = Active): полный no-op, связи по R3 всё равно неттест заблокированного владельца-агента

Обратные ссылки

Автоссылки: где используется этот документ.

Связанные Документы