Plugin Loader (загрузчик плагинов)

Обнаружение, регистрация и экспорт плагинов в Runtime. Архитектура без реализации.

Plugin Loader — подсистема Runtime, которая при старте превращает установленные плагины в доступные JS API. Цель — нулевая ручная регистрация: разработчик не редактирует нативные конфиги, всё происходит автоматически из манифестов (главное улучшение относительно Cordova).

1. Где проходит граница «build-time» и «runtime»

Регистрация плагинов делится на два момента:

• Во время сборки (build-time): Build System собирает список плагинов из конфига и манифестов, генерирует нативный «реестр» (какие плагины линкуются и регистрируются) и включает их нативные зависимости. Это безопаснее и быстрее, чем динамическая загрузка кода на устройстве.
• Во время старта (runtime): Plugin Loader инстанцирует зарегистрированные плагины, проверяет совместимость и публикует их API в Bridge/WebView.

Решение «статическая регистрация на сборке + инициализация на старте» (а не загрузка произвольного нативного кода в рантайме) принято ради безопасности и предсказуемости — см. ADR-003.

2. Поток обнаружения и регистрации (старт Runtime)

1. Runtime стартует, поднимает Bridge(native).
2. Loader читает встроенный реестр плагинов (сгенерирован на сборке из манифестов).
3. Для каждого плагина:
   a. проверить совместимость (версия Runtime, протокол моста, версия ОС, движок);
   b. при несовместимости — пропустить + залогировать понятную ошибку (Runtime не падает);
   c. инстанцировать нативный объект плагина;
   d. зарегистрировать его методы/события в Plugin Manager (карта plugin.method → обработчик).
4. Loader формирует JS-описание доступных плагинов и их методов/событий.
5. Bridge(JS) инъектируется в WebView ДО загрузки приложения, публикуя:
      window.Aurobore.<Plugin>.<method>()   и реестр window.Aurobore.__plugins
6. Веб-приложение загружается; SDK использует опубликованные обёртки.

3. Plugin Manager (реестр в Runtime)

• Хранит карту (*plugin*, *method*) → обработчик и список эмитируемых событий.
• Маршрутизирует входящие invoke-сообщения в нужный метод нужного плагина.
• Изолирует ошибки: исключение в плагине → структурированная ошибка моста, без падения Runtime.
• Управляет жизненным циклом плагинов (init/teardown, реакция на lifecycle-события приложения).

4. Экспорт API в JS

• На JS-стороне публикуется объект Aurobore с пространствами имён плагинов: Aurobore.Camera.getPhoto(...), Aurobore.Geolocation.watch(...) и т.д.
• Эти «голые» обёртки — низкоуровневый слой; типизированный публичный доступ даёт TypeScript SDK (@aurobore/*), который опирается на тот же реестр.
• Реестр доступных плагинов/методов доступен для интроспекции (полезно для DevTools и диагностики).

5. Обработка несовместимости и ошибок

Ситуация	Поведение
Версия плагина несовместима с Runtime/протоколом	Плагин не регистрируется, лог + диагностика; приложение работает без него
Нет нужного разрешения/области	Регистрация возможна, но вызовы отклоняются мостом с ошибкой *_PERMISSION_DENIED
Возможность недоступна на данном устройстве/версии	Метод доступен, но возвращает *_UNAVAILABLE
Сбой инициализации плагина	Плагин помечается недоступным, ошибка логируется, Runtime продолжает работу

6. Диагностика

• Loader предоставляет данные для aurobore doctor и DevTools: список плагинов, их версии, статус регистрации, причины пропуска.

7. Связи

• ↔ Plugin System — модель и манифесты плагинов.
• ↔ Bridge — публикация и маршрутизация.
• ↔ Build System — генерация реестра и включение нативных зависимостей.
• ↔ Runtime — владелец загрузчика.