Подготовить HY2XS к production-сборке
This commit is contained in:
@@ -0,0 +1,46 @@
|
||||
# Client and access scope
|
||||
|
||||
## Цель документа
|
||||
|
||||
Зафиксировать, что клиентский delivery/access layer не является частью install baseline.
|
||||
|
||||
## Что входит в baseline
|
||||
|
||||
В baseline этого пакета docs входит только следующее:
|
||||
- установка Hysteria2
|
||||
- установка HY2XS admin
|
||||
- базовая настройка systemd / firewall / `post-install.env`
|
||||
- подготовка рабочего серверного окружения
|
||||
|
||||
## Что не входит в baseline
|
||||
|
||||
В baseline **не входят**:
|
||||
- Telegram-бот
|
||||
- backend выдачи профилей
|
||||
- remote profile publishing
|
||||
- deep links
|
||||
- billing / подписки / тарифные планы
|
||||
- отдельный user-access API
|
||||
|
||||
## Что допускается как вспомогательный слой
|
||||
|
||||
Для smoke/manual testing могут существовать:
|
||||
- тестовый клиентский конфиг
|
||||
- тестовый URI
|
||||
- отдельные примеры импортируемых клиентских артефактов
|
||||
|
||||
Но это не делает access layer частью install baseline.
|
||||
|
||||
## Почему это важно
|
||||
|
||||
Если смешать install baseline и delivery layer, документация начинает неверно обещать лишнее:
|
||||
- будто оркестратор обязан выдавать ключи пользователям
|
||||
- будто сервер после установки автоматически включает пользовательский backend
|
||||
- будто Telegram-бот является обязательной частью системы
|
||||
|
||||
Это неверно.
|
||||
|
||||
## Правильная формулировка
|
||||
|
||||
После выполнения install flow система должна быть готова как серверное окружение HY2XS.
|
||||
Как именно оператор потом выдаёт доступ клиентам — отдельный продуктовый контур и отдельная документация.
|
||||
Reference in New Issue
Block a user