OK24 Atlas: продуктовая архитектура

Дата: 2026-09-15. Статус: базовая продуктовая архитектура; технические решения и план выполнения описаны в связанных документах.

Техническое предложение по подпроектам, SVG-редактору, Windows, хранилищам и схемам БД: OK24 Atlas — техническая архитектура. Документ учитывает последующие уточнения пользователя: Python, готовые веб-компоненты, PostgreSQL, вход по логину и паролю без регистрации, приоритет Windows 10 LTSC и отсутствие бизнес-автоматизации. Предложенный стек ещё не реализован и не означает утверждения всех технических решений.

Утверждённое название сервиса: OK24 Atlas. Название выбрано пользователем. Отдельные названия редактора и приложения стенда пока не утверждены.

1. Назначение продукта

OK24 Atlas — веб-сервис управления интерактивными картами торговых центров. Команда OK24 полностью создаёт исходные карты, геометрию и маршруты. Клиент получает веб-кабинет и редактируемые помещения: может менять сведения, расширять и объединять помещения. Посетители используют карту только на установленных стендах под Windows.

В первом выпуске подключается только существующая карта текущего клиента, со всеми её этажами и возможностями. Допустима ограниченная адаптация к серверу и редактору; существенная переработка интерфейса карты не является целью. Новые карты сейчас не создаются.

Платформа хранит клиентов и принадлежащие им карты и допускает появление других реализаций карт в будущем, включая серверный расчёт навигации и другие серверные функции. HTML/CSS/JS текущей карты — реализация для существующего клиента, а не обязательный формат поведения всех будущих карт.

Админки работают через браузер. Версия для стенда обязательно поставляется как устанавливаемое приложение OK24 Atlas. В состав приложения входят скрипты настройки ОС, на которую устанавливается ПО. Целевая ОС стендов — Windows 10 LTSC x64. Приложение — Electron с Windows-агентом; установка и системные настройки описаны в технической архитектуре. Необходимость автономной работы также определяется отдельно. Мобильная карта, QR-сценарии и публикация на сайтах ТЦ сейчас вне объёма.

2. Что существует сейчас

Выводы основаны на статическом изучении корневого приложения: index.html, server.js, js/swiper.js, js/modals.js, js/keyboard.js, js/ads.js и SVG, подключённых в index.html. Работоспособность интерфейса в браузере в рамках этого исследования не проверялась.

• Подключены четыре SVG: паркинг и три этажа.
• Данные интерактивных объектов находятся в атрибутах SVG: name, full_name, floor, cathegory, description, type.
• Реализованы переключение этажей, масштабирование, список объектов, поиск, категории, карточки, экранная клавиатура и выбор навигационного стола.
• Маршруты подготовлены заранее. Код показывает элементы с идентификаторами вида route_<объект>_<стол>. Это не расчёт пути между произвольными точками.
• SVG содержит графическое оформление; логотипы карточек также загружаются из отдельных файлов по имени объекта.
• Есть рекламные блоки в HTML и серверный метод получения рекламных изображений; автоматическая загрузка этих изображений в js/ads.js закомментирована.
• Сервер раздаёт файлы, принимает статистику кликов и формирует простой отчёт. В интерфейсе часть отправки событий закомментирована, поэтому это заготовка аналитики, а не полный учёт взаимодействий.
• В исследованном приложении нет модели клиентов, входа пользователей, прав доступа, редактора и управляемой публикации.
• В дереве присутствуют дополнительные и вложенные копии zil_a. Перед переносом нужно определить нужную исходную версию; нельзя автоматически считать все копии самостоятельными картами.

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

3. Общая схема

Это логические части продукта. Они не требуют отдельных серверов или отдельных сервисов на старте. Один сервер может отдавать обе админки, предоставлять установочные пакеты и обновления приложения для стендов и обслуживать данные карт.

Общая платформа и разные реализации карт

• Платформа: клиенты, пользователи, права, хранение, черновики, публикации, история, стенды и учёт обслуживания.
• Реализация карты: её интерфейс, формат редактирования и навигационное поведение. Разрабатывается командой OK24; текущая SVG-карта — первая такая реализация.
• Приложение стенда: устанавливаемое ПО, которое запускает реализацию карты, получает опубликованные данные, отдельно обменивается настройками, командами и состоянием с сервером и включает скрипты настройки целевой ОС. Способ упаковки текущего HTML/CSS/JS-интерфейса выбирается на этапе технического проектирования.
• Данные конкретной карты: этажи, помещения, объекты, маршруты, материалы и настройки.
• Серверные возможности: функции, которые использует выбранная реализация. Сейчас учитываем имеющиеся методы материалов и статистики; в будущем возможны расчёт маршрута и другие функции.

У карты фиксируются поддерживаемые возможности и совместимая версия её приложения. Кабинет показывает соответствующие инструменты. Платформа не должна предполагать, что всякая карта всегда является только набором SVG с готовыми маршрутами.

Общие функции не дублируются для каждой новой карты. Различия в пользовательском интерфейсе и навигации допустимы: не требуется один универсальный просмотрщик для всех будущих клиентов. В первом выпуске не создаём каталог расширений и другие реализации, а определяем границы подключения к платформе.

Для будущего серверного расчёта запрос должен относиться к конкретной карте и версии её навигационных данных. Серверный маршрут должен соответствовать плану, открытому на стенде. Первой карте сохраняем текущий способ показа заранее подготовленных путей.

4. Основные сущности

Сущность	Значение и связи
Клиент	Организация, приобретающая сервис. Может владеть несколькими картами.
Пользователь	Конкретный сотрудник со своим входом. Получает членство в организации и права на нужные карты.
Карта	Один ТЦ или другой навигационный объект целиком, со всеми этажами. Принадлежит одному клиенту.
Этаж	План и объекты отдельного уровня, включая паркинг. Принадлежит карте.
Помещение или зона	Область на плане со своим идентификатором и редактируемой геометрией. Может быть свободной или занятой магазином.
Объект каталога	Магазин, кафе или сервис: название, категория, описание, логотип, контакты и другие сведения.
Размещение объекта	Связь объекта с зоной или точкой на плане. Один магазин может занимать несколько помещений.
Точка старта	Вход, информационная стойка или положение терминала, откуда можно показать маршрут.
Маршрут	В первой версии — подготовленный путь от определённой точки старта к назначению, с возможными фрагментами на нескольких этажах.
Материал	SVG, логотип, изображение, рекламный баннер или видео, принадлежащее клиенту и используемое картами.
Версия карты	Согласованный набор планов, данных, маршрутов, материалов и настроек на момент публикации.
Реализация карты	Подготовленное OK24 приложение карты с определёнными возможностями редактора и серверными функциями.
Версия приложения стенда	Выпуск устанавливаемого ПО и входящих в него скриптов настройки ОС. Имеет собственную версию и требования к совместимости с картой.
Точка показа	Зарегистрированный у клиента стенд Windows со своей картой, централизованными настройками, состоянием подключения и историей команд управления.

Клиент не равен пользователю, этаж не равен карте, терминал не равен отдельной копии карты.

Для первой версии не нужен дополнительный уровень «объект недвижимости» между клиентом и картой: карта уже представляет один ТЦ. Такой уровень понадобится, только если одному ТЦ потребуются несколько независимых карт.

Почему помещение и магазин разделены

Если магазин выехал, его помещение осталось. Если изменилось название магазина, его размещение и путь к нему остались. Стабильные идентификаторы зон и точек назначения позволяют менять бизнес-данные без переименования SVG-маршрутов и файлов вручную.

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

5. Админка владельцев сервиса

Основные разделы: клиенты, карты, доступы, состояние обслуживания, история действий.

Возможности:

• Создать клиента, заполнить сведения и создать логин его администратора.
• Создать карту в нужной организации, подготовить этажи и первоначальное содержание.
• Назначить реализацию карты и доступные клиенту операции с помещениями. В первом выпуске подключается существующая карта.
• Видеть все карты, их состояние, дату последней публикации и ответственных сотрудников.
• Помогать с импортом, привязкой помещений и подготовкой маршрутов.
• Управлять доступными возможностями и лимитами клиента: карты, сотрудники, терминалы, место для материалов.
• Учитывать пробный период, активное обслуживание, приостановку и архивирование.
• Выполнять действия поддержки с записью автора и результата в журнале.
• Видеть состояние подключённых стендов и результаты команд управления; в дальнейшем смотреть расширенную сводную статистику использования.

Приостановка редактирования и отключение показа на стендах — разные действия. Они должны иметь явные правила. Задолженность или истечение пробного периода не должны приводить к случайному удалению материалов клиента.

6. Кабинет клиента и редактор карты

После входа пользователь видит доступные ему карты. Внутри карты предлагаются разделы:

1. Обзор: опубликована ли карта, есть ли изменения, кто и когда публиковал.
2. Этажи и план: выбор помещений, изменение их границ, расширение, объединение и привязка к объектам.
3. Объекты: магазины, питание, услуги и инфраструктура.
4. Категории: названия, иконки, порядок и видимость.
5. Навигация: точки старта, доступные маршруты и результаты их проверки.
6. Материалы и реклама: логотипы, изображения, видео и порядок рекламных блоков.
7. Оформление: название ТЦ, фирменные цвета, общая информация и контакты.
8. Публикация: предпросмотр, ошибки, выпуск версии и история.
9. Доступы и стенды: сотрудники и их полномочия, все подключённые столы клиента, их настройки показа, состояние связи, версии и инструменты управления, включая перезапуск приложения и перезагрузку ПК.

Обычный рабочий сценарий: выбрать помещение на плане → открыть карточку → заменить арендатора или исправить сведения → сохранить черновик → проверить → опубликовать.

Сценарий изменения геометрии: выбрать одно или несколько помещений → изменить границы или объединить → настроить сведения и вход результирующего помещения → проверить влияние на маршруты → предпросмотр → публикация.

Клиент управляет только своими данными. Проверка принадлежности карты, материалов и прав выполняется сервером при каждой операции, а не только скрытием разделов интерфейса.

7. Роли и полномочия

Роль	Полномочия
Администратор OK24	Управление сервисом и клиентами; доступ поддержки с журналированием.
Администратор клиента	Управление доступными картами, сотрудниками организации и публикацией.
Редактор	Изменение содержания назначенных карт и предпросмотр. Права на геометрию и публикацию выдаются отдельно.
Наблюдатель, позднее	Просмотр материалов и отчётов без изменения.
Посетитель	Работа с опубликованной картой на стенде без входа в кабинет.

В первой версии достаточно администратора сервиса, администратора клиента и редактора. Для небольшой команды клиента один человек может совмещать редактирование и публикацию.

8. SVG и границы редактора

Создание исходной карты выполняет OK24. Клиенту передаются подготовленные редактируемые помещения. Редактирование включает как сведения, так и реальное изменение геометрии SVG. Обязательная основа редактора — сторонние браузерные библиотеки SVG.js и Paper.js; собственный универсальный SVG-движок с нуля не разрабатывается. Atlas реализует поверх библиотек операции с помещениями, права и проверки маршрутов.

Управление содержанием — первая версия

• Изменение названий, описаний, категорий, логотипов и видимости объектов.
• Привязка магазина к существующей зоне, смена арендатора и отметка свободного помещения.
• Изменение рекламных материалов и оформления.
• Загрузка подготовленного SVG и проверка распознанных этажей, зон и маршрутов.
• Настройка подготовленных точек старта и проверка доступных маршрутов.

Текущие SVG уже существуют и являются исходным материалом первой версии. Дополнительный импорт остаётся функцией подготовки и обновления карты; это не обязательный первый шаг клиента после каждого входа. Подготовку импортированных материалов и связей выполняет OK24.

Редактирование помещений — первая версия

• Выбор помещения на плане и изменение его границ, в том числе расширение.
• Выбор соседних помещений и объединение их геометрии в одно помещение.
• Настройка арендатора, названия и логотипа результирующего помещения.
• Предпросмотр изменённого SVG, отмена действий и сохранение черновика.
• Проверка наложений и связей с объектами и маршрутами перед публикацией.

Предлагаемая граница редактора: OK24 задаёт редактируемые помещения и защищённые элементы плана — например, лестницы, опорные элементы и общие проходы. Клиент изменяет разрешённую геометрию визуально, без ручной правки XML. Точный набор ограничений и операций, кроме уже необходимых расширения и объединения, предстоит описать отдельно.

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

Как геометрия влияет на маршруты

В первой карте сохраняются готовые пути из SVG. Изменение контура помещения само по себе не рассчитывает новый путь.

Предлагаемый порядок: редактор выявляет затронутые помещения, входы и маршруты и отмечает их для проверки. Проверяется также изменение проходов, через которые идут пути к другим объектам. Если требуется коррекция маршрутов, её выполняет OK24; до этого затронутые изменения остаются в черновике. Стенды продолжают показывать предыдущую согласованную версию. Изменения сведений без влияния на навигацию не требуют участия OK24.

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

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

Источник данных

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

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

То же относится к контурам помещений: опубликованный SVG должен отражать сохранённую геометрию редактора. Исходные SVG сохраняются как исходные материалы; прочие слои, этажи и элементы карты должны переживать изменение помещений без потери содержимого.

При замене плана система показывает, какие связи сохранились, появились или потерялись. Неоднозначные соответствия подтверждает оператор; исчезнувшие помещения и маршруты нельзя связывать с объектами по догадке.

Загружаемый SVG проверяется до предпросмотра: допустимое содержимое, отсутствие исполняемого кода и нежелательных внешних ресурсов. Это часть безопасного импорта пользовательских материалов.

9. Черновик и публикация

Жизненный цикл:

Создание → подготовка черновика → предпросмотр → проверка → публикация → новые изменения в черновике.

• Сохранение не изменяет карту посетителей.
• Предпросмотр доступен сотрудникам с нужными правами.
• Перед публикацией проверяются связи зон, объектов, маршрутов и наличие используемых материалов.
• Критические ошибки блокируют публикацию; некритические замечания показываются отдельно.
• Выпуск фиксирует целую версию вместе с материалами. Нельзя показать новый план со старыми маршрутами из другой версии.
• Администратор может вернуть предыдущую опубликованную версию; её материалы должны сохраняться.
• История показывает автора, дату и краткое описание изменения.
• Одновременное редактирование не должно молча перезаписывать чужие изменения; для начала достаточно обнаруживать конфликт сохранения.

У карты может одновременно быть опубликованная версия и более новый черновик. «Есть изменения» и «опубликована» не являются взаимоисключающими состояниями.

10. Публикация на стендах

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

Единственный рассматриваемый канал показа — установленные стенды под Windows. На каждом стенде обязательно устанавливается приложение OK24 Atlas, которое показывает назначенную карту. Веб-формат относится к админкам; текущий HTML/CSS/JS-интерфейс карты может использоваться внутри устанавливаемого приложения.

Приложение и настройка ОС

• Поставка для стенда включает приложение и скрипты настройки соответствующей ОС.
• Перечень системных настроек, момент выполнения скриптов и необходимые права определяются при техническом проектировании.
• Для Windows используются Electron, установщик и отдельный агент с необходимыми системными правами.
• Системные скрипты подготавливает и выпускает OK24 как часть ПО. Редактирование помещений и материалов клиентом не изменяет эти скрипты.
• Версия приложения и версия содержимого карты учитываются отдельно. Публикация изменений помещений обновляет карту в совместимом приложении; обновление ПО и системных настроек имеет отдельный процесс и не выполняется при каждой публикации карты.

Приложение обязательно имеет отдельный канал связи с сервером для настроек и управления стендом. Он работает независимо от публикации содержимого карты: изменение настроек показа или отправка команды не требуют повторной публикации SVG или выпуска приложения. Это логическое разделение; конкретный транспорт выбирается позже.

• Основной источник настроек — кабинет клиента на сервере. В нём хранятся все подключённые столы, назначенные им карты и индивидуальные настройки: точка старта, этаж, ориентация, поведение при бездействии и другие параметры показа.
• При первоначальной установке допустим ручной ввод для подключения и привязки приложения к нужному клиенту и столу. После привязки приоритет имеют настройки из кабинета: приложение получает их автоматически при подключении и синхронизирует дальнейшие изменения. Повторный запуск не требует вводить настройки заново.
• Пользователь с нужными правами управляет своими стендами из кабинета: меняет настройки, перезапускает приложение, отправляет команду перезагрузки ПК и использует другие предусмотренные инструменты управления. Состав дополнительных инструментов уточняется отдельно.
• Приложение сообщает о связи, применённых настройках, версиях приложения и карты, получении команд и результате их выполнения. Кабинет различает желаемые настройки и фактически применённые, а также отправленную команду и подтверждённое выполнение.
• Команда адресуется конкретному зарегистрированному стенду и проверяется по правам клиента. История сохраняет автора, время и результат; для повторной доставки и восстановления связи предусматриваются правила, исключающие повторное выполнение уже исполненной команды и неожиданную позднюю перезагрузку.
• Перезапуск приложения и перезагрузка ПК — отдельные команды с отдельными результатами. Для каждой целевой ОС необходимо выбрать поддерживаемый механизм и необходимые права; доступность команды на устройстве показывается в кабинете. Механизм управления должен учитывать восстановление связи после перезапуска.
• Приложение сохраняет последние применённые настройки локально. Сохранение настроек не означает, что вся карта и серверные функции уже поддерживают автономную работу; этот режим определяется отдельно.

Показ и обновление карты

В кабинете клиента для терминала задаются карта, точка старта, начальный этаж, ориентация и поведение при бездействии. Приложение получает их через канал управления. Один ТЦ с пятью терминалами использует одну карту и пять централизованно сохранённых наборов настроек показа.

Стенд использует назначенную точку старта. Существующие возможности выбора навигационного стола, поиска, этажей, карточек, рекламы, экранной клавиатуры и показа маршрутов сохраняются. Перед выпуском их проверяют на целевой Windows 10 LTSC.

Публикация делает новую версию доступной всем точкам показа. Приложение проверяет обновления и переключает версию целиком в подходящий момент, например после завершения взаимодействия. Фактически применённая версия и состояние связи видны в кабинете через канал управления. Расширенная диагностика и автономная работа при отсутствии интернета — последующие возможности, требующие отдельного решения.

11. Полный сценарий обслуживания клиента

1. OK24 создаёт организацию и подключает существующую карту ТЦ к платформе.
2. Оператор использует имеющиеся SVG, подготавливает редактируемые помещения и проверяет связи зон, объектов и маршрутов.
3. Клиент получает созданные администратором логин и временный пароль; после смены пароля настраивает доступ сотрудников.
4. Сотрудник актуализирует арендаторов, логотипы, описания и рекламу; при необходимости изменяет разрешённую геометрию помещений.
5. Ответственный проверяет карту в предпросмотре и публикует первую версию.
6. На стенды Windows устанавливается приложение со скриптами настройки соответствующей ОС и выполняется первичная привязка к клиенту и столу. Приложение получает назначенную карту и настройки из кабинета. Дальнейшая настройка, перезапуск приложения и перезагрузка ПК доступны через кабинет.
7. Повседневные изменения проходят через черновик и публикацию.
8. При изменении планировки проверяются размещения и затронутые маршруты. Если маршруты требуют изменения, OK24 подготавливает их, после чего выпускается согласованная версия.

12. Бизнес-возможности

Это варианты развития продукта, а не утверждённые тарифы.

Направление	Что получает клиент
Первичное подключение	Подготовленная интерактивная карта из исходных планов, проверенные объекты и маршруты.
Подписка на сервис	Кабинет, редактирование помещений, доставка обновлений на стенды и история публикаций. Естественная единица тарификации — активная карта ТЦ.
Терминалы	Подключённые столы, централизованные настройки, контроль связи и версий, удалённый перезапуск приложения и перезагрузка ПК.
Контентное сопровождение	Команда OK24 обновляет арендаторов и рекламу по поручению клиента.
Расширенные возможности	Расширенная аналитика, несколько языков, серверная навигация и дополнительные функции конкретной реализации карты.
Работа с сетью ТЦ	В будущем — несколько карт одной организации и распределённые права сотрудников. Новые карты в первый выпуск не входят.
Рекламные возможности	Управление баннерами, позднее — расписания, размещения и отчёты.

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

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

13. Предлагаемый объём первой версии

Обязательно

• Клиенты, пользователи, вход по логину и паролю; создание учётных записей и сброс доступа администратором без регистрации и email-приглашений.
• Разделение прав и данных клиентов.
• Подключение существующей карты с паркингом и всеми тремя этажами, с сохранением текущих функций и минимальными изменениями её интерфейса.
• Модель принадлежности карт клиентам, допускающая будущие карты и разные реализации; создание других карт сейчас не требуется.
• Подготовка имеющихся SVG к редактированию и дополнительный импорт с понятным отчётом и настройкой связей.
• Объекты, категории, логотипы, размещения и базовая реклама.
• Визуальный редактор геометрии помещений: изменение границ, расширение и объединение с обновлением связанных объектов.
• Подготовленные маршруты и настройки точек старта.
• Проверка влияния геометрических изменений на навигацию и передача необходимых исправлений маршрутов команде OK24.
• Черновик, предпросмотр, проверки, публикация и возврат версии.
• Обязательное устанавливаемое приложение для стендов Windows, включающее скрипты настройки соответствующей ОС, показ и обновление текущей карты.
• Раздельный учёт версий приложения и карты, с проверкой их совместимости.
• Отдельный канал управления стендами: получение настроек из кабинета, список подключённых столов, состояние связи и применённых версий, перезапуск приложения и перезагрузка ПК с учётом прав и возможностей целевой ОС.
• Сохранение существующих серверных возможностей материалов и статистики с учётом их фактического состояния; интеграция с принадлежностью данных клиенту и карте.
• Журнал существенных изменений и базовое управление обслуживанием клиента.

Затем

• Расширенная статистика и отчёты сверх имеющихся возможностей.
• Расписания рекламы и публикаций.
• Дополнительные языки и функции конкретных реализаций карт.
• Расширенная диагностика терминалов и работа без интернета; базовый контроль состояния и управление входят в первый выпуск.
• Самостоятельная регистрация и автоматическая оплата.
• Инструменты подготовки навигационной сети для OK24 и серверный расчёт произвольных маршрутов — отдельные возможные направления; в текущий выпуск не входят.

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

14. Переход от скетча

1. Зафиксировать существующую карту, её этажи, поведение и серверные функции как основу приёмки; определить нужные исходники среди копий.
2. Выделить редактируемые помещения, защищённые слои, объекты, размещения и точки старта; обеспечить сохранение всех остальных элементов SVG.
3. Сохранить существующие пути с явной привязкой к стабильным назначениям и точкам старта.
4. Включить текущую карту в устанавливаемое приложение стенда со скриптами настройки ОС, минимально адаптировать карту к загрузке опубликованной версии и настроек стенда. На уровне платформы предусмотреть подключение других реализаций и серверных функций.
5. Добавить управление клиентами, доступами, содержанием и геометрией помещений.
6. Ввести версии, предпросмотр и публикацию.
7. Проверить установку приложения, первичную привязку, получение и применение настроек из кабинета, отчёт о состоянии, удалённый перезапуск приложения и перезагрузку ПК на целевой Windows 10 LTSC. Пройти полный сценарий на текущей карте: изменение сведений, расширение и объединение помещений, проверка маршрутов, публикация и возврат версии на стендах.

Критерий первой работающей версии: на стендах Windows установлено приложение со скриптами настройки соответствующей ОС; текущая карта сохраняет все этажи и возможности. Сотрудник клиента через веб-кабинет меняет сведения и геометрию помещений, включая расширение и объединение. После проверки связей и необходимых исправлений маршрутов согласованная версия появляется в приложениях стендов. Обычные изменения не требуют ручной правки HTML/JS; создание исходной карты и подготовка маршрутов остаются обязанностью OK24.

15. Подпроекты единого Git-репозитория OK24-Atlas

Все части продукта разрабатываются в одном Git-репозитории OK24-Atlas. Подпроект здесь означает область ответственности с собственным исходным кодом и понятными связями с другими частями. Отдельный подпроект не обязательно является отдельным процессом, сервером или устанавливаемой программой.

Ниже зафиксирована предлагаемая структура для дальнейшей реализации. Для проектов карт подготовлен каталог maps с правилами размещения. В maps/zumTradeMap сохранён snapshot существующего проекта с manifest происхождения. Адаптация к Atlas ещё не выполнена. Стек и порядок реализации описаны в технической архитектуре и docs/TASKS.md.

Основные подпроекты

Подпроект	Каталог	Ответственность
Сервер платформы	apps/server	Клиенты, пользователи, права, карты, хранение материалов, черновики, проверки и публикации. Реестр стендов, централизованные настройки, доставка команд и приём состояния. Обслуживание обеих админок, установочных пакетов и обновлений. Подключение серверных функций конкретных реализаций карт.
Админка OK24	apps/admin	Управление клиентами, картами, доступами и обслуживанием. Первичная подготовка карты, действия поддержки и управление стендами в рамках полномочий OK24.
Кабинет клиента	apps/client	Работа со своими картами, сотрудниками, содержанием и публикациями. Список подключённых столов, настройки показа, состояние, перезапуск приложения и перезагрузка ПК.
Редактор карты	modules/map-editor	Визуальное редактирование содержания и геометрии помещений, расширение, объединение, привязки объектов, предпросмотр и выявление затронутых маршрутов. Используется внутри обеих админок с соответствующими правами; отдельный сайт для редактора не требуется.
Проект карты zumTradeMap	maps/zumTradeMap	Существующий проект zumTradeMap: HTML/CSS/JS-интерфейс, SVG всех этажей и специфичное поведение текущей карты — поиск, категории, карточки, реклама, экранная клавиатура и готовые маршруты. Сохраняет своё имя и возможности, минимально адаптируется к платформе.
Приложение стенда	apps/kiosk	Обязательное устанавливаемое приложение для Windows. Запускает нужную реализацию карты, применяет параметры показа, загружает совместимую опубликованную версию. Включает компонент управления устройством и скрипты настройки ОС в поставку.
Управление устройством и настройка ОС	modules/device-agent	Отдельный канал настроек, команд и состояния. Первичная привязка стенда, синхронизация параметров, выполнение разрешённых команд, перезапуск приложения и перезагрузка ПК, скрипты настройки Windows. Сообщает серверу результаты и фактическое состояние.

Структура исходников

OK24-Atlas/
├── apps/
│   ├── server/
│   ├── admin/
│   ├── client/
│   └── kiosk/
├── modules/
│   ├── map-editor/
│   ├── device-agent/
│   │   └── windows/
│   └── contracts/
├── maps/
│   ├── README.md
│   ├── zumTradeMap/
│   └── <имя-другого-проекта>/
├── apps/server/deployment/
└── docs/

maps — общая область проектов карт. zumTradeMap — первый самостоятельный проект внутри этой области. <имя-другого-проекта> обозначает место в схеме для будущих проектов, а не уже существующую карту или буквальное имя каталога.

Служебные области:

• apps/server/contracts — общие определения форматов карты и публикации, настроек стенда, команд, результатов и совместимости версий. Позволяют частям продукта одинаково понимать передаваемые данные; способ их описания будет выбран со стеком.
• apps/server/deployment — описание и автоматизация развёртывания сервера, сборки и выпуска приложений. Скрипты настройки ОС конкретного стенда относятся к device-agent и включаются в установочную поставку.
• docs — продуктовая архитектура, договорённости между подпроектами, инструкции по выпуску, подключению и обслуживанию стендов.

Рабочие загрузки клиентов, их учётные данные, состояния стендов и опубликованные версии хранятся средствами сервера. Наличие единого Git-репозитория не означает хранение всей эксплуатационной информации в Git. Исходные материалы существующей карты используются для её первоначального подключения.

Связи и границы ответственности

1. Обе админки → сервер. Сервер проверяет права и принадлежность данных клиенту; интерфейсы работают в рамках этих прав.
2. Обе админки → редактор → сервер. Общий редактор встраивается в нужный кабинет, получает возможности выбранной реализации карты и сохраняет изменения в черновик. Итоговые проверки и публикация выполняются сервером.
3. Сервер → приложение стенда → реализация карты. На устройство поступает опубликованная версия, а приложение показывает её с помощью совместимой реализации карты.
4. Кабинет → сервер ↔ компонент управления устройством. По этому пути передаются настройки, команды и состояние. Изменение параметров стенда не требует редактирования или публикации SVG.
5. Компонент управления устройством → приложение и ОС. Применяет настройки и выполняет предусмотренные команды. Системные действия не должны зависеть от открытой карточки магазина или работоспособности слоя отображения карты. Как обеспечить перезапуск и восстановление при сбое приложения на Windows, определим при выборе технологии; отдельная системная служба заранее не предполагается.
6. Реализация карты ↔ серверные функции. Текущая карта сохраняет существующее поведение. Будущая реализация сможет запрашивать серверный расчёт маршрута и другие функции через согласованные интерфейсы.

В первом выпуске device-agent входит в состав поставки приложения стенда. Выделение в подпроект нужно для ответственности за управление и системные функции Windows; пользователю не предлагается вручную устанавливать ещё один самостоятельный продукт.

Как добавляются будущие карты и функции

• Каждый новый проект карты получает собственный каталог maps/<имя-проекта> рядом с maps/zumTradeMap. Он может иметь собственный интерфейс, ресурсы, формат редактирования и специфичные серверные модули, подключаемые к платформе. В первом выпуске переносится и подключается только существующий проект zumTradeMap.
• Новые проекты находятся в том же Git-репозитории OK24-Atlas. У каждого описываются назначение, поддерживаемые возможности и точки подключения к серверу, редактору и приложению стенда. Общие функции платформы остаются в общих подпроектах.
• Проект реализации и экземпляр карты клиента — разные понятия: несколько клиентских карт могут использовать одну реализацию с разными данными. Новый клиент сам по себе не требует копировать zumTradeMap или создавать новый проект.
• Возможности редактора и форматы публикации привязываются к реализации карты. Общий редактор не должен предполагать, что все будущие карты имеют ту же структуру SVG, что текущая.
• Серверная навигация при появлении требований может быть выделена в модуль сервера или отдельный подпроект внутри этого же репозитория. Сейчас не создаём неиспользуемую службу расчёта маршрутов.
• Общие клиенты, доступы, управление стендами и история публикаций продолжают обслуживаться платформой.

Что означает единый репозиторий для выпусков

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

16. Решения для следующего обсуждения

• Какие дополнительные операции с помещениями нужны помимо изменения границ, расширения и объединения: разделение, создание новых помещений, перемещение входов?
• Какие слои и области разрешено изменять клиенту, а какие защищены?
• Как назначаются арендатор и вход при объединении и кто подтверждает пригодность затронутых маршрутов?
• Нужны ли терминалы без интернета уже при запуске?
• Какие настройки ОС выполняют скрипты приложения на Windows и в какие моменты: установка, запуск или обновление ПО?
• Какие дополнительные инструменты управления стендами нужны помимо настройки показа, перезапуска приложения и перезагрузки ПК?
• Какие сведения и рекламные возможности обязательны для первого клиента?

Согласованные границы: исходные карты создаёт OK24; клиент редактирует содержание и геометрию подготовленных помещений; первый выпуск сохраняет текущую карту и работает только в обязательном устанавливаемом приложении на стендах Windows. Приложение включает скрипты настройки целевой ОС. Дальше можно детализировать редактор, выбрать стек, организацию данных, формат публикации и механизмы установки и настройки ОС, сохраняя возможность будущих серверных функций.