# Roadmap разработки

## Цель первого MVP

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

В MVP не входят полноценный маркетплейс, собственная видеоплатформа, AI-анализ записей, Kubernetes и сложная микросервисная архитектура.

## Этап 0. Формализация продукта

Срок: 3-5 дней.

- Описать роли: пользователь, стример, эксперт, модератор, администратор.
- Зафиксировать пользовательские сценарии MVP.
- Описать жизненный цикл события:
  `draft -> scheduled -> ready -> live -> review -> finished -> archived`.
- Определить правила вступления в сквад и выхода из него.
- Разделить персональные и командные монеты.
- Определить, какие действия изменяют баланс.
- Решить, какие возможности предоставляет LiveKit, а какие Twitch/YouTube embeds.
- Создать список функциональных и нефункциональных требований.

Результат: `docs/product/mvp.md`, диаграмма состояний события и список acceptance criteria.

## Этап 1. Подготовка разработки

Срок: 2-3 дня.

- Инициализировать Git-репозиторий.
- Создать структуру `backend`, `frontend`, `docs`, `deploy`.
- Добавить `Makefile` с основными командами.
- Настроить Docker Compose для PostgreSQL, Redis, MinIO и Keycloak.
- Добавить `.env.example`.
- Настроить линтеры и pre-commit проверки.
- Создать GitHub Actions для lint и test.
- Добавить ADR-шаблон для архитектурных решений.

Результат: проект запускается одной командой, CI проходит на пустом каркасе.

## Этап 2. Проектирование контрактов и данных

Срок: 4-6 дней.

- Создать ER-диаграмму.
- Спроектировать таблицы пользователей, сквадов, событий и кошельков.
- Зафиксировать REST API в OpenAPI до реализации UI.
- Определить формат ошибок API.
- Ввести UUID, timestamps и optimistic locking.
- Спроектировать ledger вместо прямого изменения поля баланса.
- Добавить idempotency key для голосования и финансовых команд.
- Спроектировать transactional outbox.

Минимальные сущности:

```text
users
streamer_profiles
squads
squad_members
events
event_participants
event_rounds
polls
poll_options
votes
wallets
ledger_entries
outbox_events
media_assets
```

Результат: миграции, OpenAPI-файл, ER-диаграмма и два-три ADR.

## Этап 3. Первый backend vertical slice

Срок: 1-2 недели.

- Подключить OIDC-авторизацию.
- Реализовать профиль пользователя.
- Реализовать создание сквада.
- Реализовать вступление пользователя в сквад.
- Реализовать создание события стримером.
- Добавить приглашение второго участника.
- Реализовать изменение статусов события.
- Сделать публичные endpoints для активных и недавних событий.
- Добавить интеграционные тесты через Testcontainers.
- Добавить структурированные логи и базовые метрики.

Результат: полный HTTP-сценарий от входа пользователя до создания запланированного события.

## Этап 4. Первый frontend vertical slice

Срок: 1-2 недели.

- Создать дизайн-токены и базовые компоненты в Storybook.
- Реализовать авторизацию.
- Сделать главную страницу с активными и недавними событиями.
- Сделать поиск и страницу сквада.
- Сделать кабинет пользователя и стримера.
- Сделать форму создания события.
- Генерировать TypeScript-клиент из OpenAPI.
- Добавить обработку loading, empty и error states.
- Покрыть критичные компоненты тестами.

Результат: пользователь проходит основной сценарий через браузер.

## Этап 5. Live-комната

Срок: 2 недели.

- Поднять LiveKit локально.
- Добавить веб-камеры двух участников.
- Добавить демонстрацию экрана.
- Встроить разрешенные Twitch/YouTube плееры и чаты.
- Реализовать WebSocket-подключение к комнате.
- Передавать presence, состояние события и серверное время.
- Реализовать переподключение и восстановление состояния.
- Не доверять клиентскому таймеру: источником времени является сервер.

Результат: два стримера и зрители одновременно находятся в live-комнате.

## Этап 6. Интерактив и результаты

Срок: 1-2 недели.

- Реализовать серверное создание опроса.
- Добавить начало и завершение опроса по таймеру.
- Обеспечить один голос пользователя с защитой от повторов.
- Транслировать агрегированные результаты через WebSocket.
- Реализовать завершение события.
- Добавить экспертную и модераторскую проверку результата.
- Начислять награды через ledger.
- Публиковать доменные события через outbox.

Результат: событие полностью проходит путь от создания до начисления наград.

## Этап 7. Архив и медиа

Срок: 1 неделя.

- Записывать LiveKit-комнату.
- Сохранять запись в MinIO/S3.
- Создавать preview через FFmpeg.
- Добавить страницу завершенного события.
- Сохранять хронологию раундов, опросов и итогов.
- Добавить retry и dead-letter обработку фоновых задач.

Результат: завершенные события доступны в архиве.

## Этап 8. Минимальный e-commerce

Срок: 1-2 недели.

- Добавить партнерские коллекции и товары.
- Реализовать остатки и резервирование.
- Добавить корзину и создание заказа.
- Оплачивать заказ внутренними монетами через ledger.
- Защитить создание заказа idempotency key.
- Покрыть конкурентное списание и резервирование интеграционными тестами.

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

## Этап 9. Нагрузка и надежность

Срок: 1 неделя.

- Определить SLI/SLO для HTTP API и live-комнаты.
- Создать k6-сценарии для REST и WebSocket.
- Проверить конкурентное голосование и начисление монет.
- Добавить Redis для presence и горизонтального масштабирования realtime.
- Проанализировать SQL через `EXPLAIN ANALYZE`.
- Добавить необходимые индексы.
- Настроить rate limiting.
- Проверить graceful shutdown.
- Провести тест восстановления после отказа Redis, PostgreSQL и worker.
- Опубликовать отчет с графиками, bottleneck и изменениями.

Результат: утверждения о нагрузке подтверждены измерениями.

## Этап 10. Разделение на пять репозиториев

Выполнять после работающего MVP и стабилизации API.

- Вынести `bartered-web`.
- Вынести WebSocket-контур в `bartered-realtime`.
- Вынести media workers в `bartered-media`.
- Вынести deployment и observability в `bartered-platform`.
- Оставить доменную бизнес-логику в `bartered-api`.
- Настроить versioning контрактов и независимый CI.
- Подготовить локальный compose, объединяющий все репозитории.

Каждый репозиторий должен содержать:

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

## Порядок первых задач

1. Написать `docs/product/mvp.md`.
2. Нарисовать lifecycle события и ER-диаграмму.
3. Инициализировать каркас Go и React.
4. Поднять PostgreSQL, Redis, MinIO и Keycloak через Docker Compose.
5. Описать API пользователей, сквадов и событий в OpenAPI.
6. Реализовать миграции и слой доступа через sqlc.
7. Сделать сценарий: вход -> создание сквада -> создание события.
8. Подключить React к готовому API.
9. После устойчивого HTTP-сценария переходить к LiveKit и WebSocket.

## Что покажет профессиональный уровень

- осмысленные границы модулей;
- SQL и транзакции, а не только CRUD;
- идемпотентность и конкурентный доступ;
- контракт OpenAPI и совместимость клиентов;
- интеграционные и end-to-end тесты;
- метрики, трассировка и структурированные логи;
- нагрузочные тесты с опубликованными результатами;
- ADR, объясняющие компромиссы;
- воспроизводимый локальный запуск и CI/CD.