RepWay

Рабочая документация проекта. Файл можно свободно менять, дополнять и использовать как основу для ТЗ, презентации, инструкции клиенту или внутренней базы знаний.

Версия v0.1.11 от 19.06.2026

Фокус версии: удобство списка черновиков отчетов.

Что изменено:

в каждой карточке черновика отчета добавлена кнопка Предпросмотр;
выбранный черновик подсвечивается в списке;
карточка черновика больше не сжимает заголовок в узкую колонку;
мелкой строкой показывается, когда черновик создан и когда обновлен;
предпросмотр переключает верхний блок отчета без публикации.
в Фото сайта выровнена строка кнопки Открыть страницу применения и описания;
в Фото сайта добавлено явное пояснение по ограничениям загрузки: до 8 МБ за файл и до 6 изображений в одном отчете.
в карточке отправленного фото-отчета добавлена кнопка Добавить в отчет;
если черновика отчета еще нет, RepWay создает его автоматически и добавляет выбранный фото-отчет;
в редакторе отчета выбранные фото-отчеты выводятся отдельным раскрывающимся блоком;
в публичном отчете выбранные фото-отчеты также открываются по клику, с галереей изображений и ссылкой на страницу применения.

Версия v0.1.9 от 19.06.2026

Фокус версии: рабочее удобство формы Фото сайта.

Что изменено:

добавлена кнопка Сохранить черновик для отчета по изображениям;
добавлена кнопка В архив: текущая форма переносится в архив черновиков и очищает рабочий экран;
архив черновиков раскрывается под формой, запись можно вернуть или удалить;
черновик сохраняется локально отдельно для каждого проекта;
добавлена кнопка Очистить экран, чтобы сбросить заполненную форму и сохраненный черновик;
после успешной отправки на согласование черновик очищается автоматически.

Версия v0.1.8 от 19.06.2026

Фокус версии: доработка раздела Фото сайта.

Что изменено:

описание отчета по изображениям стало заметнее и выводится справа от кнопки Открыть страницу применения;
поправлена верстка, чтобы описание не наезжало на галерею изображений;
специалист может редактировать отчет по изображениям до согласования заказчиком;
после статуса Согласовано редактирование блокируется и в UI, и на API.

Версия v0.1.7 от 18.06.2026

Фокус версии: мобильная установка RepWay без отдельной нативной разработки.

Что изменено:

добавлен PWA manifest для iOS и Android;
добавлены иконки приложения 180, 192 и 512 px;
подключена регистрация service worker без жесткого кеширования рабочих данных;
добавлены мета-настройки для режима standalone на iPhone и Android;
RepWay можно установить на экран телефона из браузера.

Версия v0.1.1 от 14.06.2026

Фокус версии: убрать путаницу между рабочей моделью специалиста и понятным клиентским интерфейсом.

Что изменено:

лендинг переписан из внутренней документации в более понятную витрину продукта;
первый экран лендинга теперь объясняет пользу RepWay: клиенты, брифы, SEO-данные, согласования и отчеты;
блок Зачем клиент, проект и вся структура заменен на нормальные секции Для кого RepWay и Как это работает;
крупные визуальные примеры перенесены ниже и стали компактнее;
в клиентском кабинете слово Проект постепенно заменяется на более понятные формулировки Сайт, Бриф, Отчет, Согласование;
пункт меню Брифинг проекта в режиме заказчика отображается как Бриф;
в клиентском брифе добавлены поля Название брифа и Сайт;
из клиентского брифа убран странный выбор Работа / сайт с текстом Работа еще не создана специалистом;
сайт из формы брифа сохраняется в текст брифа и виден специалисту;
демо-логика больше не должна подсовывать заказчику ООО Ромашка в форме брифа, если у него нет реального клиентского проекта.

Продуктовое правило после этой версии:

специалист внутри системы должен думать категориями заказчик -> направление -> клиентский проект -> задачи -> отчеты;
заказчик должен видеть простые сущности: сайт, бриф, согласования, задачи, отчеты;
термин Клиентский проект используется для рабочего объекта специалиста по конкретному заказчику;
слова работа, заказ, заказы, работы клиентов не использовать как основные названия разделов, чтобы не смешивать заявку, направление и проект.

1. Что мы создаем

RepWay - платформа для специалистов, агентств и заказчиков, где можно вести проекты по SEO, созданию сайтов, рекламе и аналитике.

Главная идея: специалист работает внутри проекта, собирает данные, формирует задачи, отчеты, стратегии, согласования и показывает заказчику понятную картину без хаоса из таблиц, скринов и переписок.

1.0. Текущий фокус перед хостингом

Сейчас задача - не распыляться на мелочи, а довести платформу до тестового внешнего запуска.

Приоритеты:

стабилизировать обязательный путь: вход, организация, клиент, проект, задачи, отчет, Яндекс;
держать новые идеи в плане, но внедрять только то, что можно проверить в реальном интерфейсе;
перед переносом выполнить актуальные SQL-патчи в Supabase;
на сервере использовать отдельный .env.production, а не локальный .env.local;
проверить production-переменные через npm run check:env и /api/health;
заменить локальные URL Яндекса и Supabase на домен;
запускать приложение через PM2 и Nginx;
перед реальными клиентами ограничить регистрацию и проверить роли доступа.

Рабочие файлы для переноса:

DEPLOY_PLAN.md - инструкция по переносу на сервер;
DEPLOY_CHECKLIST.md - короткий чеклист перед запуском;
SECURITY_CHECKLIST.md - что закрыть перед реальными клиентами;
ecosystem.config.cjs - PM2-конфиг;
scripts/check-env.mjs - проверка переменных окружения;
/api/health - быстрая проверка живого сервера.

1.1. Что уже внедрено (сейчас)

Роли и доступ:
режимы executor и client,
внутренний тариф Internal,
отдельные роли в организации и базовые ограничения по видимости.
Клиенты и проекты:
создание/редактирование клиента,
контакты и договорные поля (контакт, телефон, Telegram, роль, статус оплаты),
создание проектов по типам website, seo, ads, complex.
Основные рабочие блоки:
проектный центр, бриф, задачи, согласования,
документы проекта: договоры, счета, акты и PDF-просмотр внутри проекта,
фото-отчеты сайта с галереей, одобрением и замечаниями заказчика,
отчеты и публикация в /share/[token],
обратная связь специалиста и клиента по цепочке.
Интеграции и API:
Яндекс OAuth и сохранение подключения,
Яндекс.Метрика, Яндекс.Вебмастер, Яндекс.Директ,
сохранение синхронизированных данных в БД и история обновлений.
SEO-модули:
семантика (CSV/ручной ввод),
стратегия с горизонтами,
инструменты: SERP, Wordstat, индексация, аудит.
Продуктовая надстройка:
встроенная help-инструкция,
роли-ориентированная навигация,
глобальная read-only админка владельца платформы,
регистрация заказчика с заявкой на услугу,
тарифная модель и лимиты.

1.2. Матрица доступа для тестового запуска

На тестовом запуске доступ специально закрывается консервативно: лучше показать меньше, чем случайно открыть чужой рабочий кабинет.

Заявки заказчиков:

владелец RepWay видит все входящие заявки в Админка -> Платформа;
специалист/агентство видит только заявки, назначенные на его кабинет, в разделе Заявки;
заказчик не видит общую воронку заявок и не видит заявки других заказчиков.
прямой API-доступ закрыт так же, как UI:
/api/platform/admin/overview и назначение заявки требуют email владельца RepWay из REPWAY_PLATFORM_OWNER_EMAIL;
/api/client-requests/assigned возвращает только заявки текущего кабинета специалиста и доступен владельцу/админу этого кабинета;
действие Взять в работу меняет только заявку, где assigned_workspace_id совпадает с кабинетом текущего специалиста.

Клиенты:

специалист/агентство видит только клиентов, где его кабинет имеет роль owner или admin;
участники с ролью просмотра не получают рабочий раздел управления клиентами;
заказчик работает через свой клиентский кабинет и не видит список клиентов специалиста.
прямой доступ через Supabase закрывается RLS:
organizations читаются только через can_read_organization;
organization_members показывают пользователю только его членство или участников организаций, где он owner/admin;
projects читаются только через доступ к своей организации;
обновление карточки клиента разрешено только owner/admin организации.
актуальный SQL-патч для этого слоя: supabase/harden-client-access.sql.

Проекты:

специалист/агентство видит только проекты управляемых клиентов;
заказчик видит только проекты организаций, куда он приглашен;
если доступа к проекту нет, проектный центр не открывается и показывается уведомление Нет доступа к этому проекту;
при пустом кабинете специалист попадает на дорожную карту, а не в чужой проект.
переключатель проекта в верхней панели принимает только проекты из разрешенного списка текущего режима;
сохраненный в браузере activeProjectId не считается доступом: если проект не входит в список доступных, интерфейс переключается на первый разрешенный проект;
после создания проекта pending-переход открывает только проект управляемого клиентского кабинета;
дочерние данные проекта закрываются теми же функциями:
can_read_project для просмотра отчетов, задач, согласований, SEO-данных и Яндекс-метрик;
can_manage_project для создания/изменения задач, отчетов, импортов, семантики и синхронизаций.

Служебные разделы:

Платформа доступна только владельцу RepWay из REPWAY_PLATFORM_OWNER_EMAIL;
Сообщество доступно владельцу RepWay и кабинетам с тарифом Tester;
SEO-инструменты дополнительно проверяют тариф и тип проекта.

SEO и рабочие инструменты:

заказчик не видит рабочие инструменты специалиста: Яндекс, Директ, Семантика, Импорт, Инструменты, Популярные запросы;
Basic не получает SEO-инструменты и Яндекс-подключения, это бесплатный режим с рекламой и базовой работой по проекту;
Tester, Pro, Agency, Internal получают расширенный SEO-доступ;
UI закрывает эти разделы через requiredPlanFeature: seoTools;
API закрывает прямой доступ:
/api/seo-tools/* требует авторизацию, can_manage_project и тариф с seoTools;
/api/yandex/connections, /api/yandex/oauth/start, /api/yandex/sync требуют управление workspace/project и тариф с seoTools;
/api/yandex/popular-queries требует projectId, авторизацию, can_manage_project и тариф с seoTools.

2. Для кого платформа

Специалист

SEO-специалист, маркетолог, агентство, веб-студия или владелец сервиса.

Специалист может:

создавать клиентов и проекты;
подключать Яндекс.Метрику и Яндекс.Вебмастер;
загружать семантику;
проверять позиции, аудит сайта, индексацию;
создавать задачи;
готовить стратегию продвижения;
загружать шаблоны сайта на согласование;
отправлять отчеты и сводки заказчику.

Заказчик

Клиент, которому нужен понятный кабинет по проекту.

Заказчик может:

смотреть проект;
заполнять бриф проекта;
смотреть отчеты;
согласовывать стратегию, задачи, шаблоны сайта;
оставлять обратную связь;
видеть, что сделано и что запланировано.

Самостоятельная заявка заказчика

Заказчик может прийти без приглашения специалиста:

выбирает на регистрации Заказчик;
выбирает одну или несколько услуг: SEO, сайт, редизайн, перенос CMS, юзабилити, Директ, VK/таргет или аналитика;
указывает сайт, бюджет и короткое описание задачи;
после регистрации заявка сохраняется в таблицу client_requests;
владелец платформы видит новые заявки в Админ RepWay -> Платформа.

На первом этапе заказчик не выбирает специалиста сам. Заявка попадает владельцу платформы, а назначение специалиста/агентства делается вручную. Это сохраняет простоту MVP и не превращает продукт раньше времени в сложный маркетплейс.

Назначение заявки специалисту

[готово] Владелец RepWay вручную назначает заявку заказчика на кабинет специалиста или агентства:

открыть Админ RepWay -> Платформа;
в блоке Заявки заказчиков нажать Назначить или Переназначить;
выбрать кабинет специалиста/агентства;
добавить комментарий для специалиста;
сохранить назначение.

После назначения заявка получает статус Назначена и становится видимой специалисту в разделе Заявки. Специалист видит email клиента, услуги, сайт, бюджет, описание, комментарий владельца RepWay и дату назначения.

Действия специалиста на первом этапе:

Скопировать контакты;
Взять в работу.
Создать клиента и проект - превращает назначенную заявку в клиентскую организацию и рабочий проект.

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

Для перехода заявка -> клиент -> проект нужны поля конвертации:

supabase/add-client-requests.sql

После выполнения патча у заявки сохраняются converted_organization_id, converted_project_id и converted_at, поэтому повторное нажатие не создает дубли.

Несколько специалистов на одного заказчика

[готово] Для marketplace-ready модели добавлены проектные назначения.

Правило:

заказчик остается одной клиентской организацией;
работа делится на проекты и направления;
специалист назначается не на клиента целиком, а на конкретный проект/направление;
SEO/сайт может вести один специалист, СММ - другой, Директ - третий;
каждый специалист видит только назначенный проект и рабочие поля этого проекта;
заказчик в своем кабинете видит свои проекты и согласования;
владелец RepWay видит общую картину в Админ RepWay.

Пример:

клиент: ООО Рога и Копыта;
проект: SEO + разработка сайта -> специалист A;
проект: СММ -> специалист B.

Техническая модель:

organizations -> projects -> project_assignments -> workspaces

Где project_assignments хранит:

проект;
кабинет специалиста/агентства;
направление: SEO, сайт, Директ, VK, СММ, аналитика, комплекс;
роль: главный, специалист, наблюдатель;
статус: активно, пауза, закрыто.

Для подключения нужно выполнить SQL:

supabase/add-project-assignments.sql

Это не ломает будущий маркетплейс. Наоборот, позже публичная карточка специалиста и автоматический подбор будут создавать такие же project_assignments, только не вручную владельцем RepWay, а через выбор заказчика или алгоритм подбора.

Владелец кабинета

Специалист, агентство или команда, которые владеют своим рабочим кабинетом.

Владелец кабинета может:

работать на назначенном тарифе Basic, Tester, Pro или Agency;
видеть расширенные возможности в пределах назначенного тарифа;
управлять организациями, клиентами и проектами.

Владелец платформы

Главный администратор RepWay. Это не то же самое, что владелец кабинета специалиста.

Включается через серверную переменную:

REPWAY_PLATFORM_OWNER_EMAIL=owner@example.com

Можно указать несколько email через запятую.

Владелец платформы получает отдельный пункт Платформа в левом меню и видит общий read-only обзор:

количество кабинетов;
количество клиентов;
количество проектов;
количество пользователей и участников;
кабинеты специалистов/агентств;
последние клиенты;
последние проекты;
проблемные подключения Яндекса.
заявки заказчиков и их назначение на специалиста/агентство.

[готово] Владелец платформы может вручную менять тариф кабинета специалиста/агентства:

Basic - бесплатный доступ с рекламой и базовыми лимитами;
Tester - тестовый доступ для первых проверяющих платформы;
Pro - платный профессиональный тариф;
Agency - тариф для агентств;
Internal - внутренний служебный тариф, использовать только для кабинета владельца RepWay или служебных тестов.

Внутреннее сообщество тестеров

[готово] В левом меню добавлен раздел Сообщество.

Зачем нужен:

собирать баги от тестеров;
фиксировать идеи и предложения;
задавать вопросы по работе платформы;
обсуждать отдельные модули RepWay;
публиковать объявления владельца платформы.

Категории тем:

Ошибки и баги;
Идеи и предложения;
Вопросы по работе;
Обсуждение модулей;
Объявления RepWay.

Статусы темы:

Новая;
Принято;
В работе;
Сделано;
Отклонено.

Доступ:

владелец RepWay видит все темы и может менять статус;
специалист/агентство и тестер могут создавать темы и писать комментарии;
заказчику раздел не показывается.

Для подключения таблиц нужно выполнить SQL-патч:

supabase/add-community-forum.sql

Текущий этап специально не содержит удаления, блокировок и массового редактирования. Эти действия добавляются отдельно после проверки прав доступа.

3. Основные типы проектов

SEO-проект

Активны:

SEO-стратегия;
Яндекс;
Семантика;
Инструменты;
Отчеты;
Задачи;
Согласования.

Создание сайта

Активны:

Бриф проекта;
Шаблоны сайта;
Фото сайта;
Согласования;
Задачи;
Проектный центр;
Клиентская обратная связь.

SEO-разделы должны быть скрыты или второстепенны, чтобы не путать специалиста и заказчика.

Реклама

Активны:

Бриф;
Яндекс;
Отчеты;
Задачи;
Согласования.

В будущем сюда можно добавить VK Рекламу, рекламные кабинеты и медиапланы.

Комплексный проект

Активны почти все разделы. Подходит для клиента, где одновременно есть SEO, сайт, реклама и аналитика.

4. Текущая логика интерфейса

Левая колонка делится на группы:

Центр;
Проект;
SEO и данные;
Админка.

Второстепенные группы можно раскрывать, чтобы интерфейс не перегружал пользователя.

Главная цель интерфейса: пользователь сначала видит рабочий путь, а не все технические возможности сразу.

4.1. Короткая инструкция по использованию (по ролям)

Для специалиста:

Открой проект и проверь, что есть контактные данные и последний отчет.
Доведи до закрытия все Согласования перед переходом к следующему этапу.
Обновляй Яндекс-данные по регламенту (по мере необходимости), затем сверяй KPI.
Формируй отчет в формате: что сделано, что изменилось, что дальше.

Для клиента:

Смотри текущий проект и блок задач: там видно, что ждет моего решения.
При необходимости оставляй комментарий в обратной связи или по согласованию.
После обновления отчета проверяй короткие KPI-блоки и закрывай согласования.

4.2. Журнал релизов (фиксируем внедренный функционал)

Текущая логика журнала держится в lib/release-log.ts.
После каждого релиза добавляй запись в:
releaseLog — для раздела [implemented] и [next].
В приложении раздел Помощь берет этот же список для блока Что внедрено на практике.
Это убирает ручное дублирование между кодом и документацией.

Пример структуры:

{
  date: "2026-06-08",
  mode: "executor" | "client" | "all",
  type: "implemented" | "next",
  title: "Короткий текст изменения"
}

Как обновлять:

Добавляй новую строку в этот блок после каждого релиза.
В приложении соответствующий чеклист видно в Помощь → Что внедрено на практике.
Старые записи оставляй — это удобно при онбординге новых сотрудников и приёмке.

5. Рабочий путь специалиста

Шаг 1. Создать клиента

Специалист добавляет клиента и контактные данные:

компания;
контактное лицо;
телефон;
Telegram;
роль контакта;
договор;
тариф;
статус оплаты.

Шаг 2. Создать проект

При создании проекта важно выбрать тип:

SEO;
создание сайта;
реклама;
комплексный проект.

Бриф проекта

Бриф - это зона заказчика.

Правило:

заказчик видит форму заполнения брифа и отправляет вводные специалисту;
в брифе направления сгруппированы: сайт, SEO и аналитика, реклама и соцсети, контент;
в блоке сайта есть отдельные пункты: создание сайта, редизайн сайта, перенос сайта на другую CMS, улучшение юзабилити сайта;
в блоке рекламы и соцсетей есть Яндекс.Директ, VK Реклама и СММ;
специалист не заполняет бриф вместо клиента в основном рабочем пути;
на стороне специалиста раздел Брифинг проекта показывает только готовые брифы, статусы и карточки с ответами;
если вводных не хватает, специалист переводит бриф в статус Нужны уточнения и задает вопросы в диалоге.
Брифинг проекта и SEO-стратегия - разные рабочие поля: бриф собирает вводные заказчика, стратегия хранит план работ специалиста.

Это разделяет клиентские вводные и рабочее поле специалиста: заказчик не видит внутренние инструменты, а специалист получает готовую структурированную карточку.

От типа проекта зависит, какие разделы должны быть видны и какие инструменты включены.

Шаг 3. Собрать вводные

Через бриф можно собрать:

информацию о бизнесе;
цели проекта;
услуги;
аудиторию;
конкурентов;
пожелания;
файлы и документы.

Бриф должен быть универсальным: SEO, создание сайта, реклама, комплексный проект.

Дополнительно в брифе есть СММ:

ведение соцсетей;
контент-план;
рубрики;
регулярные публикации;
коммуникация с аудиторией;
связка с VK Рекламой и Яндекс.Директом.

Шаг 4. Подготовить стратегию

Специалист может:

загрузить документ стратегии;
расписать пункты стратегии на 1, 2, 3, 6 и 12 месяцев;
отметить статус выполнения;
объяснить, почему пункт важен;
описать ожидаемый результат;
перенести пункт на следующий период.

Шаг 5. Работать с задачами

Задачи должны быть полноценным рабочим модулем:

название;
описание;
приоритет;
статус;
срок;
специалист;
связь с проектом;
связь с семантикой, отчетом, аудитом или согласованием.

Шаг 6. Отправлять согласования

На согласование можно отправлять:

SEO-стратегию;
сводку по семантике;
шаблон сайта;
HTML-прототип;
отчет;
задачу или группу задач;
бриф.

Заказчик должен видеть компактную карточку и раскрывать детали по клику.

Шаг 7. Формировать отчет

Отчет должен показывать:

что сделано;
что изменилось;
какие данные пришли из Яндекса;
что требует внимания;
какие задачи запланированы;
что нужно согласовать.

6. Модули платформы

Роли и вход

[готово] Базовая логика входа разделяет специалиста и заказчика.

Правила:

специалист или агентство после входа открывает Кабинет специалиста;
если у специалиста еще нет проектов или кабинета, он остается в режиме специалиста и видит дорожную карту первого шага;
заказчик после приглашения или регистрации как заказчик открывает Кабинет заказчика;
заказчик не видит рабочее поле специалиста;
сохраненный режим Специалист/Заказчик имеет приоритет над старым типом аккаунта в браузере, чтобы не было мигания чужого кабинета при обновлении страницы.

Кабинет специалиста

[план] Привести кабинет специалиста к единой терминологии и структуре.

Кабинет специалиста - это вся рабочая зона специалиста или агентства. Его не нужно переименовывать в Клиентские проекты.

Рекомендуемая структура:

Обзор;
Заявки - только входящие обращения до начала работы;
Заказчики - карточки клиентов и организаций;
Клиентские проекты - рабочие направления по заказчикам: SEO, SMM, Директ, сайт, редизайн;
Задачи - конкретные действия внутри клиентского проекта;
Отчеты - результаты за период;
Инструменты;
Финансы / Биллинг;
Настройки.

Правильная цепочка:

Заявка -> Заказчик -> Клиентский проект -> Задачи -> Отчет

Термины:

Заявка - входящий запрос заказчика до начала работы;
Заказчик - клиент/организация;
Направление - SEO, SMM, Директ, разработка сайта и другие услуги;
Клиентский проект - конкретная рабочая единица по заказчику и направлению;
Задача - конкретное действие внутри клиентского проекта;
Отчет - результат за выбранный период.

Мобильная установка

[готово] RepWay подготовлен как PWA-приложение. Это не отдельная публикация в App Store или Google Play, но уже позволяет пользоваться платформой как приложением на телефоне.

Как установить на iPhone:

Открыть https://app.repway.ru в Safari.
Нажать кнопку Поделиться.
Выбрать На экран Домой.
Подтвердить название RepWay.

Как установить на Android:

Открыть https://app.repway.ru в Chrome.
Нажать меню браузера.
Выбрать Установить приложение или Добавить на главный экран.

Что уже работает:

отдельная иконка RepWay на экране телефона;
запуск без адресной строки браузера в режиме приложения;
старт с /app, чтобы пользователь попадал в кабинет;
сохранение обычной авторизации Supabase.

Что делать позже, если понадобится публикация в магазинах:

завернуть PWA в Capacitor;
добавить push-уведомления;
настроить сборки Android APK/AAB и iOS IPA;
пройти публикацию в Google Play и App Store.

Матрица доступа

[частично] Правила доступа постепенно выносятся из интерфейсной логики в понятную модель ролей.

Текущие роли:

Владелец RepWay - главный админ платформы, определяется через REPWAY_PLATFORM_OWNER_EMAIL;
Специалист/агентство - владелец рабочего кабинета workspace;
Тестер - кабинет специалиста с тарифом Tester;
Заказчик - участник организации клиента с ролью viewer;
Менеджер клиента - участник организации клиента с ролью admin.

Правила на сейчас:

| Раздел | Владелец RepWay | Тестер | Специалист/агентство | Заказчик | |---|---:|---:|---:|---:| | Кабинет специалиста | да | да | да | нет | | Кабинет заказчика | если есть доступ к клиенту | если есть доступ к клиенту | если есть доступ к клиенту | да | | Проекты, задачи, отчеты | да | да | да, только свои | только свои проекты | | SEO и инструменты | да | да | по тарифу | нет | | Заметки | да | да | да | нет | | Заявки | все заявки | назначенные заявки | назначенные заявки | нет | | Сообщество | да, модерация | да | нет | нет | | Админ RepWay | да | нет | нет | нет |

Сообщество специально закрыто: его видят только владелец RepWay и кабинеты с тарифом Tester. Обычный специалист не видит пункт меню, не загружает API сообщества и не может создать тему/комментарий через прямой запрос.

[готово] Заявки, клиенты и проекты закрыты дополнительными UI-правилами:

Заявки: владелец RepWay видит всю воронку, специалист видит только заявки, назначенные на его workspace, заказчик раздел не видит.
Клиенты: специалист видит только организации, где он owner/admin; заказчик общий список клиентов не видит.
Проекты: специалист видит только проекты управляемых клиентских организаций; заказчик видит только проекты организаций, где он участник.
прямой вызов скрытого раздела через интерфейс показывает уведомление о недоступности, а не пустой/чужой экран.
режим специалиста без своих проектов показывает дорожную карту, даже если этот же аккаунт где-то является заказчиком.

Проектный центр

Центр управления проектом.

Должен показывать:

тип проекта;
заказчика;
контакт;
специалиста;
последний отчет;
ожидающие согласования;
открытые задачи;
ближайшие действия.

Заметки

[готово] Отдельное рабочее поле специалиста для быстрых записей и рабочего блокнота.

Заметки:

не привязаны к конкретному проекту;
хранятся на уровне кабинета специалиста/агентства;
имеют заголовок и раскрываются кликом по заголовку;
подходят для мыслей, созвонов, рисков и идей;
группируются по типам и подсвечиваются разными цветами;
поддерживают поиск, флаг важности и закрепление;
поддерживают редактирование, удаление и архив;
архив скрыт по умолчанию и раскрывается по клику;
из заметки можно создать задачу в выбранном проекте;
есть сортировка: сначала обновленные, сначала новые, сначала старые, по заголовку или по типу;
видны в отдельном пункте меню Рабочее поле -> Заметки;
доступны только владельцу/админу кабинета специалиста через can_manage_workspace;
заказчик не видит пункт меню, не загружает список заметок и не проходит RLS на таблице workspace_notes;
позже могут переноситься в задачу, стратегию, бриф или отчет.

Для сохранения в Supabase нужно выполнить SQL-патч:

supabase/harden-workspace-notes.sql

Бриф проекта

Модуль для сбора вводных.

Поддерживает:

SEO;
создание сайта;
рекламу;
СММ;
комплексные проекты;
загрузку файлов;
предпросмотр;
отправку заказчику;
отдельный рабочий режим для специалиста: готовый бриф раскрывается как документ, а история брифов раскрывается кликом по заголовку.

SEO-стратегия

Модуль планирования работ.

Поддерживает:

месяцы и горизонты;
пункты стратегии;
статусы;
причины переносов;
документ стратегии;
объяснение пользы.

Семантика

Модуль для ключевых слов.

Поддерживает:

ручной ввод;
импорт CSV;
загрузку несколькими строками;
группы;
посадочные страницы;
связь с задачами;
данные из Яндекс.Вебмастера.

Правила отображения:

0 по позиции или частотности не считается реальной метрикой, если источник не дал данных;
неизвестная позиция/частотность показывается как — или нет данных;
Яндекс.Вебмастер дает показы, клики, CTR и среднюю позицию по сайту, но не дает Wordstat-частотность;
если есть показы, но нет кликов, запрос получает статус Есть показы;
статус Есть показы означает: проверить сниппет, интент запроса, релевантность страницы и среднюю позицию;
частотность нужно загружать отдельно через Wordstat, CSV или ручной ввод, не подменяя ее показами из Вебмастера.

Яндекс

Интеграционный раздел.

Поддерживает:

Яндекс.Метрику;
Яндекс.Вебмастер;
OAuth;
подключение Метрики и Вебмастера по домену проекта без ручного поиска ID;
ручное обновление токена;
синхронизацию данных;
выбор периода.

Как подключать по домену:

В проекте должен быть заполнен сайт, например site.ru или https://site.ru.
Открой раздел Яндекс.
В блоке Домен проекта нажми Подключить Метрику или Подключить Вебмастер.
Пройди OAuth Яндекса.
Платформа передаст домен в callback:

для Метрики попробует найти счетчик по домену счетчика;
для Вебмастера попробует найти сайт среди доступных host в аккаунте.

После успешного подключения нажми Синхронизировать.

Ограничения:

если в аккаунте Яндекса нет счетчика или сайта с этим доменом, подключение не определится автоматически;
для Вебмастера сайт должен быть добавлен в Яндекс.Вебмастер, а права должны быть подтверждены;
если в OAuth-приложении нет нужных доступов, нужно добавить права и получить новый токен.

Инструменты

Инструменты специалиста.

Текущие и планируемые:

проверка позиций;
ручные SERP-замеры;
проверка индексации;
аудит сайта;
кластеризация семантики;
Wordstat или аналог;
пакетная проверка URL.

Популярные запросы (онлайн)

Отдельный блок в SEO и данные, который не зависит от проекта и не требует подключения вебмастера/метрики.

Что показывает:

отдельный рейтинг трендов за неделю или месяц;
общий обзор популярных запросов, если поле Базовый запрос оставить пустым;
тематический список запросов, если ввести базовую фразу;
рабочий буфер Идеи для семантики;
автоматический план действий по группам идей;
историю последних запусков рейтинга;
выбор периода (сейчас, 24 часа, 7 дней, 30 дней);
лимит строк;
признак источника: онлайн или демо.

Как использовать:

Открой SEO и данные -> Популярные запросы.
В верхнем блоке Рейтинг трендов выбери За неделю или За месяц.
Нажми Обновить рейтинг.
Смотри первые позиции: это не данные конкретного сайта, а общий спрос по Яндексу в выбранном регионе.
Нажми Как тема у подходящего тренда, чтобы быстро открыть тематический подбор по этой фразе.
Нажми + идея, чтобы отложить запрос в буфер Идеи для семантики.
В нижнем блоке можно оставить Базовый запрос пустым для общего обзора или ввести тему, например стоматология, ремонт квартир, создание сайта.
Если запросы подходят под проект, добавь их в семантику кнопкой + в семантику, пакетной кнопкой В семантику или сначала отправь в Идеи.
Если при пустом базовом запросе видна диагностика, что часть тем не дала ответ, это не ошибка: общий обзор уже собран, а дополнительные темы просто не успели ответить за лимит времени.
Если живой обзор временно не вернул строки, демо-данные не подмешиваются: нужно повторить обновление после восстановления сети или ввести конкретную базовую тему.

Рабочий буфер Идеи для семантики:

хранится локально для текущего проекта;
помогает не отправлять в ядро все подряд;
показывает, какие идеи уже есть в семантике;
автоматически группирует идеи по смысловым типам;
показывает рекомендованные действия: посадочная, локальное SEO, FAQ/контент, разбор брендов;
выводит видимый блок Готовый план действий прямо на странице;
позволяет одним кликом отправить отобранные запросы в семантику;
позволяет скопировать подборку для заметки, задачи или согласования;
позволяет скопировать текст готового плана действий;
очищается вручную кнопкой Очистить.

Логика блока Готовый план действий:

план появляется только после того, как в Идеи для семантики добавлена хотя бы одна фраза;
план строится не по конкретному сайту, а по типу спроса в выбранных идеях;
коммерческие фразы превращаются в рекомендацию по посадочным страницам и офферам;
локальные фразы превращаются в рекомендацию по локальному SEO, городам, адресам, карте и микроразметке;
вопросные фразы превращаются в рекомендацию по статьям, FAQ и контентным блокам;
сервисные фразы превращаются в рекомендацию по разделению услуг на отдельные страницы;
брендовые фразы требуют ручной проверки: свой бренд, чужой бренд, маркетплейс или нерелевантный спрос;
прочие фразы не отправляются автоматически в работу, их нужно разобрать вручную.

Как использовать Готовый план действий:

Добавить 5-20 фраз в Идеи для семантики.
Прочитать видимый блок Готовый план действий.
Удалить лишние идеи, если план получился шумным.
Скопировать текст плана кнопкой Скопировать текст.
Вставить текст в задачу, заметку или согласование.
После ручной проверки отправить подходящие фразы в семантику.

Ограничения:

план действий не является прогнозом позиций;
план не гарантирует трафик;
перед обещанием заказчику нужно проверить выдачу, релевантность посадочной, регион, конкурентов и бизнес-цель;
если в идеях много общих фраз, план будет общим, поэтому сначала нужно чистить подборку.

Как читать данные:

Поисковая частота - ориентир по спросу, а не гарантия трафика;
Регион - текущая зона сбора данных (Россия, Москва, 213 и т.д.);
Источник показывает, пришли ли данные из Яндекс API или из резервного режима;
пустой базовый запрос собирает обзор по нескольким популярным темам, поэтому он полезен для поиска трендов;
тематический запрос лучше использовать для подбора идей под конкретный проект.

Настройка API:

если YANDEX_POPULAR_QUERIES_ENDPOINT пустой, а YANDEX_POPULAR_QUERIES_API_KEY/YANDEX_SEARCH_API_KEY не заданы, блок работает в демо режиме;
если задан endpoint, модуль использует его напрямую (GET с параметрами period, region, limit);
если YANDEX_POPULAR_QUERIES_API_KEY (или YANDEX_SEARCH_API_KEY) задан и YANDEX_SEARCH_API_FOLDER_ID есть, используется Yandex SearchAPI Wordstat endpoint автоматически;
после изменения .env.local нужно перезапустить dev-сервер;
при сетевом сбое или таймауте показывается понятное сообщение и демо-резерв.

Практический сценарий специалиста:

раз в неделю открыть рейтинг трендов и посмотреть новые массовые темы;
отдельно ввести тематику клиента и собрать релевантные запросы;
складывать подходящие запросы в Идеи для семантики;
смотреть группы идей и переносить в семантику только подходящие группы;
копировать подборку, если нужно обсудить ее с заказчиком;
смотреть блок Готовый план действий, затем копировать его в задачу или согласование;
после отбора сохранить идеи в семантику;
по спорным или новым группам отправить заказчику согласование/комментарий;
не обещать позиции по трендам напрямую: использовать блок как источник идей, а не как прогноз поисковой выдачи.

Согласования

Модуль взаимодействия с заказчиком.

Нужно придерживаться принципа: короткая карточка, подробности раскрываются по клику.

Отчеты

Модуль отчетности.

Должен быть понятным для заказчика:

меньше технической каши;
больше выводов;
компактные KPI;
раскрываемые детали;
понятные рекомендации.

Доступ:

специалист/агентство видит черновики, опубликованные отчеты и управление публичными ссылками;
заказчик видит только опубликованные отчеты своих проектов;
заказчик видит только активные публичные ссылки по своим проектам;
публичная ссылка открывается без входа только по активному токену /share/[token];
публичная ссылка не должна отдавать рабочие таблицы целиком: только клиентские поля отчета, KPI, SEO/Ads/Метрики/Директа и семантики;
реальные публичные ссылки не подставляют демо-данные, если в проекте нет статистики.

Для жесткого режима в Supabase нужно выполнить SQL-патч:

supabase/harden-public-reports.sql

Задачи

Рабочий модуль управления работами.

Должен связать:

стратегию;
семантику;
аудит;
отчеты;
согласования;
пожелания заказчика.

В рабочем центре задачи есть:

статус;
рабочий период: эта неделя, этот месяц, следующий месяц, backlog;
признак ожидает клиента;
причина ожидания клиента;
связь с объектом проекта: семантика, стратегия, согласование, отчет, страница сайта, Яндекс или бриф;
специалист, срок, приоритет и комментарии.

Зачем это нужно:

специалист видит, что делать сейчас, что перенесено и что блокируется заказчиком;
заказчику можно понятно показать, где нужен его ответ, доступ, материал или согласование;
задача получает контекст: откуда она появилась и к какому объекту проекта относится;
активная доска остается рабочей, а закрытое уходит в архив.

План развития задач по мотивам Jira/Linear/ClickUp, но без лишней сложности:

Рабочий период + ожидание клиента + связь с объектом проекта.
Направления/эпики: SEO, семантика, контент, сайт, реклама, согласования.
Чек-листы внутри задачи.
Шаблоны задач для SEO, сайта, рекламы и аналитики.
История изменений задачи.
Roadmap 1-3-6-12 месяцев с привязкой задач.
Клиентский слой: что сделано, что в работе, что ждет клиента, что дальше.

Планы действий

Единая логика для всех автоматических или полуавтоматических планов внутри платформы.

Правильный формат плана:

Что сделать - конкретное действие специалиста;
Почему это важно - причина, связанная с данными или бизнес-целью;
На основе чего - источник: тренды, семантика, Вебмастер, аудит, бриф, стратегия;
Что проверить вручную - выдача, посадочная, релевантность, регион, доступы, ограничения;
Куда перенести - задача, заметка, согласование, стратегия или отчет.

Правила:

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

Удаление:

ключевые слова удаляются в разделе Семантика в таблице Ключевые слова;
рядом с удалением ключа есть чекбокс, выбранные ключи можно удалить одной кнопкой Удалить выбранные;
задачи не удаляются физически, а переносятся в архив;
рядом с задачей есть чекбокс, выбранные задачи можно одной кнопкой перенести в архив;
архив задач находится в разделе Обратная связь / Задачи отдельным раскрывающимся блоком Архив задач;
удаление доступно специалисту/владельцу, не заказчику;
в Supabase для удаления ключевых слов в живой базе нужен SQL-патч supabase/add-delete-keywords-tasks.sql;
архивирование задачи работает через обновление client_feedback, поэтому ответы и история не теряются.

7. Данные Яндекса

Яндекс.Метрика

Может дать:

посещения;
органические переходы;
источники;
поисковый трафик;
поведение пользователей;
конверсии, если настроены цели.

Яндекс.Вебмастер

Может дать:

поисковые запросы;
показы;
клики;
CTR;
среднюю позицию;
топовые запросы;
запросы без позиции;
данные за доступный период.

Важно: данные Вебмастера могут быть ограничены доступным диапазоном дат. Если Яндекс говорит, что период доступен только с конкретной даты по конкретную дату, интерфейс должен объяснять это человеку.

8. Текущие ограничения

Живая проверка позиций

Автоматический парсер Яндекса пока не внедрен как основной способ.

Причины:

капча;
прокси;
региональность;
персонализация выдачи;
риск блокировок;
нестабильность.

Для MVP выбран более надежный путь:

подтягивать данные из Яндекс.Вебмастера;
добавлять ручные SERP-замеры;
сохранять историю;
показывать динамику.

API сторонних сервисов

Можно подключать бесплатные или условно бесплатные сервисы, но у каждого будут лимиты, ключи и ограничения.

9. Тарифная логика

Internal

Внутренний тариф владельца.

Особенности:

не требует оплаты;
виден только владельцу;
включает SEO-инструменты;
нужен для разработки и внутреннего использования.

Базовый тариф

Для простого кабинета клиента:

проекты;
бриф;
задачи;
отчеты;
согласования.

Free с рекламой

Бесплатный тариф можно оставить как реальный вход в платформу, но монетизировать рекламой.

Логика:

платформа доступна бесплатно;
в интерфейсе показываются аккуратные рекламные блоки;
часть функций ограничена лимитами;
пользователь может убрать рекламу переходом на платный тариф.

Рекомендуемые ограничения Free:

ограниченное количество клиентов/проектов;
ограниченное количество отчетов;
часть SEO-инструментов закрыта или лимитирована;
нет white-label;
в публичных отчетах можно показывать маленький брендированный блок RepWay, но без агрессивной рекламы.

Где показывать рекламу:

правый или нижний блок в обзоре;
пустые состояния: нет проекта, нет отчета, нет заявок;
нижний блок в инструментах;
редкое всплывающее окно с предложением тарифа.

Правило всплывающей рекламы:

не показывать при каждом клике;
не показывать поверх важных действий: сохранение, отправка отчета, согласование;
не чаще одного раза за сессию или раз в несколько часов;
всегда иметь понятную кнопку закрытия;
текст должен быть мягким: Убрать рекламу и открыть больше возможностей.

Первый MVP рекламной модели:

1 встроенный рекламный блок в кабинете;
1 блок в пустых состояниях;
1 аккуратное всплывающее предложение для Free;
скрытие рекламы для Pro, Agency, Internal.

Tester

Отдельная роль/тариф для первых тестеров платформы.

Зачем нужен:

давать людям доступ на тест без оплаты;
не путать тестеров с обычными бесплатными пользователями;
собирать обратную связь по продукту;
спокойно проверять расширенные разделы до платного запуска.

Особенности:

рекламные блоки скрыты;
лимиты выше, чем на Free;
SEO-инструменты доступны;
PDF-экспорт доступен;
white-label выключен, чтобы не смешивать тестовый доступ с агентским тарифом.

Как использовать:

назначить организации/кабинету план Tester;
попросить тестера пройти сценарии: регистрация, клиент, проект, бриф, задачи, отчет, Яндекс, заявки;
собрать обратную связь: что непонятно, где лишнее, где не хватает действия.

Планируемый раздел Бета-тест внутри кабинета:

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

Pro

Для SEO-специалистов:

семантика;
Яндекс;
SEO-инструменты;
расширенные отчеты;
история позиций.

Agency

Для агентств:

много клиентов;
много проектов;
роли;
сотрудники;
расширенные лимиты;
брендированные отчеты.

Предложение для тестеров

Для первых тестеров с фриланса лучше сделать отдельное простое предложение:

Тестируем RepWay - платформу для SEO-специалистов, маркетологов и веб-студий.

Что нужно:
- зарегистрироваться;
- создать тестового клиента и проект;
- попробовать бриф, задачи, отчеты, Яндекс и заявки;
- записать, где непонятно, что мешает и чего не хватает.

Что получит тестер:
- бесплатный доступ на время тестирования;
- возможность повлиять на продукт;
- ранний доступ к платформе;
- бонус/скидка после запуска платных тарифов.

Важно:
это тестовая версия, поэтому могут быть недоработки. Нам нужна честная обратная связь по удобству и логике работы.

Будущий модуль Бета-тест

Минимальный MVP:

отдельный раздел Бета-тест только для тарифа/роли Tester и владельца RepWay;
список заданий: регистрация, добавление заказчика, создание проекта, бриф, задачи, отчет, публичная ссылка, мобильная версия;
форма Сообщить о проблеме;
форма Предложить идею;
список отправленных тестером отзывов;
ручное начисление бонусов ресурсами платформы.

Задача модуля - собирать обратную связь структурно, а не терять ее в чатах и скриншотах.

10. Supabase

Для полноценной работы нужны переменные:

NEXT_PUBLIC_SUPABASE_URL=
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=
SUPABASE_SERVICE_ROLE_KEY=
YANDEX_CLIENT_ID=
YANDEX_CLIENT_SECRET=
YANDEX_REDIRECT_URI=
YANDEX_DIRECT_CLIENT_ID=
YANDEX_DIRECT_CLIENT_SECRET=
YANDEX_DIRECT_REDIRECT_URI=

YANDEX_DIRECT_* нужны только для отдельного OAuth-приложения Яндекс.Директа. Если Direct-приложение использует тот же callback, что Метрика/Вебмастер, YANDEX_DIRECT_REDIRECT_URI можно оставить пустым.

Рабочий стол Директа

Директ вынесен из общего раздела Яндекс в отдельный пункт левого меню Реклама -> Директ.

Что там есть:

отдельное подключение по логину клиента Директа;
несколько кабинетов/логинов Директа в одном проекте;
раскрытие и скрытие блока кабинетов по заголовку;
раскрытие каждого кабинета отдельно: статус, токен, последняя синхронизация, обновление доступа;
кнопка OAuth Подключить Директ;
выбор периода синхронизации;
синхронизация выбранного периода отдельно по нужному кабинету;
KPI по расходу, кликам, конверсиям, CPA, CTR;
раскрывающийся блок кампаний, чтобы таблица не перегружала экран;
переход в CSV-импорт Директа как запасной вариант.

Общий раздел Яндекс теперь остается для Метрики, Вебмастера и поисковых данных, а рекламные кампании ведутся отдельно.

Фото сайта

Раздел Проект -> Фото сайта нужен для согласования визуальных материалов сайта: скриншотов, фото блоков, баннеров, изображений для страниц.

Как работает:

специалист добавляет изображения файлом или ссылками;
указывает страницу/блок и комментарий, что именно нужно проверить;
RepWay создает согласование типа Фото сайта;
заказчик раскрывает карточку, смотрит галерею и выбирает решение;
если замечаний нет, заказчик нажимает Одобрить;
если замечания есть, заказчик ставит чекбокс Есть замечания и пишет сообщение;
замечания сохраняются в диалоге карточки, а статус меняется на Есть замечания.

Для MVP изображения, загруженные файлом, сохраняются прямо внутри согласования. Крупные изображения лучше добавлять ссылкой. Следующий производственный шаг - вынести файлы в Supabase Storage или S3-совместимое хранилище.

Документы проекта

Раздел Центр -> Документы нужен для рабочих документов конкретного проекта: договоров, счетов, актов, технических заданий, таблиц и коммерческих предложений.

Как работает:

специалист открывает нужный проект и загружает PDF, Word или Excel;
указывает тип документа, название и короткий комментарий;
файл сохраняется на сервере/VPS в папке загрузок, а в Supabase остается служебная запись проекта;
заказчик видит документы только своего проекта;
справа открывается предпросмотр PDF, а Word/Excel можно открыть или скачать отдельной кнопкой;
специалист может отправить клиенту заметку по изменению пункта документа, и она попадает в ленту проекта как обращение.

Этот раздел не заменяет Шаблон сайта и Фото сайта: шаблоны и изображения остаются согласованиями, а Документы - это архив рабочих PDF по проекту.

SQL-патчи нужно выполнять аккуратно через Supabase SQL Editor.

Правило:

если файл называется fix или patch, обычно его можно выполнить поверх существующей схемы;
если файл создает таблицы с drop, нужно внимательно читать предупреждение Supabase;
destructive operations нельзя запускать без понимания, что удаляется.

11. Где мы можем споткнуться

Сложность интерфейса

Главный риск - сделать слишком много функций на одном экране.

Решение:

показывать только нужное по типу проекта;
раскрывать детали по клику;
группировать действия;
не заставлять пользователя бегать по страницам.

Яндекс API

Риск - ограничения токенов, прав и периодов.

Решение:

показывать понятные уведомления;
хранить дату периода;
объяснять, что именно пришло из API;
давать кнопку обновления токена и удаления подключения.

Роли и доступ

Риск - специалист и заказчик увидят не то, что должны.

Решение:

довести модель ролей;
скрывать UI-действия;
проверять доступ не только на UI, но и на уровне Supabase RLS.

Отчеты

Риск - отчет превращается в техническую кашу.

Решение:

сначала вывод;
потом KPI;
потом детали по клику;
отдельно блок "что делать дальше".

12. Доступ заказчика

Приглашение заказчика

[готово] Специалист приглашает клиента через Настройки -> Пригласить заказчика.

Сценарий:

специалист выбирает организацию;
вводит email клиента;
оставляет роль Заказчик;
RepWay создает приглашение и копирует ссылку на регистрацию;
клиент открывает ссылку, регистрируется или входит с этим же email;
после входа приглашение принимается автоматически;
клиент попадает в режим заказчика без переключателя на специалиста.

Важно:

общий логин и пароль клиенту выдавать не нужно;
email в приглашении должен совпадать с email аккаунта клиента;
роль Заказчик не видит рабочее поле специалиста;
роль Менеджер предназначена для сотрудников специалиста и видит управленческие разделы.

Что еще можно добавить позже

[план] Подключить настоящую email-отправку приглашений через почтовый сервис.

[план] Добавить страницу управления приглашением: отозвать, отправить повторно, показать дату последнего открытия.

13. Первый вход и пустой кабинет

[готово] После регистрации пользователь попадает в кабинет /app, а не на обязательную страницу добавления клиента.

Как теперь устроен первый вход:

регистрация или вход открывает основной кабинет;
если проектов еще нет, внутри кабинета показывается стартовая подсказка;
основное действие - Создать первый проект;
в форме проекта можно сразу добавить нового клиента;
отдельная кнопка Добавить только клиента остается для случаев, когда проекта пока нет.

Если при создании клиента появляется ошибка column reference "workspace_id" is ambiguous, нужно выполнить SQL-патч:

supabase/fix-workspace-id-ambiguous.sql

Этот патч обновляет функции ensure_default_workspace и create_client_organization.

14. Ближайший план

Этап 1. Упростить путь пользователя

Довести левое меню.
Скрывать лишние разделы по типу проекта.
Сделать проектный центр главным экраном действий.
Привести Кабинет специалиста к структуре: Обзор, Заявки, Заказчики, Клиентские проекты, Задачи, Отчеты, Инструменты, Финансы, Настройки.
Заменить названия работы, заказы, работы клиентов на Клиентские проекты, если речь идет о рабочем объекте специалиста по заказчику.

Этап 2. Довести проектный центр

Показать клиента и контакт.
Показать открытые задачи.
Показать согласования.
Показать последние отчеты.
Показать быстрые действия.

Этап 3. Довести согласования

Компактные карточки.
Раскрытие по клику.
Предпросмотр HTML-шаблонов.
Публичная выгрузка.

Этап 4. Довести Яндекс.Вебмастер

Выбор периода.
Понятные подписи: неделя, месяц, доступный период.
Больше запросов.
Сохранение пользовательского запроса.
Создание задач из запросов.

Этап 5. Довести отчеты

Отдельная SEO-сводка.
Блок "что важно".
Блок "что сделано".
Блок "что дальше".
Минимум лишней технической информации.

Этап 6. Разделить две логики клиентов и заявок

Ветка "специалист уже ведет заказчика": специалист сам создает клиента, выдает доступ, создает проект и формирует отчет.
Ветка "заказчик ищет специалиста": заказчик оставляет заявку, RepWay назначает специалиста/агентство, специалист принимает лид и только потом создает проект.
Не смешивать заявку и проект: заявка описывает потребность, проект начинается после принятия работы.
В интерфейсе создания проекта сначала выбирать клиента; если клиента нет, вести в Добавить клиента или Пригласить заказчика.
Для будущего marketplace оставить основу: публичная карточка специалиста, ручное/автоматическое назначение заявки, принятие лида специалистом.

Этап 7. Сделать раздел Бета-тест

Добавить отдельный раздел Бета-тест для тестеров и владельца.
Вывести чеклист заданий для тестера.
Добавить отправку бага/идеи/UX-замечания из кабинета.
Показать тестеру его отправленные отзывы.
В админке владельца собрать все отзывы тестеров.
Подготовить ручное начисление бонусов ресурсами платформы.

Этап 7. Подготовить монетизацию

тарифы;
лимиты;
доступы;
внутренний тариф;
платные модули;
Free-тариф с рекламой;
отключение рекламы на платных тарифах;
мягкое всплывающее предложение апгрейда;
тестовое предложение для первых пользователей.

15. Почта и SMTP

[частично] В RepWay добавлен базовый модуль системных писем через внешний SMTP.

Что уже подключено:

письмо заказчику/менеджеру при приглашении в организацию;
повторная отправка письма по уже созданному приглашению;
резервное копирование ссылки приглашения, если SMTP еще не настроен;
письмо владельцу платформы при новой заявке заказчика;
письмо специалисту/агентству при назначении заявки;
health-проверка показывает, заполнен ли SMTP;
тестовая API-ручка для владельца платформы: POST /api/platform/admin/email/test.

Какие переменные нужны в .env.production:

SMTP_HOST=
SMTP_PORT=587
SMTP_SECURE=false
SMTP_USER=
SMTP_PASSWORD=
SMTP_FROM=RepWay <no-reply@repway.ru>

Рекомендация:

для RepWay лучше использовать внешний SMTP: Timeweb, Яндекс 360, Brevo, Mailgun или аналог;
полноценный почтовый сервер на VPS пока не нужен, потому что он требует SPF, DKIM, DMARC, PTR/rDNS и постоянного контроля доставляемости;
если SMTP не заполнен, платформа продолжит работать, но письма будут пропускаться.

16. Как менять эту документацию

Этот файл можно редактировать как обычный текст.

Что удобно менять:

добавлять новые модули;
отмечать готовность функций;
переносить пункты в план;
писать заметки по продукту;
использовать как основу для инструкции пользователям.

Рекомендуемый формат статусов:

[готово] функция работает
[частично] функция есть, но требует доработки
[план] функция еще не внедрена
[пауза] отложено

17. СММ-модуль

[частично] В RepWay добавлено рабочее место СММ.

Что уже есть:

контент-план по проекту;
сохранение СММ-постов в Supabase через таблицу smm_posts;
площадки: VK, Telegram, Дзен, YouTube Shorts, сайт/блог;
статусы: идея, черновик, на согласовании, запланирован, опубликован, просрочен;
автоматическая пометка просрочки, если дата публикации уже прошла;
фильтр по статусу и площадке;
ручной ввод ссылки публикации и метрик: охват, реакции, комментарии;
отправка отдельного поста на согласование заказчику;
отправка СММ-сводки заказчику;
создание задачи из СММ-поста;
удаление СММ-поста специалистом;
заказчик видит план и факт без внутренней рабочей кухни.

Что нужно выполнить в Supabase:

запустить файл supabase/add-smm-posts.sql;
после выполнения обновить страницу приложения;
если SQL еще не выполнен, модуль работает временно, но посты не будут сохраняться после обновления страницы.

Зачем это нужно:

специалист может доказать, что СММ-работа ведется по плану;
заказчик видит не хаотичные сообщения в чате, а понятные публикации, статусы и ссылки;
позже сюда можно подключать API VK/Telegram/YouTube и автоматически собирать факт публикаций.

Что следующим этапом:

добавить календарный вид;
добавить медиаматериалы к постам;
подключить API соцсетей для проверки факта публикации и метрик.

18. Редактирование лендинга

[готово] Владелец RepWay может менять главный лендинг через веб-интерфейс.

Где находится:

войти под владельцем платформы;
открыть Админ RepWay;
раскрыть блок Лендинг RepWay;
изменить JSON;
нажать Применить предпросмотр;
нажать Сохранить лендинг.

Что можно менять:

заголовок и подзаголовок первого экрана;
пункты преимуществ;
блоки для специалиста и заказчика;
описание инструментов;
FAQ;
CTA;
тексты карточек;
ссылки на изображения из /public/landing.

Что нужно выполнить в Supabase:

запустить файл supabase/add-landing-pages.sql;
после этого лендинг будет храниться в таблице landing_pages;
если таблицы нет, платформа покажет дефолтный лендинг из кода.

Важное ограничение:

доступ к сохранению есть только у email из REPWAY_PLATFORM_OWNER_EMAIL;
публичный посетитель может только читать лендинг;
если JSON испорчен, платформа нормализует данные и подставит безопасные дефолтные значения.

19. Журнал решений

Sitemap: lastmod, changefreq, priority

Этот раздел относится к инструменту Инструменты → SEO-проверки → Sitemap.

lastmod

lastmod показывает поисковику дату последнего существенного изменения страницы.

Как использовать:

ставить дату в формате YYYY-MM-DD;
обновлять дату только если страница реально изменилась;
не менять дату каждый день автоматически, если контент не менялся.

Пример:

<lastmod>2026-06-20</lastmod>

changefreq

changefreq подсказывает примерную частоту обновления страницы.

Допустимые значения:

always;
hourly;
daily;
weekly;
monthly;
yearly;
never.

Практическая логика:

главная и активные разделы: weekly;
новости или блог при частых публикациях: daily или weekly;
статичные услуги и контакты: monthly;
архивные страницы: yearly или never.

priority

priority показывает относительную важность страницы внутри одного сайта.

Диапазон:

от 0.0 до 1.0.

Практическая логика:

главная: 1.0;
важные услуги и категории: 0.8;
статьи и посадочные среднего приоритета: 0.6;
технические или второстепенные страницы: 0.3.

Важно:

priority не гарантирует рост позиций;
значение работает только как подсказка внутри текущего сайта;
не нужно всем страницам ставить 1.0.

Построчный формат в RepWay

В генераторе можно указать значения для каждой строки:

URL | lastmod | changefreq | priority

Пример:

https://site.ru/ | 2026-06-20 | weekly | 1.0
https://site.ru/catalog/ | 2026-06-18 | weekly | 0.8
https://site.ru/blog/post | 2026-06-10 | monthly | 0.6

2026-06-08

Решили упростить логику интерфейса.
Семантика должна быть проще: данные, группы, задачи, отчет.
Левое меню должно быть компактнее.
Второстепенные блоки должны раскрываться по клику.
По типу проекта нужно скрывать лишний функционал.