SHARENTA — продуктовый аудит и дорожная карта

Дата: 23 сентября 2026
Основание: код репозитория (веб: Next.js App Router, контур applyContourAction, Android Compose-клиент того же /api/contour).
Не проверялось в браузере в этом аудите. Часть сценариев (вход, каталог, сделка) подтверждалась ранее на локальном пилоте; текущий документ не считает UI «готовым» только по названию экрана.

Главная функция продукта: соединять арендодателя и арендатора, помочь найти вещь, договориться и вернуться за следующей арендой. Ориентир механики — BlaBlaCar: нашёл предложение → связался → организовал сделку в интерфейсе. SHARENTA при этом остаётся площадкой аренды вещей, а не поездок.

Платежи, SMS, внешний KYC и УКЭП не подключены — это честно отражено в UI (SettlementNotice, копирайт KYC). Этот план не предлагает подключать провайдеров, пока владелец продукта явно не решит иначе.

1. Краткое описание текущего продукта

SHARENTA — рабочий городской пилот: публичный каталог, карта OSM, карточка юнита, заявка на даты, чат сторон, цепочка сделки (заявка → документы → подписи → фото выдачи → аренда → фото возврата → отзыв), кабинет с двумя рейками CRM, модерация объявлений и ручной KYC.

Слоган в шапке: «Найди. Возьми. Верни.»

Что уже является настоящим контуром, а не макетом:

• Поиск и фильтры (/api/catalog, applyFilters) по названию, бренду, модели, описанию, характеристикам, категории, цене, рейтингу, городу, датам.
• Бронь с блокировкой пересечений (canCreateBooking, BUSY_BOOKING_STATUSES, advisory lock в Postgres).
• Чаты, привязанные к объявлению/сторонам.
• Документы сделки генерируются при подтверждении владельца (шаблоны + хеш содержимого, не УКЭП).
• Выдача и возврат требуют фото и чек-лист.
• Отзыв после completed: арендатор — о юните, владелец — об арендаторе.
• Избранное, городская подписка на пустой город, тикеты поддержки, in-app уведомления, буст в ранжировании без оплаты.

Что выглядит как продукт, но не является законченной пользовательской ценностью: тарифы PRO/MAX, реферальные выплаты, каналы push/email/telegram, «просмотры» в аналитике, сортировка «по расстоянию», процент ответов владельца, Android-цифры рефералки.

2. Фактический статус существующих функций

Легенда статуса:

2.1. Обнаружение

2.2. Аккаунт и создание предложения

2.3. Сделка и общение

Цепочка статусов брони (код):
requested → documents (кнопка «Подтвердить») → signed → active → completed, либо rejected / cancelled / expired / noshow / unreturned.
Статус confirmed в типах есть, в живом пути почти не сохраняется.

2.4. Возврат, рост, админка, Android

Дубли, которые не надо плодить вторым контуром: избранное vs listing.favorites (счётчик); кабинет vs /landlord; буст «в ленте» и «в поиске» (один флаг); документы сделки vs legacy documents; чат с карточки, из брони и из профиля.

3. Сценарий A. Арендатор

Узкое место сценария A: после «нашёл» следующий шаг — либо жёсткая заявка с KYC, либо спрятанный чат. Нет мягкого BlaBlaCar-шага «написать и договориться», а отказ владельца обнуляет путь.

4. Сценарий B. Арендодатель

Узкое место сценария B: объявление появляется «не там» на карте и без календаря, а на входящую заявку можно только да/нет.

5. Список обнаруженных продуктовых проблем

1. Связь со владельцем слабее брони. Основной CTA — «Забронировать». Чат вторичен. Текст заявки не становится сообщением в треде.
2. Нет торга по датам. Отказ конечен; согласование = новая заявка и снова KYC-гейт.
3. Новое объявление врёт карте. publishDraft пишет lat/lng Арбата и distanceKm: 0.3 независимо от города.
4. Календарь не часть публикации. Владелец закрывает дни только после создания.
5. Пустой поиск беднее пустого города. City empty: соседние города + watch. Search empty: одна фраза.
6. KYC ручной — стоп-кран первой аренды. Новый человек не отправляет заявку, пока админ не нажмёт Verify.
7. Статусы сделки говорят на двух языках (booking vs deal; кнопка «Подтвердить» пишет documents).
8. «Проверен» и «просмотры» и «% ответов» и «по расстоянию» выглядят как живые метрики, часть из них — сиды или константы.
9. Уведомления существуют только внутри открытого сайта. Для BlaBlaCar-ритма «написал — ответил» этого мало, но внешние каналы — отдельное продуктовое решение, не инфраструктурный фетиш.
10. PRO/буст/реферал продают то, чего нет (оплата, выплаты, права PRO). Это ломает доверие сильнее, чем отсутствие функции.
11. Возврат пользователя не собран: нет recently viewed, похожих, repeat booking, follow.
12. Android отстаёт точечно (фейковая рефералка опаснее отсутствующего CRM).
13. Дубли кабинетов повышают стоимость любой доработки хозяина.

Не проблемы этого плана (уже сделано или сознательно отложено): поиск по каталогу, антидаблбук, фото сделки, честный копирайт «деньги мимо платформы», модерация, избранное, city watch.

6. Приоритетный список P1 / P2 / P3

Правило: P1 — без этого трудно найти → связаться → договориться → арендовать. P2 — быстрее договариваются и возвращаются. P3 — рост бизнеса. Не включать то, что уже работает.

P1

#### P1-1. Вопрос владельцу как равный шаг рядом с заявкой

• Проблема: арендатор не понимает, что можно написать до брони; текст заявки пропадает из диалога.
• Для кого: обе стороны.
• Сейчас: openConversation с иконки; createBooking.message лежит на брони.
• Сделать: на PDP вторая явная кнопка «Написать»; при заявке копировать message первым сообщением в связанный чат; с брони — тот же тред.
• Зависимости: нет.
• Почему P1: это механика BlaBlaCar без новой сущности.
• Готово когда: с карточки и из заявки открывается один чат по юниту; текст заявки виден владельцу в чате.
• Тесты: contour createBooking создаёт/линкует conversation + user message; браузер: карточка → чат; бронь с текстом → тред содержит текст.

#### P1-2. Ответ на заявку: другие даты или короткий отказ, не только «нет»

• Проблема: отказ убивает сделку; согласование дат невозможно внутри заявки.
• Для кого: обе стороны.
• Сейчас: setBookingStatus confirm/reject.
• Сделать: действие владельца «предложить даты» (новые start/end, бронь остаётся или переходит в ожидание ответа арендатора) + опциональный комментарий при отказе, уходящий в чат. Не плодить вторую CRM.
• Зависимости: P1-1 (чат как канал).
• Почему P1: иначе «договориться» вне платформы или с нуля.
• Готово когда: владелец может сменить период без новой заявки; арендатор принимает/отклоняет; пересечения по-прежнему блокируются canCreateBooking.
• Тесты: overlap lock на предложенных датах; UI оба статуса; нельзя занять чужой busy span.

#### P1-3. Честная точка на карте и город при публикации

• Проблема: все новые юниты сидят в одной точке Арбата; карта и «рядом» врут.
• Для кого: арендодатель (ввод), арендатор (поиск).
• Сейчас: publishDraft hardcode lat/lng/district; город — текстовое поле.
• Сделать: выбор города из тех же CITIES + ручной пин на карте или адрес → lat/lng; district не подставлять «Арбат», если город другой; distanceKm не показывать, пока нет гео пользователя (лучше скрыть, чем врать).
• Зависимости: нет.
• Почему P1: без этого карта и «рядом с вами» ломают доверие к каталогу.
• Готово когда: объявление в Казани не рисуется на Арбате; редактирование тоже меняет координаты.
• Тесты: publish с городом ≠ Москва; карта показывает пин; регресс фильтр listingInCity.

#### P1-4. Доступность в мастере создания

• Проблема: владелец публикует «всегда свободно», календарь находит только потом.
• Для кого: арендодатель, косвенно арендатор.
• Сейчас: unavailableDates через toggleListingDate после создания.
• Сделать: шаг или блок в review: закрыть дни до отправки на модерацию. Не отдельный продукт календаря.
• Зависимости: нет (усиливает P1-2).
• Почему P1: заявки на занятые дни = лишние отказы.
• Готово когда: дни, закрытые в мастере, видны на PDP и блокируют createBooking.
• Тесты: publish с unavailableDates; book на закрытый день отклоняется.

#### P1-5. Пустой поиск с следующим действием

• Проблема: «нет таких юнитов» заканчивает сценарий.
• Для кого: арендатор.
• Сейчас: EmptyState без CTA; CityEmptyState уже умеет соседей и watch.
• Сделать: переиспользовать паттерн city empty: снять фильтр, соседний город, «смотреть всю категорию», watch города если пусто из‑за города. Не делать want-ad в P1.
• Зависимости: city watch уже есть — не дублировать тип подписки.
• Почему P1: поиск — главный вход; тупик убивает цикл.
• Готово когда: на нуле результатов ≥2 действия, которые меняют выдачу или оставляют watch.
• Тесты: UI-тест/браузер: запрос без хитов показывает CTA; watch не создаётся дважды.

#### P1-6. Понятный статус заявки одним языком

• Проблема: «Подтвердить» ≠ confirmed; арендатор не видит «что делать завтра».
• Для кого: обе стороны.
• Сейчас: Deal Workspace + сырые статусы.
• Сделать: чеклист на /bookings/[id]: заявка → ответ владельца → подписи → фото выдачи → аренда → фото возврата → отзыв. Без новой state-машины, только UX поверх существующих статусов.
• Зависимости: нет.
• Почему P1: организация сделки — ядро продукта.
• Готово когда: обе стороны на одном экране видят текущий шаг и единственную кнопку следующего.
• Тесты: снапшот копирайта по статусам; регресс canOwnerAct / canRenterCancel.

#### P1-7. Снять ложные бейджи с нового объявления

• Проблема: verified: true при публикации; сорт «по расстоянию» по сиду.
• Для кого: арендатор (доверие).
• Сейчас: publishDraft + filters.sort === "distance" по distanceKm.
• Сделать: verified только после модерации/KYC владельца (как решите в вопросах); скрыть или переименовать сорт, пока нет гео.
• Зависимости: P1-3 для честного distance.
• Почему P1: вранье метрик хуже отсутствия метрик.
• Готово когда: свежий юнит без галочки «Проверен», пока модерация не прошла; сорт distance не обещает GPS.
• Тесты: publish → listing.verified false; модерация approve не обязана ставить verified, если это другой смысл (зафиксировать в копирайте).

P2

#### P2-1. Похожие объявления на карточке

• Проблема: сравнение только «назад в ленту».
• Для кого: арендатор.
• Сейчас: SQL similarity для ранга поиска; AI-текст.
• Сделать: блок 4–8 юнитов той же категории/города, исключая текущий. Не персональный ML.
• Зависимости: каталог уже есть.
• Готово когда: PDP внизу кликабельная сетка; пусто, если кандидатов нет.
• Тесты: не показывает себя; только status=active.

#### P2-2. Недавно просмотренные + счётчик просмотров владельца

• Проблема: аналитика врёт; арендатор не возвращается к вчерашней карточке.
• Для кого: обе стороны.
• Сейчас: views сид/поле без инкремента.
• Сделать: писать просмотр (уникальный за сессию) в контур; лента «смотрели» в кабинете/поиске. Без отдельной аналитической платформы.
• Зависимости: нет.
• Готово когда: открытие PDP увеличивает views; владелец видит то же число в analytics.
• Тесты: contour increment; гость не падает.

#### P2-3. Повторить аренду

• Проблема: повтор = ручной поиск юнита.
• Для кого: арендатор.
• Сейчас: /bookings история.
• Сделать: на completed «Запросить снова» → /book/[id] с теми же дефолтными длительностями, если юнит active.
• Зависимости: бронь уже умеет даты из URL (readBookDates).
• Готово когда: один тап из истории.
• Тесты: paused listing не даёт CTA.

#### P2-4. Избранное заметнее; подписка на владельца — нет, если не решите иначе

• Проблема: избранное спрятано в кабинете.
• Для кого: арендатор.
• Сейчас: /favorites работает.
• Сделать: вход из кабинета уже есть — добавить сердце в шапку или счётчик. Не делать «коллекции». Follow владельца — только если P2-3 и избранного мало (см. вопросы).
• Зависимости: нет.
• Готово когда: избранное открывается за один тап с главной оболочки.
• Тесты: гостевое избранное по-прежнему claim после логина.

#### P2-5. Instant confirmation — только после решения PM

• Проблема: каждая заявка ждёт человека.
• Для кого: обе стороны.
• Сейчас: всегда requested.
• Сделать: флаг объявления «подтверждать сразу», если календарь закрыт и нет пересечений; иначе не трогать.
• Зависимости: P1-4, вопрос владельца продукта.
• Готово когда: юнит с флагом создаёт бронь сразу в documents (или согласованный статус) без кнопки владельца; без флага — как сейчас.
• Тесты: overlap + instant не обходит lock.

#### P2-6. Сохранённый поисковый запрос

• Проблема: watch только на город.
• Для кого: арендатор.
• Сейчас: watchCity.
• Сделать: не начинать, пока не закрыт P1-5. Затем: сохранить текущие query+фильтры, notice при новом listing-хите. Расширить city watch, не плодить второй inbox.
• Зависимости: P1-5.
• Готово когда: из поиска «сообщить, если появится»; срабатывает на createListing после модерации.
• Тесты: не спамит на каждое обновление контура.

#### P2-7. Быстрые ответы владельца

• Проблема: типовые вопросы каждый раз с нуля.
• Для кого: арендодатель.
• Сейчас: свободный чат.
• Сделать: 3–5 шаблонов в чате («сегодня свободны», «залог X», «встреча у метро»).
• Зависимости: P1-1.
• Готово когда: вставка текста, не автобот.
• Тесты: сообщение сохраняется как обычное user message.

#### P2-8. Честность Android-рефералки и сервисов

• Проблема: нативные цифры 12/8/4250 ₽ расходятся с вебом.
• Для кого: обе стороны на Android.
• Сейчас: ReferralScreen MiniStat hardcoded; web referralStats().
• Сделать: те же числа, что веб, или убрать блоки. Не чинить весь паритет Android в P2.
• Зависимости: нет.
• Готово когда: нет зашитых KPI.
• Тесты: ручной экран / снимок.

#### P2-9. Переписка по тикету поддержки

• Проблема: тикет — одно сообщение без ответа.
• Для кого: обе стороны + админ.
• Сейчас: create + смена статуса.
• Сделать: простые реплики в том же тикете (не новый мессенджер). Связать «чат поддержки» копирайтом с тикетами, не с /messages.
• Зависимости: нет.
• Готово когда: пользователь видит ответ админа.
• Тесты: contour addTicketMessage; права только стороны и админ.

P3

Не делать, пока P1 не закрыт. Кратко, чтобы не изобретать заново:

7. Рекомендуемый порядок разработки

Не параллелить новый кабинет, новый мессенджер и PRO.

1. P1-1 чат = канал договорённости (включая текст заявки).
2. P1-6 чеклист статусов на существующей сделке (быстрый UX, снижает путаницу пока идут 3–5).
3. P1-7 убрать ложные бейджи/сорт.
4. P1-3 точка на карте при создании и редактировании.
5. P1-4 дни недоступности в мастере.
6. P1-2 встречные даты (опирается на чат и календарь).
7. P1-5 пустой поиск.
8. P2-3 repeat из истории.
9. P2-1 похожие на PDP.
10. P2-2 просмотры как правда.
11. P2-4 вход в избранное.
12. P2-7 шаблоны ответов.
13. P2-8 Android реферал не врать.
14. P2-9 ответы в тикетах.
15. Остальное — после ответов в §10 (instant, saved search, PRO, каналы, want-ad).

Android: повторять те же P1 на уже существующих экранах Compose, не поднимать отдельный продукт. Исключение — P2-8 сразу, это баг доверия.

8. Зависимости между задачами

P1-1 (чат)
  ├── P1-2 (другие даты в том же диалоге)
  └── P2-7 (шаблоны)

P1-3 (пин)
  └── P1-7 (distance имеет смысл только после пина / скрытия сорта)

P1-4 (календарь в create)
  ├── P1-2 (предложение дат)
  └── P2-5 (instant book, если разрешите)

P1-5 (пустой поиск)
  └── P2-6 (saved search)

P2-3 (repeat)
  └── P3-10 (follow — опционально)

PRO / оплата / want-ad / hourly / multi-unit
  └── ничего из P1; не начинать раньше решения PM

Существующие модули, на которые опираться, а не заменять: applyContourAction, canCreateBooking, useCatalogListings, CityEmptyState, DealWorkspace, watchCity, dual CRM.

9. Критерии готовности (сводка)

См. поле «Готово когда» у каждой задачи. Общий критерий пилота сценария:

Новый арендатор без демо-карточек: находит юнит в своём городе → пишет владельцу или шлёт заявку с текстом в чате → владелец предлагает другие даты или подтверждает → обе стороны видят один следующий шаг → фото выдачи → фото возврата → отзыв → из истории можно запросить тот же юнит.

Новый арендодатель: публикует фото, цену, свою точку, закрытые дни → после модерации юнит на карте там, где указал → видит входящую заявку и отвечает не только «нет».

Регрессы, которые нельзя сломать: нет двойной брони, гость не читает чужие чаты, KYC-копирайт не обещает OCR, деньги аренды не «принимаются» UI, AI не выдумывает юниты.

10. Вопросы владельцу продукта

Без этих ответов часть бэклога нельзя честно брать в работу.

1. KYC до первой заявки: оставить ручной стоп (сейчас так) или разрешить заявку/чат, а выдачу держать до Verify? Это главный тормоз сценария A.
2. Instant book: нужен ли флаг «подтверждать сразу», или пилот всегда с живым «да» владельца (ближе к BlaBlaCar)?
3. Деньги: аренда по-прежнему только напрямую? Буст/PRO остаются бесплатной записью в контур или прячем витрину /services, пока нет провайдера?
4. PRO: реальные права (лимиты объявлений, сотрудники) или убрать маркетинговые тарифы, чтобы не обещать кабинет компаний?
5. Гео пилота: один город / список CITIES / свободный ввод города мира? От этого зависит P1-3.
6. Want-ad («ищу дрель»): нужен в этой волне или достаточно city watch + пустой поиск?
7. Каналы связи: достаточно in-app на пилот или нужен хотя бы email на «новая заявка» / «вам написали»?
8. Подписка на владельца vs усилить избранное и repeat — что ближе к «вернуться»?
9. Android: паритет P1 на тех же экранах или веб — источник правды, приложение догоняет позже?
10. Галочка «Проверен» на юните: это KYC владельца, модерация объявления или ручной бейдж? Сейчас смыслы смешаны (listing.verified vs user.kyc).

Метод и ограничения аудита

• Читались страницы src/app/**, контур src/lib/contour.ts, типы, каталог, deal-engine, CRM, Android Store.kt / экраны.
• Не запускался полный ручной прогон всех 14 шагов A/B в этом аудите.
• Не предлагается перепись стека, микросервисы, смена дизайн-системы, вторая библиотека компонентов.
• Функции, которые уже есть, не стоят в бэклоге как новые.

Сводная таблица