Требования к текущему этапу проекта

Паспорт документа

• Статус документа: target requirements
• Актуально на: 28 марта 2026 года
• Владелец: backend/platform-команда
• Пересмотр: при изменении бизнес-приоритетов, quality gates или инженерных требований
• Область применения: текущие продуктовые и инженерные требования этапа controlled MVP
• Связанные документы:
  • Roadmap
  • Текущее состояние
  • Инженерные принципы

1. Бизнес-цель текущего этапа

Текущий этап проекта — не "строительство с нуля", а доведение существующей платформы до контролируемого MVP, который можно безопасно развивать дальше. Приоритет не в расширении списка фич любой ценой, а в том, чтобы:

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

2. Основные роли системы

• Гость: просмотр каталога, карточек, публичных страниц.
• Buyer: профиль, лиды, отзывы, персональные действия.
• Seller: профиль организации, айтемы, лиды, сотрудники.
• Admin: модерация, reference data, аналитика, операционные действия.

3. Функциональные требования P0

Публичная часть

• Каталог должен показывать только допустимые к публикации айтемы.
• Карточка айтема должна корректно отображать ключевые параметры, описание, отзывы и CTA на заявку.
• Публичный seller profile должен открываться без авторизации и быть пригодным для SEO.

Авторизация и аккаунты

• Регистрация и логин должны работать через httpOnly cookies.
• Refresh-flow должен быть безопасным и поддерживать ротацию refresh token.
• GET /auth/me должен надёжно возвращать текущего пользователя для SSR и client hydration.

Buyer-сценарии

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

Seller-сценарии

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

Admin-сценарии

• Admin должен видеть очередь модерации айтемов.
• Admin должен уметь одобрять и отклонять айтемы с комментарием.
• Admin должен иметь работающий обзор по лидам и базовой статистике.

Документация и эксплуатация

• Каноническая документация проекта должна быть на русском языке.
• Должен существовать единый эксплуатационный runbook для production-сервера.
• Портал документации должен читать markdown напрямую из docs/.
• Должен существовать отдельный канонический документ с инженерными принципами ведения разработки и передачи проекта другой команде.
• Для frontend-команды должен существовать отдельный handoff-документ с git-репозиториями, OpenAPI, env и правилами контрактной работы.

4. Инженерные требования P0

• build, check-types и релевантные test не должны расходиться с реальным кодом.
• Проект должен строиться так, чтобы его можно было передать другой команде без критичной зависимости от текущих разработчиков.
• Все ключевые слои системы должны иметь явные границы и формализованные контракты.
• Нельзя усиливать связанность frontend с внутренними backend/workspace-исходниками, если стратегическая цель — отдельный frontend-репозиторий.
• Production-сборка должна использовать только актуальное дерево frontend-кода.
• Все production-домены должны быть закрыты HTTPS.
• Нужно избегать хардкода старых доменов и старых entrypoint'ов.
• Для критичных сценариев обязательны unit, integration и минимальные e2e/smoke проверки по уровню риска.
• Каждый production-баг должен закрываться регрессионной проверкой.
• Изменения инфраструктуры должны отражаться в docs/project/current-state.md и docs/operations/deployment-runbook.md.
• Изменения архитектуры, контрактов и процесса разработки должны синхронно отражаться в канонической документации.

5. Требования P1 после стабилизации

• E2E smoke-тест на публичный каталог и карточку айтема.
• Smoke/API integration-тест на auth refresh и базовый health/catalog.
• Buyer onboarding с полноценным UX, а не только с техническими заготовками.
• Доведение seller dashboard до бизнес-полезного состояния.
• Полноценная админская ролевая модель.
• SEO-метаданные и structured data на всех публичных страницах.

6. Требования P2 и поздние этапы

• Telegram notifications.
• SMS verification.
• Карта и геопоиск.
• CPL billing.
• CRM v1.0.
• Онлайн-платежи и транзакционная модель.

7. Критерии готовности ближайшего релиза

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

1. Production и документация синхронизированы.
2. Quality gates перестали врать: зелёные тесты и сборки соответствуют реальному коду.
3. Основные buyer/seller/admin потоки не содержат известных критичных несоответствий статусной модели.
4. Команда понимает, какой roadmap является каноническим и какие задачи идут следующими.
5. Базовые инженерные принципы проекта зафиксированы и пригодны для передачи новой команде.