earer":  [

               ]
}
[securitySchemes]
{
    "Bearer":  {
                   "type":  "apiKey",
                   "description":  "JWT Authorization header using the Bearer scheme. \\r\\n\\r\\n \r\n                      Enter \u0027Bearer\u0027 [space] and then your token in the text input below.\r\n                      \\r\\n\\r\\nExample: \u0027Bearer 12345abcdef\u0027",
                   "name":  "Authorization",
                   "in":  "header"
               }
}

[component-base-app/src/main/java/com/wakakiosk/apps/presentation/splash/SplashInteractor.kt]
48:fun fetchStandSettings(): Completable {
66:private fun loadData(): Completable {
81:wearableManager.get().updateUsersWearables()
120:miniAppManager.get().getOrDownload(wearable.userId, request)
[component-base-app/src/main/java/com/wakakiosk/apps/data/managers/WearableManagerImpl.kt]
82:override fun updateUsersWearables(): Completable {
[component-base-app/src/main/java/com/wakakiosk/apps/domain/
… 230 chars omitted, open in editor for full output …
g, request: MiniAppRequest): Single<MiniAppSpec> {
[component-base-app/src/main/java/com/wakakiosk/apps/infrastructure/settings/StandSettings.kt]
5:class StandSettings(
[component-base-app/src/main/java/com/wakakiosk/apps/di/modules/KioskApiModule.kt]
25:fun provideKioskApiUrl(): String = PLACEHOLDER_BASE_URL
29:fun provideKioskTokenProvider(): KioskTokenProvider = KioskTokenProvider.NONE
[component-base-app/src/main/java/com/wakakiosk/apps/data/db/AppDatabase.kt]
52:const val VERSION = 43

Исследование завершено. Главный вывод: миграция должна идти как замена bootstrap-модели, а не как механическая подмена Retrofit API; административные endpoints (Users, Roles, TerminalProfiles и подобные) в Android runtime, вероятно, вообще не нужны. Сейчас оформляю этапы, контрольные точки и список контрактных вопросов.
Код не менял. Новый API не является прямой заменой старого: текущий runtime построен вокруг user → wearable → product, новый — вокруг terminal → profile → package.
План миграции
1.
Зафиксировать, какие старые сценарии должен заменить Kiosk API: активацию, авторизацию, продукты, mini-app, лицензии.
2.
Составить таблицу соответствия старых API новым endpoints. Административные Users, Roles, Terminals не подключать к runtime без необходимости.
3.
Дополнить stand-конфигурацию URL нового сервера и переключателем legacy/kiosk. Убрать placeholder из KioskApiModule.kt.
4.
Реализовать хранение идентификатора терминала, hardware code, JWT и состояния активации. Токен хранить отдельно от пользовательских OAuth-токенов.
5.
Описать процесс первой активации через Devices/activate, повторной активации и обработки 401/403.
6.
Добавить доменный слой нового протокола: TerminalRepository, TerminalSession, PackageRepository, HeartbeatManager. DTO не передавать напрямую в presentation.
7.
Определить новую локальную модель пакета. Не встраивать её искусственно в существующие UserEntity, WearableEntity и ProductEntity.
8.
Реализовать скачивание пакета через Devices/package/{platform}: временный файл, проверка checksum, безопасная распаковка, атомарная установка и откат на предыдущую версию.
9.
Определить преобразование package manifest в текущие понятия приложения: BOOT-продукт, пункты меню, права JS bridge, indexPage, сервисы и версии.
10.
Добавить новый вариант загрузки данных в SplashInteractor.kt, оставив старый WearableManager за переключателем.
11.
Перевести загрузку mini-app на установленный Kiosk package либо добавить адаптер над существующим MiniAppManagerImpl.kt.
12.
Реализовать heartbeat: при запуске, после установки пакета и периодически. Обработать needUpdate, потерю сети и блокировку терминала.
13.
Сохранить offline-запуск последней валидной версии пакета. Не удалять рабочую версию при ошибке обновления.
14.
Провести пилот на одном приложении/стенде, затем включить протокол отдельно для app-beta-apps, app-wakakiosk-beta и app-wakakiosk-beta-rf.
15.
После стабилизации удалить старые API, Wearable/Product bootstrap и совместимый слой отдельным этапом.
16.
Проверить unit-тестами активацию, токен, heartbeat, checksum, распаковку и откат; затем собрать все три приложения и выполнить gradlew test.
Нужны ответы
1.
Новый API заменяет весь Cedar/Auth функционал или только активацию терминала и доставку пакета?
2.
Что находится внутри package? Нужен пример архива и описание manifest.
3.
Как приложение получает terminalId, PIN и hwCode?
4.
Какой срок жизни JWT и предусмотрено ли его обновление?
5.
Какие значения допустимы для platform, и какой алгоритм используется для checksum?
6.
Каков формат deviceStatuses и требуемая частота heartbeat?
7.
api/auth/login предназначен для Android-клиента или только для административного интерфейса?
8.
С какого приложения начинать пилот?