Назначение: Контракт. Продукт: ShariX Open · Общий компонент.

Для кого: Разработчик · Интегратор · Оператор развёртывания · Администратор · Поддержка · Нейросеть.

Темы: Модули → Доступность · Эксплуатация → Диагностика · Архитектура → Границы.

Для возможности ShariX Open проверяются разные факты:

1. Известен конкретный модуль/provider и его назначение.
2. Исходники получены из ожидаемого репозитория/ветки; известна фактическая лицензия.
3. Checkout существует, модуль выбран конфигурацией и реально загружен текущим Django-процессом.
4. Для защищённой операции выполнены применимые условия entitlement.
5. Настройки/схема/dependencies готовы, проверка health подтверждает нужный уровень работы.

Положительный import test не заменяет эти пункты. Публичность репозитория не является лицензией, а entitlement не является Git credential.

Sysadmin владеет module metadata/lifecycle/health и решением о разрешённых protected capabilities. Onboarding связывает предметную потребность с возможными реализациями: базовой, установленным модулем, доступным для установки вариантом, custom external либо defer.

Не создавайте в onboarding второй каталог лицензий и репозиториев. Его semantic mapping читает descriptive metadata из canonical Sysadmin projection.

• BASE — предусмотренная базовая реализация.
• INSTALLED — модульная реализация уже установлена по текущей проверке.
• PUBLIC_INSTALLABLE / PRIVATE_AVAILABLE — доступный вариант подключения, который ещё не равен рабочему runtime.
• PRIVATE_UNAVAILABLE / UNAVAILABLE — нужная реализация сейчас недоступна с указанной причиной.
• CUSTOM_EXTERNAL — явно выбранная внешняя/собственная реализация.
• DECLINED — возможность отложена/не выбрана в данном проекте по его решению.

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

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

• Отказ не должен удалять данные или отключать несвязанные приложения.
• Источники online/offline authorization и пределы выданного разрешения проверяются штатным resolver.
• Секреты доступа к Git/API не записываются в проектный manifest или Wiki.
• Внутренний выпуск/управление закрытыми разрешениями описывается ответственными во внутренней документации.

Sysadmin различает source/config/runtime, restart_required, materialization_staged/failed и результат module probe. Если target-specific setup прошёл, но полная сборка заблокирована другим модулем, это не готовый runtime. Отсутствующий sharix_health.py даёт generic-проверку, а не доказательство всех внешних интеграций.

1. Проверьте canonical metadata и выбранную реализацию.
2. Прочитайте причину недоступности и границы fallback.
3. Установку/включение проводите штатной панелью модулей и installer, затем проверьте текущий процесс.
4. В нужных условиях выполните live health отдельно от статической проверки.

Общий компонент может применяться и на Platform; его изменение передаётся ответственному Platform для проверки и принятия. Это не инструкция обновлять другую установку из публичного workflow.

Проверено по Git-исходникам 31.10.2026. Состояние исходников отделено от состояния конкретной установки; команды ниже при редакционной проверке не выполнялись, бизнес-данные и значения секретов не читались.

• sharix-open-sysadmin / services/modules_catalog.py.
• sharix-open-sysadmin / services/module_health.py.
• sharix-open-sysadmin / services/proprietary_capabilities.py.
• sharix-open-sysadmin / services/module_runtime_state.py.
• sharix-open-onboarding / services/capabilities.py.
• sharix-open-onboarding / services/contributions.py.