02 — Product Roadmap

Общая логика фазирования

Phase 0 — Foundation (Недели 1-2)

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

Эпик F1: Репозиторий и инфраструктура хостинга кода

• Создать репозиторий bablo на GitVerse (primary)
• Создать зеркало на GitHub (mirror)
• Настроить SSH-ключи Claude Code на rigabase для push в оба ремоут
• Залить стартовый пакет (этот) в репозиторий
• Настроить git hooks: git push origin && git push mirror единой командой

Эпик F2: Стройплощадка (transparency site)

• Инициализировать Astro-проект в transparency/
• Настроить парсинг markdown из docs/, work-logs/, OPEN_QUESTIONS.md
• Реализовать страницы:
  • Главная: что мы делаем, статус проекта одной фразой
  • Документация (рендер документов из docs/plaid/ и docs/brief/)
  • Work-logs (хронологический список отчётов о работе)
  • Открытые вопросы (раздел «Для клиента» из OPEN_QUESTIONS.md)
  • Финансы (графика + таблица из expenses.yaml)
• Настроить фильтрацию: что НЕ публиковать на Стройплощадке (раздел «Для команды», файлы из docs/research/, ADR с internal: true)
• Билд CI: при пуше в main → собрать → закинуть в Docker-volume контейнера bablo-transparency
• Развернуть контейнер на rigabase (Docker Compose в /opt/bablo/)
• Прописать Proxy Host в NPM: bablo-stroyka.<domain> → bablo-transparency:80
• Защитить базовой HTTP-авторизацией (login/password в NPM)
• Отдать Руслану URL и креды

Эпик F3: Базовая финансовая прозрачность

• Создать expenses.yaml с начальным наполнением (ставки, первые записи)
• Написать скрипт infra/scripts/validate-expenses.mjs (валидация YAML)
• Реализовать отображение в Стройплощадке: график «потрачено накопительно по неделям», таблица записей, итоговая сумма с пометкой «ставки на 30% ниже среднерыночных»
• Шаблон work-log с авто-генерацией суммы часов (Claude Code сам считает по дате и часам в frontmatter)

Эпик F4: Финализация документов

• Финализировать 01-PRODUCT-VISION.md (есть)
• Финализировать 02-PRODUCT-ROADMAP.md (этот файл)
• Написать 03-PRD.md (полное техническое задание Phase 1)
• Написать 04-TECH-STACK.md (зафиксированный стек с обоснованиями)
• Подготовить docs/brief/01-Концепция-для-Руслана.md (короткая выжимка для клиента, без техники)
• Создать docs/research/VPS_rigabase_карта.md (есть, перенести)
• Создать первый ADR: docs/decisions/0001-стек.md

Критерий завершения Phase 0: Руслан открыл Стройплощадку, увидел документацию, увидел финансы, увидел список открытых вопросов. Прислал фидбэк хотя бы по одному пункту.

Phase 1 — MVP пилот (Недели 3-12)

Цель: работающий продукт, на котором Руслан и Семён реально ведут объект Серафимовича и хотя бы один раз ловят потерю.

Эпик P1: Основа приложения

• Инициализировать Next.js 15 + TypeScript + Tailwind в app/
• Настроить Drizzle ORM, подключить к PostgreSQL
• Установить pgvector в Docker-контейнере PostgreSQL
• Создать схему БД (по PRD): organization, user, project, estimate, document, item_catalog, counterparty, alert, etc.
• Генерация миграций Drizzle, применение
• Базовый layout приложения (header, sidebar, main)
• Тёмная тема по умолчанию (см. дизайн-токены в docs/plaid/05-DESIGN.md)

Эпик P2: Аутентификация и роли

• Настроить Lucia (или Auth.js)
• Email/password + magic link
• Роли: owner, editor, viewer
• Создать пользователей: Роман, Руслан, Семён, два соучредителя (всего 5)
• Middleware для проверки доступов на основе ролей
• Адаптивный мобильный header с навигацией

Эпик P3: Объекты и сметы

• CRUD для проекта (объекта): создание, редактирование, архивация
• Импорт xlsx сметы (формат Smeta.RU и Гранд-Сметы)
  • Парсер xlsx через exceljs или xlsx
  • Распознавание иерархии: разделы → подразделы → позиции
  • Извлечение коэффициентов и шифров расценок
  • UI ревью распарсенной сметы (можно править ячейки)
  • Сохранение в БД как estimate_version
• Импорт PDF договора с заказчиком (Anthropic API парсинг: сумма, аванс %, контактные данные)
• Главный экран объекта: смета, расходы, маржа (статика для начала, без живых данных)

Эпик P4: AI-парсинг документов

• Модуль lib/ai/anthropic-client.ts — единая точка вызова API, retry, биллинг
• Промпт для парсинга КП (PDF, xlsx, текст)
• Промпт для парсинга счёта на оплату
• Промпт для парсинга акта выполненных работ
• Промпт для парсинга свободного текста («монтаж 350 ₽ за м²»)
• Vision-парсинг фото и скриншотов
• Декомпозиция строки на cost_components (good/delivery/install/deposit/vat/other)
• Сохранение распарсенного в БД с привязкой к документу и проекту
• UI: показ распарсенного, возможность ручной правки
• Логирование стоимости каждого вызова (в expenses.yaml автоматически)

Эпик P5: Каталог позиций и матчинг

• Структура item_catalog: canonical_name, category, unit, specs, aliases, embedding
• Генерация эмбеддингов через Voyage AI или OpenAI Embeddings (без локальных моделей)
• Поиск похожих позиций через pgvector (косинусное расстояние)
• При новой document_line — поиск кандидата в каталоге → совпадение / создание новой записи
• LLM-проверка для пограничных случаев (cosine similarity 0.7-0.85)
• UI: ручная коррекция матчинга, добавление alias

Эпик P6: Telegram-бот

• Создать бота через @BotFather, получить токен
• Инициализировать grammY в tg-bot/
• Long-polling режим (без webhook)
• Команды: /start, /projects, /help
• Обработка входящих файлов: PDF, JPG, PNG, MP4 (вернуть «не поддерживаю», но без падения)
• Обработка текстовых сообщений
• Обработка пересланных сообщений (со ссылкой на оригинал)
• Привязка пользователя Telegram к user в БД (через /start <invite_token>)
• Контекстный вопрос «к какому объекту?» если непонятно
• Inline-ответ с разбором документа и линком в веб
• Деплой как systemd-сервис bablo-telegram-listener.service (по образцу dominium)

Эпик P7: Финансовая модель и маржа

• Сущность contract (договор с заказчиком): сумма, аванс %, дата начала
• Сущность revenue_event: поступление от заказчика
• Сущность payment_event: исходящая оплата
• Сущность extra_cost_category: преднастроенные категории (городок, аренда техники, ФОТ, штрафы, корпоративные, прочее) + кастомные
• Сущность extra_cost: запись внесметного расхода
• Расчёт маржи: триггер на любое изменение → пересчёт margin_snapshot
• UI главного экрана объекта: маржа большой цифрой, разбивка по категориям, цветовой индикатор
• Главный экран портфеля: все объекты карточками, маржа по каждому

Эпик P8: Контроль подрядчиков (Subcontract Tracker)

• Сущность subcontract: договор с подрядчиком, тип (fixed_scope / open_scope), сумма, объём, единица измерения
• Сущность subcontract_progress: накопленный закрытый объём
• Импорт акта подрядчика (в свободной форме) через AI-парсинг
• Привязка акта к договору, проверка остатка
• Алерт «акт превышает остаток по договору»
• UI карточки договора подрядчика: «всего / закрыто / осталось», список актов
• Для open_scope — отключение алертов «превышение объёма» (т.к. эталона нет)

Эпик P9: Калькулятор хомутовых лесов

• Исследование нормативов (ГОСТ 27321-2018, СП 49.13330.2010, ТТК производителей)
• Файл коэффициентов lib/calculators/scaffolding-coefficients.ts
• Формула расчёта: площадь + высота → периметр → ярусы → секции → штуки по 10 позициям
• UI калькулятора: ввод параметров, прозрачные промежуточные шаги
• Возможность ручной коррекции коэффициентов
• Сохранение расчёта как calculation с привязкой к проекту
• Сравнение полученного КП с эталонной комплектацией: для каждой позиции — отклонение в шт и в %
• Алерт «дефицит/избыток позиции» при отклонении > 5%

Эпик P10: Алерты

• Сущность alert: тип, severity (info/warning/critical), статус (open/acknowledged/resolved/ignored)
• Типы алертов в Phase 1:
  • duplicate_order — дубль заказа в каталоге
  • qty_below_calculation — поставщик недокомплектовал относительно эталона
  • qty_above_calculation — поставщик завысил относительно эталона
  • subcontract_overrun — акт подрядчика превышает остаток
  • price_outlier — цена выше других предложений на 15%+
  • margin_drop — маржа объекта упала >5% за неделю
• UI: лента алертов на главном экране, фильтры по статусу
• В Telegram-боте: уведомление о critical-алертах сразу после загрузки документа
• Возможность «пометить как ложный» (для калибровки порогов)

Эпик P11: Запуск пилота

• Загрузить реальную смету Серафимовича в систему
• Загрузить договор с заказчиком (поступления, ожидания)
• Прогнать существующие КП (Опалубка, СистемаТрейд) через систему — проверить, что алерты срабатывают
• Прогнать калькулятор лесов на 10 000 м² × 42 м (параметры из реального запроса Руслана к Опалубке)
• Семён получает приглашение в Telegram-бот, делает первый ввод документа
• Соучредители получают viewer-доступ
• Еженедельные звонки с Романом и Русланом первые 2 месяца

Критерий завершения Phase 1: На объекте Серафимовича за первые 4 недели использования поймана хотя бы одна реальная потеря (alert, на который Руслан отреагировал и который сэкономил деньги).

Phase 1.5 — Расширение (Месяцы 4-6)

Цель: доработать по фидбэку, подключить ещё 1-2 объекта.

Эпик 15-1: Доработка по фидбэку пилота

• Список приоритетных правок из фидбэка Руслана и Семёна
• Калибровка порогов алертов (по результатам «помечено как ложный» в Phase 1)
• UX-улучшения наиболее частых сценариев

Эпик 15-2: Подключение новых объектов

• Добавление 2-го объекта Руслана
• Добавление 3-го объекта Руслана
• Тестирование переключения контекста объекта в Telegram-боте

Эпик 15-3: Расширение типов документов

• КС-2, КС-3 (если на новых объектах будут)
• Универсальный передаточный документ (УПД)
• Накладные ТОРГ-12

Эпик 15-4: Сравнительные таблицы

• Сравнение нескольких КП по одной позиции
• Кросс-проектное сравнение «эта позиция на других объектах»

Эпик 15-5: Mail.ru интеграция (опционально, по запросу)

• Если Руслан говорит «надо» — IMAP-парсинг входящих с автоматической привязкой к объекту
• Если нет — отложить в Phase 2

Phase 2 — Продукт для рынка (Месяцы 7-12)

Цель: подготовить продукт к продаже другим стройкомпаниям, найти первого внешнего клиента.

Эпик 2-1: Multi-tenant

• Сущность organization, привязка всех данных
• Изоляция данных между организациями (RLS в PostgreSQL)
• Регистрация новых организаций
• Приглашения сотрудников в организацию

Эпик 2-2: Биллинг

• Тарифная модель (исследование рынка)
• Интеграция с платёжной системой (российской — ЮMoney, Тинькофф Касса, или ЮКассой)
• Управление подпиской из UI
• Триал-период

Эпик 2-3: Институциональная память («уроки»)

• Кросс-проектные алерты («такую плитку ты уже заказывал лишнюю на объекте X»)
• Каталог «уроков» — типовые ошибки, которые система видела
• Рекомендации использовать остатки с других объектов

Эпик 2-4: Расшифровка голосовых

• Whisper API или альтернативы
• Парсинг расшифровки через тот же AI-pipeline

Эпик 2-5: Лендинг и маркетинг

• Лендинг (Astro или Next.js)
• Кейс-стади по результатам пилота Руслана (с его разрешения)
• SEO-оптимизация под целевые запросы
• Первые продажные диалоги

Эпик 2-6: WhatsApp-бот (если рынок требует)

• WhatsApp Business API
• Аналогичный функционал Telegram-бота

Эпик 2-7: Документация для клиентов

• Help-центр
• Видеогайды по основным сценариям
• FAQ

Phase 3 — Масштабирование (Год 2+)

Цель: устойчивый рост клиентской базы, выход на 30+ платящих компаний.

Эпики на этой фазе зависят от того, что выявит Phase 2. Возможные направления:

• Прогноз кассового разрыва
• Управление складскими остатками
• Гантт-планирование работ
• Интеграция с 1С (двусторонняя)
• Интеграция с банк-клиентами
• API для третьих сторон
• Мобильное приложение (если адаптивный веб не покроет)
• Расценки/калькуляторы для других видов работ (опалубка, кладка, кровля, отделка)
• Расширение на другие сегменты строительства (ИЖС, дорожное, инфраструктурное)

Принципы приоритизации

При выборе следующей задачи из эпика:

1. Сначала то, что ловит деньги. Алерты, которые показывают конкретную потерю, важнее красивых UI.
2. Сначала то, что критично для пилота. Если без фичи нельзя запустить Серафимовича — она first priority.
3. Сначала то, что переиспользуется. Каталог позиций нужен во всех модулях — делать раньше калькулятора лесов.
4. Не оптимизировать преждевременно. Если за 4 недели пилота используется 1 раз — не доделывать перфектно.
5. Согласовать с Русланом любую задержку Phase 1. Если эпик растягивается > 2 недель — обсудить, не урезать ли scope.