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

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

- Статус документа: target requirements
- Актуально на: 28 марта 2026 года
- Владелец: backend/platform-команда
- Пересмотр: при изменении бизнес-приоритетов, quality gates или инженерных требований
- Область применения: текущие продуктовые и инженерные требования этапа controlled MVP
- Связанные документы:
  - [Roadmap](./roadmap.md)
  - [Текущее состояние](./current-state.md)
  - [Инженерные принципы](../governance/engineering-principles.md)

## 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. Базовые инженерные принципы проекта зафиксированы и пригодны для передачи новой команде.