offplan · online
Session · conv-16

Session CONV-16

In Progresssessionconv-16

Resume Prompt

Continue /plan plans/permission-and-tenancy-model.md — paused mid-interview after Block C2 closed. Pick up at Block C → C3: Buyer visibility scope (что видит Buyer на странице после magic link click — только shortlist, все available units проекта, или filtered subset?). After C3 → C4 (reservation lock + race-condition resolution) → D (URL routing + multi-role auth flow) → E (invitations forward+reverse + token mechanics + guest→Partner upgrade) → F (referral data model) → G (edge cases: suspension, GDPR) → H (final tech-estimate spec для Ильи). Финальный output: заполненный plan-файл (status → ratified) + ADR 0009 (Tenancy & Permission Architecture) + ADR 0010 (Stock allocation strategy). Полное interview state — в memory plan_permission_tenancy_state.md. Не запускать другие sub-/plan'ы (1.2, 1.7, 1.11) до ratification — они все depend on Phase 1.3.

Summary

Single-purpose /plan interview for Phase 1.3 (Tenancy & Permission Model). Worked through Block A (entity model — Partner / users / buyer / billing), Block B (permissions — 5 roles + matrix + scoping), and Block C partially (C1 stock allocation model + C2 targets/cascade). All major architectural decisions on tenancy closed: Partner = paying entity, multi-select studio/agency/developer type, one-email-one-identity with workspace switcher, Модель 4 billing (each org = Partner with tier + free guest tier conversion path), Buyer = passwordless per-presentation magic link. Permission matrix defined for 5 roles (Owner / Admin / Manager / Editor / Agent) with Manager merged as operational sales lead = Editor + stock + buyers. Stock allocation: S·1 (Shared default + Single allocation), assignment = exclusivity scope, Stage 1 supports guest-organisation + specific-personal-user as targets. No code/files in repo changed — pure interview session; outputs are memory entries that /resume will replay.

Changes

Decisions

Billing Model 4 (Tier-based + free guest organisations). Каждая организация = Partner с tier'ом, может приглашать guest organisations бесплатно. Free Guest tier = можно быть guest в чужих проектах, нельзя создать свои. Conversion path: «нужен свой проект → upgrade». Rejected: Модель 1 (каждая организация платит сама) — high friction onboarding в реальном off-plan рынке (developer обычно платит за весь sales-stack); Модель 2 (host-подписка покрывает экосистему free) — низкий ARPU per user, риск abuse; Модель 3 (per-seat Figma-style) — complex billing, friction на каждое добавление пользователя. Модель 4 единственная покрывает reverse case (Agency хочет multi-developer dashboard со своими проектами) и self-service growth (guest pробует → upgrade до Partner).

Buyer identity: passwordless magic link, per-presentation scope. Buyer = конечный покупатель квартиры (не Partner, не платит). Получает email с magic link → видит свой shortlist (heart-юниты помеченные Agent'ом во время презентации). Per-presentation scope = одна magic link сессия на одного buyer'а от одного Agent'а; глобальная buyer-identity (один кабинет на все презентации) отложена в Stage 2. Rejected: (A) запись без логина — buyer теряется если потерял email, не может отметить «передумал»; (C) full identity с паролем — friction убивает conversion на B2B2C voronk'е.

Stock allocation S·1 (Shared default + Single). Default = все юниты shared (видны всем members + всем guest organisations с project membership), assignment делает unit exclusive только для assigned party + Owner/Admin/Manager партнёра-владельца (Editor видит всё всегда, assignment его не блокирует — content access vs sales access разделены). Multi-allocation (один unit нескольким parties одновременно) отложено в Stage 2 как opt-in per-project. Rejected: W·1 (white-list default) требует обязательного assign-step при создании юнита что замедляет onboarding; S·M / W·M (multi-allocation) увеличивает risk double-sale что Роман явно назвал critical fail. S·1 автоматически защищает: на момент reserve у юнита один правовой owner.

5 ролей; Manager = объединённая operational роль (Editor + stock + buyers). Рассматривался strict-Manager (без content access), но Sergey предпочёл (c) объединение — для оперативных правок Manager не должен звать Editor. Editor получил permission менять цену юнита (цена = часть unit-content). Agent получил permission менять status own units (available → reserved → sold) — без этого после каждой продажи нужен звонок Manager'у, bottleneck. Один user = одна role per Partner (если нужно и контент и продажи → Admin). Custom roles → Stage 2.

Org-level scoping default + project-level option в Stage 1. Personal invites через Settings → Team по умолчанию org-level (Иван — Agent во всех проектах Partner'а). Project-level scope доступен в Stage 1 для случая фрилансера на один проект. Guest organisation members наследуют project-level membership автоматически (приглашение по организации, members наследуют). Per-action scope, time-limited memberships, sub-project scoping — Stage 2.

Cascade при удалении allocation target'а: escalate up, never auto-shared. User leaves → revert assignments к Manager/Admin партнёра + audit + email notification. Guest org removed → revert к Owner-team + notification. Auto-revert к shared rejected — риск что unit вдруг становится «продавайте все» без явного согласия Owner'а; всегда escalate up к человеку который владеет проектом.

Stage 1 allocation targets: guest organisation + specific personal user. Покрывает 90% реальных кейсов (Developer + 2-3 agency, inhouse VIP-broker). Specific user inside guest org (Маша из E&V персонально), personal role group (all Senior Agents), internal team/department — отложено в Stage 2.

Bulk operations через filter+checkbox+dropdown. В Stage 1 — filter list view + multi-select checkboxes + dropdown «Assign to». CSV import убран (покрывается AI file upload Phase 1.5.X — MCP wrapper для PDF/Excel). Range-select на floorplate — Stage 2 (nice UI, не критично).

Project ownership transfer отложено в Stage 2/3. Reverse invite (VV создаёт проект → приглашает иностранного Developer'а как guest organisation) работает без transfer'а — проект продолжает «жить» в VV-tenancy, Developer работает там как partner. Self-service ownership transfer (проект уходит из VV-tenant в Developer-tenant с миграцией данных) — manual через support до Stage 2.

Next Steps

  1. Resume /plan plans/permission-and-tenancy-model.md at Block C → C3 (Buyer visibility scope: что видит Buyer на странице после magic link click — только shortlist, все available units проекта, или filtered subset?)
  2. After C3: C4 (reservation lock + race-condition resolution) → D (URL routing + multi-role auth flow) → E (invitations forward+reverse + token mechanics + guest→Partner upgrade) → F (referral data model) → G (edge cases — suspension, GDPR) → H (final tech-estimate spec для Ильи)
  3. Финальный output /plan: заполненный plans/permission-and-tenancy-model.md (status → ratified) + ADR 0009 (Tenancy & Permission Architecture) + ADR 0010 (Stock allocation strategy)
  4. После ratification — отправить tech-estimate request Илье на 10 subtasks Phase 1.3
  5. Workstream stage1-roman-integration: tick первый sub-plan task после ratification + advance к sub-plan 2 (onboarding-trial-mode)

Open Questions

Context for next session