# Building OS — концепция продукта

Статус: интерактивная продуктовая концепция. Папка автономна и не входит в сборку Village OS.

Открыть локально:

- `index.html` — маркетинговый лендинг;
- `prototype.html` — кликабельный прототип приложения арендатора и веб-кабинета управляющей команды.

Для корректной работы относительных ссылок удобнее запустить статический сервер:

```bash
cd products/building-os
python3 -m http.server 8080
```

Затем открыть `http://localhost:8080`.

Публичный стенд: `https://building.village-os.ru`.

Nginx-конфигурация публичного стенда хранится в `deploy/nginx-building-os.conf`. Статика
размещается отдельно от Village OS в `/var/www/building-os`.

Прямые ссылки для демонстрации:

- приложение арендатора: `https://building.village-os.ru/prototype?view=tenant&screen=home`;
- создание заявки: `https://building.village-os.ru/prototype?view=tenant&screen=requests`;
- гостевой доступ: `https://building.village-os.ru/prototype?view=tenant&screen=access`;
- бронирование: `https://building.village-os.ru/prototype?view=tenant&screen=spaces`;
- каталог услуг: `https://building.village-os.ru/prototype?view=tenant&screen=services`;
- операционная сводка: `https://building.village-os.ru/prototype?view=ops&screen=overview`;
- Service desk: `https://building.village-os.ru/prototype?view=ops&screen=requests`;
- эксплуатация: `https://building.village-os.ru/prototype?view=ops&screen=maintenance`;
- аналитика: `https://building.village-os.ru/prototype?view=ops&screen=analytics`;
- интеграции: `https://building.village-os.ru/prototype?view=ops&screen=integrations`.

## 1. Продуктовая идея

Building OS — единое цифровое окно арендатора и операционный слой здания. Он не заменяет BMS,
СКУД, VMS, ERP/1С или CMMS, а связывает их с ежедневными сценариями арендаторов, ресепшена,
охраны, FM-команды, инженеров и подрядчиков.

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

## 2. Для каких объектов

- Office: одно офисное здание, до 10 арендаторов и 300 активных пользователей;
- Business Center: крупный бизнес-центр или два небольших здания;
- Campus: портфель зданий с едиными правилами, SSO и общей аналитикой;
- Managed Territory: деловой квартал, индустриальный парк, курорт или логистическая территория.

Первый фокус — современный бизнес-центр класса A/B+ с 10–40 арендаторами. Здесь достаточно сложные
процессы, чтобы ценность продукта была очевидной, но ещё возможно провести управляемый пилот.

## 3. Роли

### Пользовательский контур

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

### Операционный контур

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

## 4. Доменная модель

```text
Портфель
└── Территория / кампус
    └── Здание
        ├── Этаж
        │   ├── Помещение
        │   └── Переговорная / сервисная зона
        ├── Парковка
        │   └── Парковочное место
        └── Зона доступа

Организация-арендатор
├── Договор
├── Помещения
├── Администраторы
└── Сотрудники
```

Пользователь может состоять в нескольких организациях и иметь права на нескольких объектах.
Заявка привязана к объекту, помещению, SLA, заявителю, исполнителю, затратам и истории изменений.

## 5. MVP

### Приложение арендатора

1. Главная: здание, быстрые действия, активные заявки, ближайшие бронирования и новости.
2. Заявки: категория, помещение, фото, описание, удобное время, статус и чат.
3. Доступ: гостевой пропуск, список гостей, QR, заявка на постоянный доступ.
4. Пространства: переговорные, парковка, коворкинг, спортзал; календарь и бронирование.
5. Услуги: клининг, доставка, кейтеринг, мелкий ремонт и дополнительные сервисы.
6. Документы и новости: регламенты, памятки, плановые работы, экстренные уведомления.
7. Профиль: организация, помещения, автомобили, коллеги и настройки уведомлений.

### Веб-кабинет управляющей команды

1. Операционная сводка: открытые заявки, риск SLA, проходы, загрузка и инциденты.
2. Service desk: очереди, фильтры, приоритеты, назначение, чек-листы, акты и затраты.
3. Арендаторы: организации, договоры, помещения, сотрудники и администраторы.
4. Доступ: гостевые и постоянные права, зоны, массовый отзыв и журнал событий.
5. Пространства: календарь, правила, тарифы, блокировки и загрузка.
6. Эксплуатация: оборудование, регламентные работы, подрядчики и чек-листы.
7. Коммуникации: новости, документы, сегменты получателей и экстренные сообщения.
8. Аналитика: SLA, причины обращений, загрузка, NPS/CSAT, затраты и выгрузки.
9. Интеграции: состояние коннекторов, очередь обмена, повторы и журнал ошибок.
10. Настройки: объекты, роли, SSO/2FA, брендирование и аудит.

## 6. Сквозные сценарии

### Заявка арендатора

Сотрудник создаёт заявку → система выбирает SLA по категории и договору → диспетчер назначает
исполнителя → сотрудник получает статусы → инженер заполняет чек-лист и акт → заявитель оценивает
результат → данные попадают в аналитику арендатора и объекта.

### Гостевой доступ

Сотрудник указывает гостя, время и зоны → при необходимости администратор арендатора согласует
заявку → гость получает ссылку/QR → охрана видит ожидаемый визит → событие прохода сохраняется.
Физическое открытие турникета появляется только после подключения конкретной СКУД.

### Бронирование

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

## 7. Что можно переиспользовать из Village OS

- каркас TypeScript-монорепы и общие Zod-контракты;
- авторизацию, refresh-токены, инвайты и восстановление пароля;
- уведомления, web-push, WebSocket и шаблоны писем;
- media upload, аудит, health-check, Sentry и провижининг инстансов;
- управление модулями, брендирование и UI-примитивы;
- базовые механики заявок, бронирований, чатов и ролей.

Что нельзя переносить как есть:

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

## 8. Техническая граница продукта

Рекомендуемая архитектура — отдельные приложения и отдельная доменная схема Building OS, но с
возможностью вынести проверенные платформенные блоки в общие пакеты. Для первого пилота — отдельная
БД и процесс на объект; позднее — control plane и портфельный уровень.

Критичные требования до production: decimal для денег, расширенный RBAC, SSO и 2FA, аудит доступа,
очередь интеграций, off-site backup, мониторинг, модель SLA/эскалаций и юридическая модель организаций.

## 9. Этапы

1. Discovery: обследование одного объекта, карты ролей, SLA и систем-интеграций.
2. Concierge MVP: tenant PWA, service desk, новости, документы и ручные гостевые заявки.
3. Operations: SLA, подрядчики, чек-листы, акты, пространства и аналитика.
4. Integration: первый стандартный коннектор СКУД, ERP-обмен и SSO.
5. Portfolio: несколько объектов, общие политики, BI и эксплуатационный control plane.

Лендинг намеренно описывает продуктовую концепцию без утверждений, что внешние интеграции уже
реализованы. Кликабельный прототип демонстрирует целевой UX, а не production-систему.