homeserver: рендейм subserver→homeserver, документ деривации ключей, запрет пустого пароля

Основное (наша работа в этой сессии):
- Переименование «subserver» → «homeserver» по всему проекту: основной ESP32-скетч
  (папка shine_subserver_ui → shine_homeserver_ui, .ino, flash-скрипт, режим burn.sh
  homeserver-ui), скетч lvgl_nav_minimal_test (ключ homeserver.key:<имя>), spec-доки
  reference/*, формат PDA (терминология session_type=100 «Homeserver пользователя»),
  константа SESSION_TYPE_HOMESERVER в JS и Rust (значение 100 не менялось, формат не затронут),
  pending/future доки, AGENTS.md, DAO-док. Сохранены отдельный lvgl_subserver_touch_test и
  историческая пометка о рендейме в DERIVATION.md.
- Новый источник истины по деривации ключей: Dev_Docs/Keys/DERIVATION.md (Argon2id-секрет из
  пароля, формула Ed25519(SHA-256(base64(secret)|suffix)), суффиксы root/bch/dev/homeserver.key,
  Solana-ключ = dev.key). Уточнены роли root (главный/master) и dev (пополняемый кошелёк) в
  Dev_Docs/Keys/README.md.
- UI: убран легаси-путь пустого пароля (derivePasswordSeed и др.), deriveMasterSecretFromPassword
  бросает ошибку на пустом пароле, register-view блокирует пустой пароль; экран пополнения
  переведён на канонический device-адрес из preGeneratedKeyBundle (удалён расходящийся
  deriveWalletFromPassword).

Включены также параллельные правки Solana-аудита №3 (были в рабочем дереве, переплетены в lib.rs):
- shine_users: defense-in-depth «строгий список аккаунтов» (require!(it.next().is_none()))
  в init/update economy config и create/update user PDA, плюс описание в doc/programs/shine_users.md;
- Dev_Docs/audit/Solana-audit-3-by-Claude-12июня2026.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Dev_Docs/Future_Features/README.md

@@ -37,7 +37,7 @@
 - `medium/2026-05-25_1106_shine_balance_wallet.md` - кошелёк и пополнение баланса сияния через блокчейн.
 - `medium/2026-05-26_0029_esp32s3_file_storage.md` - ESP32S3 как личное файловое хранилище SHiNE для файлов переписок и вложений.
 - `medium/2026-06-03_подключение_других_устройств_через_qr.md` - довести подключение других устройств через QR: сейчас заготовка есть, но сценарий работает нестабильно и его нужно будет отдельно доделать.
-- `medium/2026-06-02_сессионные_саб_серверы_в_pda.md` - несколько саб-серверов пользователя как типизированные сессии в PDA с версией записи.
+- `medium/2026-06-02_сессионные_homeserver_в_pda.md` - несколько homeserver-ов пользователя как типизированные сессии в PDA с версией записи.
 
 ### DAO-запуск
 

Dev_Docs/Future_Features/medium/2026-06-02_сессионные_homeserver_в_pda.md

@@ -1,4 +1,4 @@
-# Сессионные саб-серверы в PDA пользователя
+# Сессионные homeserver-ы в PDA пользователя
 
 - Статус:
   `future`
@@ -10,15 +10,15 @@
   после завершения первого этапа по пользовательским сессиям
 
 - Основание:
-  Идея зафиксирована после обсуждения архитектуры пользовательских сессий и внутренних саб-серверов. Сейчас задача сознательно отложена: сначала нужно аккуратно ввести базовую модель сессий, а затем возвращаться к расширенной серверной роли.
+  Идея зафиксирована после обсуждения архитектуры пользовательских сессий и внутренних homeserver-ов. Сейчас задача сознательно отложена: сначала нужно аккуратно ввести базовую модель сессий, а затем возвращаться к расширенной серверной роли.
 
 ## Зачем нужна фича
 
-У одного пользователя может быть несколько доверенных внутренних саб-серверов, и каждый из них должен жить как отдельная пользовательская сессия, а не как отдельная особая сущность вне общей модели.
+У одного пользователя может быть несколько доверенных внутренних homeserver-ов, и каждый из них должен жить как отдельная пользовательская сессия, а не как отдельная особая сущность вне общей модели.
 
 Это нужно, чтобы:
 
-- хранить несколько саб-серверов у одного пользователя одновременно;
+- хранить несколько homeserver-ов у одного пользователя одновременно;
 - различать обычные клиентские сессии и серверные сессии по явному типу;
 - дать расширяемый формат записи с версией;
 - использовать единый подход для DM, звонков и внутренних команд между сессиями.
@@ -35,18 +35,18 @@
 Предварительные значения:
 
 - тип `1` - обычная пользовательская сессия;
-- тип `100` - саб-сервер пользователя;
+- тип `100` - homeserver пользователя;
 - версия `1` - первая рабочая версия формата записи сессии.
 
 На текущем этапе под это уже зарезервирован отдельный блок `SessionsBlock` с `block_type = 55`, а `TrustedStateBlock` остаётся на `50`.
 
-Важно: саб-серверов у одного пользователя может быть несколько.
+Важно: homeserver-ов у одного пользователя может быть несколько.
 
 ## Архитектурный принцип
 
 Внутренний протокол взаимодействия должен оставаться транспортным.
 
-То есть SHiNE-сервер не должен разбирать прикладной смысл внутренней нагрузки саб-сервера, а должен:
+То есть SHiNE-сервер не должен разбирать прикладной смысл внутренней нагрузки homeserver-а, а должен:
 
 - доставлять сообщения между сессиями;
 - доставлять сигналы звонков между сессиями;
@@ -60,7 +60,7 @@
 - Вызов звонка уже рассылается по нескольким активным сессиям пользователя.
 - Сигналы звонка уже адресуются конкретной сессии, а stop-сигналы дублируются на остальные сессии того же пользователя.
 
-Иными словами, текущая серверная логика ближе к модели "сервер доставляет между сессиями", чем к модели "сервер понимает внутренний протокол саб-сервера".
+Иными словами, текущая серверная логика ближе к модели "сервер доставляет между сессиями", чем к модели "сервер понимает внутренний протокол homeserver-а".
 
 ## Что нужно сделать при возврате к задаче
 
@@ -77,7 +77,7 @@
    - правила удаления и обновления записи;
    - правила ротации `sessionPubKey`.
 6. Продумать, как UI и сервер будут отличать тип `1` и тип `100`.
-7. Определить, какие внутренние сообщения саб-сервера останутся полностью прозрачными для SHiNE-сервера, а какие потребуют только технической маршрутизации.
+7. Определить, какие внутренние сообщения homeserver-а останутся полностью прозрачными для SHiNE-сервера, а какие потребуют только технической маршрутизации.
 8. Добавить API/операции чтения и обновления списка сессий, если для этого не хватит существующих механизмов.
 9. После реализации обязательно обновить документацию.
 
@@ -101,5 +101,5 @@
 Продолжать после завершения первой части:
 
 1. описать минимальный формат записи пользовательской сессии;
-2. отдельно решить, живут ли саб-серверы в том же списке, что и обычные сессии;
+2. отдельно решить, живут ли homeserver-ы в том же списке, что и обычные сессии;
 3. затем уже проектировать операции регистрации, обновления и отключения таких сессий.

Dev_Docs/Keys/DERIVATION.md

@@ -0,0 +1,154 @@
+# Деривация секрета и ключей SHiNE (формулы)
+
+> **Статус: ИСТОЧНИК ИСТИНЫ (single source of truth) по конкретной деривации.**
+> Этот файл описывает, как из пароля получается секрет и как из секрета выводятся
+> все ключи (root, blockchain, device/Solana, homeserver) — формулами, байт-в-байт.
+> Если в коде меняется деривация (формула секрета, параметры Argon2id, соль, формула
+> ключа, разделитель `|`, набор/имена суффиксов, формат homeserver-ключа, связь
+> dev-ключ ↔ Solana-адрес) — **в том же изменении обязательно править этот документ**.
+> Роли и назначение ключей описаны отдельно в `Dev_Docs/Keys/README.md` (архитектура).
+> Здесь — только механика. Документ намеренно краткий.
+
+---
+
+## 1. Секрет (masterSecret)
+
+`masterSecret` — 32 байта. Два источника:
+
+**А. Из пароля пользователя (основной путь, UI).**
+
+```
+login    = trim(lowercase(login))
+salt     = SHA-256("shine-auth-v2|login=" + login + "|suffix=master.secret")[0..16)   // первые 16 байт
+material = utf8(login + "\n" + password)
+masterSecret(32) = Argon2id(material, salt, t=2, m=65536 KiB, p=1, dkLen=32)
+```
+
+- Параметры Argon2id фиксированы: `t=2`, `m=65536` (64 МиБ), `p=1`, `dkLen=32`.
+- Логин входит и в соль, и в начало `material` (склейка через `\n`).
+- Пустой пароль **запрещён**: легаси-fallback без Argon2 удалён, `deriveMasterSecretFromPassword` бросает ошибку на пустом пароле, а форма регистрации в UI блокирует пустой пароль (`register-view.js`).
+
+**Б. Случайный (прошивка ESP32, новый аккаунт без пароля).**
+
+```
+masterSecret(32) = 32 случайных байта (esp_random)   // хранится на устройстве как base58
+```
+
+Дальше деривация ключей одинакова независимо от источника секрета.
+
+---
+
+## 2. Производные ключи
+
+Все ключи выводятся из `masterSecret` по **одной формуле**, отличается только суффикс:
+
+```
+material    = base64_std(masterSecret) + "|" + <суффикс>
+seed(32)    = SHA-256(material)
+(pub, priv) = Ed25519_keypair_from_seed(seed)
+```
+
+- `base64_std` — стандартный base64 (не url-safe).
+- Разделитель — символ `|`.
+- Суффиксы значимы байт-в-байт (регистр и точки важны).
+
+| Ключ | Суффикс | Назначение (кратко) |
+|------|---------|---------------------|
+| root | `root.key` | Личность. Подписывает unsigned-часть PDA-записи (`RootKeyBlock`). |
+| blockchain | `bch.key` | Подписывает `LastBlockState` персонального блокчейна (`blockchain_public_key`). |
+| device / **Solana** | `dev.key` | Ключ устройства = Solana-ключ. Fee payer и подпись Solana-транзакций; адрес кошелька = `base58(devicePub)`. См. §3. |
+| homeserver | `homeserver.key:<имя>` | Ключ homeserver-устройства, по одному на каждый homeserver (различитель — имя). См. §4. |
+
+Полные роли каждого ключа — в `Dev_Docs/Keys/README.md`.
+
+---
+
+## 3. Solana-ключ
+
+Отдельного «солана-ключа» нет. На Solana работают два ключа:
+
+- **`dev.key` (device) — пополняемый кошелёк и fee payer.** Solana-адрес = `base58(devicePub)`.
+  Этим ключом оплачиваются и подписываются `create_user_pda` / `update_user_pda`.
+  Пополнять SOL нужно именно на этот адрес.
+- **`root.key` — авторитет записи**, подписывает unsigned-часть PDA через Ed25519-инструкцию, но **не** является fee payer.
+
+Соответствует формату PDA `shine-solana/shine/doc/formats/shine-user-pda-format-v.1.0.md` §2.1
+(«create/update оплачиваются с `device_key`», «root_key — не fee payer»).
+
+Кратко про роли на Solana: `root.key` — это **главный (master) ключ**: им управляют PDA-записью
+(`create/update`) и через это можно заменить все остальные ключи; `dev.key` — это **пополняемый
+кошелёк и плательщик комиссий**. Полное описание ролей — `Dev_Docs/Keys/README.md`.
+
+---
+
+## 4. Ключи homeserver
+
+У пользователя может быть несколько homeserver-ов. Каждый имеет **своё имя** и **свой приватный ключ**,
+выведенный из секрета по той же формуле с именованным суффиксом:
+
+```
+suffix      = "homeserver.key:" + <имя homeserver>      // имя по умолчанию: "homeserver1"
+material    = base64_std(masterSecret) + "|" + suffix
+seed(32)    = SHA-256(material)
+(pub, priv) = Ed25519_keypair_from_seed(seed)
+```
+
+Пример для двух homeserver-ов:
+
+```
+homeserver.key:home-a   ->  ключ A
+homeserver.key:home-b   ->  ключ B
+```
+
+Публичный ключ homeserver-а публикуется в `SessionsBlock` пользовательской PDA как
+`session_pub_key` с `session_type = 100`, имя — в `session_name` (формат PDA §13).
+
+> Это переименование прежней схемы `subserver.key:<имя>` → `homeserver.key:<имя>`.
+> Термин «саб-сервер» по проекту заменяется на «homeserver».
+
+---
+
+## 5. Где это в коде
+
+### Деривация секрета и ключей (UI, каноническая)
+- `shine-UI/js/services/crypto-utils.js`
+  - секрет из пароля: `makeArgon2Salt`, `deriveMasterSecretArgon2id`, `deriveMasterSecretFromPassword` (~129–218);
+  - ключ из секрета: `deriveEd25519FromMasterSecret` (~220).
+- `shine-UI/js/services/auth-service.js` — набор root/bch/dev из `masterSecret` (~732–758).
+- `shine-UI/server-ui/js/server-ui-shared.js` — те же root/bch/dev для серверного UI (~147–160).
+
+### Solana-ключ / адрес кошелька (UI)
+- `shine-UI/js/pages/registration-payment-view.js` — `deriveUserWalletAddress`: адрес = `base58(devicePub)` (~113).
+- `shine-UI/js/pages/topup-view.js` — `deviceWalletAddressFromBundle`: тот же канонический адрес из `preGeneratedKeyBundle.devicePair`.
+  Прежний расходящийся путь `deriveWalletFromPassword` (прямой Argon2 по `dev.key`, мимо `masterSecret`) удалён.
+
+### Деривация ключей (прошивка ESP32)
+- `ESP32/esp32/ESP32-S3-Touch-AMOLED-2.16/test-device/shine_homeserver_ui/shine_homeserver_ui.ino`
+  - `deriveKeysFromMasterSecret` (~782), `restoreDerivedKeysFromSecret` (~806), `deriveFreshSecretAndWallet` (~829);
+  - регистрация/подпись Solana: `registerHomeserverOnSolana` (~1182), `signMessageEd25519` (~1147).
+- `ESP32/esp32/ESP32-S3-Touch-AMOLED-2.16/test-device/test_sketches/lvgl_nav_minimal_test/lvgl_nav_minimal_test.ino`
+  - homeserver-ключ: `homeserverKeySuffix` (~690), `deriveKeyPairFromSecretSuffix` (~699), `refreshDerivedKeys` (~725); суффикс `homeserver.key:<имя>`.
+
+### Формат PDA (куда попадают ключи)
+- `shine-solana/shine/doc/formats/shine-user-pda-format-v.1.0.md`
+  — `RootKeyBlock` §6, `DeviceKeyBlock` §7, `blockchain_public_key` §9, `SessionsBlock`/`session_type=100` §13, оплата §2.1.
+
+### Сервер (тестовый seed)
+- `SHiNE-server/src/test/java/test/it/cases/SeedDataPopulationHelper.java` `deriveKeysFromPassword` (~246) —
+  выводит ключи как `Ed25519(SHA-256(base64(SHA-256(password)) + suffix))`, **без** Argon2 и **без** разделителя `|`.
+  Это **не баг**, а точное повторение легаси-пути UI `derivePasswordSeed` (для пустого пароля), у которого тоже нет `|`.
+  С современным путём `masterSecret`-bundle (Argon2 + `base64(secret)|suffix`) он **не совпадает** by design.
+  Если потребуется, чтобы seed совпадал с реальными клиентами на Argon2 — нужно отдельно портировать
+  Argon2id+masterSecret в Java (на сервере Argon2 сейчас нет). Простое добавление `|` было бы **неверным**:
+  сломало бы совпадение с легаси-путём и всё равно не дало бы совпадения с Argon2-путём.
+
+---
+
+## 6. Правило синхронизации (обязательно)
+
+1. Этот документ — источник истины по деривации секрета и ключей.
+2. Любое изменение кода, затрагивающее формулу секрета, параметры Argon2id, соль, формулу ключа,
+   разделитель `|`, набор/имена суффиксов, формат homeserver-ключа или связь dev-ключ ↔ Solana-адрес —
+   **обязательно** отражать здесь в том же изменении.
+3. Пункты, помеченные ⚠️, — это долг к устранению, а не норма.
+4. Нельзя сознательно оставлять код и этот документ в рассинхроне без отдельной явной договорённости.

Dev_Docs/Keys/README.md

@@ -8,7 +8,7 @@
 
 В SHiNE у пользователя есть несколько уровней ключей:
 
-- `root key` - главный корневой ключ пользователя, он же основной Solana-ключ.
+- `root key` - главный (master) ключ пользователя: тот, кто им владеет, управляет пользовательской PDA в Solana и может заменить все остальные ключи. Это не пополняемый кошелёк (комиссии платит `device key`).
 - `blockchain key` - ключ записи в персональный SHiNE-блокчейн пользователя.
 - `device key` - общий ключ пользовательских устройств для повседневной работы, звонков, DM и мелких платежей.
 - `session key` - ключ конкретной сессии или конкретного устройства для авторизации на сервере.
@@ -28,9 +28,9 @@
 - управление остальными ключами;
 - подтверждение операций, которые должны иметь максимальный уровень доверия.
 
-В текущей модели `root key` совпадает по смыслу с главным Solana-ключом пользователя.
+`root key` — это **главный (master) ключ** в следующем смысле: зная `root key`, можно управлять пользовательской PDA-записью в Solana (`create_user_pda` / `update_user_pda`) и тем самым **заменить все остальные ключи** пользователя (device, blockchain, homeserver). Поэтому компрометация `root key` равносильна компрометации всей личности пользователя.
 
-На `root key` могут храниться значимые средства, если пользователь сознательно выбирает такую модель. Для мелких текущих расходов предпочтительнее использовать `device key`.
+Важно не путать авторитет и кошелёк: `root key` — это авторитет над PDA-записью, а **SOL-комиссии за create/update платит `device key`** (он же fee payer и адрес для пополнения). Подробнее о том, какой ключ за что отвечает на Solana, — в `Dev_Docs/Keys/DERIVATION.md`, §3.
 
 ## `blockchain key`
 
@@ -158,6 +158,7 @@ Self-message - это сообщение пользователя самому
 
 ## Связанные документы
 
+- `Dev_Docs/Keys/DERIVATION.md` - **источник истины по конкретной деривации** секрета и ключей (формулы Argon2id, `base64|suffix→SHA-256→Ed25519`, суффиксы `root.key`/`bch.key`/`dev.key`/`homeserver.key:<имя>`, Solana-ключ, ссылки на код).
 - `Dev_Docs/Personal_Messages/README.md` - текущая документация личных сообщений.
 - `Dev_Docs/Blockchain/README.md` - точка входа по форматам SHiNE-блокчейна.
 - `Dev_Docs/Solana_Architecture/README.md` - архитектура Solana-программ, PDA-счетов, DAO и движения средств.

Dev_Docs/Pending_Features/2026-06-07_1650_esp32_homeserver_ui_прототип.md

@@ -1,26 +1,26 @@
-# ESP32 UI-прототип сабсервера SHiNE
+# ESP32 UI-прототип homeserver SHiNE
 
 - краткое описание фичи:
-  для `Waveshare ESP32-S3-Touch-AMOLED-2.16` добавлен новый интерактивный UI-скетч сабсервера `SHiNE` с хранением данных в `NVS`, настройками `Wi-Fi`, настройками серверов, кошельком, экраном `QR/URI`, живой Solana-регистрацией и экраном входящих запросов. Логика PIN в коде сохранена, но вход по PIN во временной сборке отключён, чтобы не блокировать проверку остальных экранов. В текущей версии `Wi-Fi` подключается реально, адреса `API/RPC/WS` проверяются реально, баланс кошелька читается из `Solana RPC`, а регистрация отправляет `create_user_pda` в `shine_users`.
+  для `Waveshare ESP32-S3-Touch-AMOLED-2.16` добавлен новый интерактивный UI-скетч homeserver `SHiNE` с хранением данных в `NVS`, настройками `Wi-Fi`, настройками серверов, кошельком, экраном `QR/URI`, живой Solana-регистрацией и экраном входящих запросов. Логика PIN в коде сохранена, но вход по PIN во временной сборке отключён, чтобы не блокировать проверку остальных экранов. В текущей версии `Wi-Fi` подключается реально, адреса `API/RPC/WS` проверяются реально, баланс кошелька читается из `Solana RPC`, а регистрация отправляет `create_user_pda` в `shine_users`.
 
 - что именно проверять:
-  1. Прошить режим `subserver-ui` и дождаться открытия главного экрана без PIN.
+  1. Прошить режим `homeserver-ui` и дождаться открытия главного экрана без PIN.
   2. Проверить, что текст в заголовках, кнопках и статусах отображается читаемо; в текущей временной сборке допускается ASCII-транслитерация русского текста.
   3. Открыть `Настройки` и убедиться, что показывается пометка о временно отключённом входе по PIN.
   4. Открыть `Подключение -> Wi-Fi`, ввести `SSID` и пароль, нажать `Проверить`, дождаться реального подключения, затем перезагрузить устройство и проверить, что значения сохранились.
   5. Открыть `Подключение -> Серверы`, проверить или изменить `API/RPC/WS`, нажать `Проверить` и убедиться, что показываются реальные статусы доступности, затем перезагрузить устройство и проверить сохранение значений.
-  6. Открыть `Аккаунт`, ввести логин, имя сабсервера и нажать `Сгенерировать`; проверить, что появились секрет и адрес кошелька, а после перезагрузки они не исчезают.
+  6. Открыть `Аккаунт`, ввести логин, имя homeserver и нажать `Сгенерировать`; проверить, что появились секрет и адрес кошелька, а после перезагрузки они не исчезают.
   7. Открыть `Кошелёк`, нажать `Проверить` и убедиться, что баланс реально читается из `Solana RPC`; затем открыть `QR и URI` и проверить, что QR-код отрисовывается и сканируется как `solana:`-ссылка.
   8. При необходимости отдельно проверить тестовые кнопки `+/- SOL`: они меняют локальный баланс для UX-сценариев, но после следующей реальной RPC-проверки баланс должен вернуться к сетевому значению.
   9. Вернуться на главный экран и проверить, что до выполнения всех условий кнопка регистрации недоступна, а после выполнения становится доступной.
-  10. Выполнить регистрацию и убедиться, что статус меняется на `Сабсервер активен`, онлайн-статус становится активным, а на экране появляются краткие отпечатки `PDA/TX`.
+  10. Выполнить регистрацию и убедиться, что статус меняется на `Homeserver активен`, онлайн-статус становится активным, а на экране появляются краткие отпечатки `PDA/TX`.
   11. После регистрации проверить через `Solana`/UI проекта, что `user_pda` для этого логина реально создана и соответствует `device`-адресу устройства.
   12. Открыть `Запросы`, поочерёдно открыть оба демонстрационных запроса и проверить, что кнопки `Разрешить` и `Отклонить` меняют их статус.
   13. При необходимости открыть `Настройки -> Сменить PIN` и убедиться, что новый PIN сохраняется, хотя вход по PIN временно не используется на старте.
   14. Выполнить `Полный сброс` и убедиться, что все поля, секрет, баланс, онлайн и регистрация очищаются.
 
 - ожидаемый результат:
-  новый `ESP32`-скетч стабильно запускается, показывает читаемый интерфейс хотя бы в ASCII-транслитерации, сохраняет данные во внутренней памяти устройства, реально подключается к `Wi-Fi`, реально проверяет `API/RPC/WS`, реально читает баланс из `Solana RPC`, рисует рабочий `QR` для `solana:`-URI и позволяет вручную пройти полный сценарий on-chain регистрации сабсервера.
+  новый `ESP32`-скетч стабильно запускается, показывает читаемый интерфейс хотя бы в ASCII-транслитерации, сохраняет данные во внутренней памяти устройства, реально подключается к `Wi-Fi`, реально проверяет `API/RPC/WS`, реально читает баланс из `Solana RPC`, рисует рабочий `QR` для `solana:`-URI и позволяет вручную пройти полный сценарий on-chain регистрации homeserver.
 
 - статус:
   pending

Dev_Docs/Pending_Features/2026-06-08_1150_esp32_auto_flash_script.md

@@ -1,13 +1,13 @@
-# ESP32 авто-прошивка shine_subserver_ui
+# ESP32 авто-прошивка shine_homeserver_ui
 
 - краткое описание фичи:
-  добавлен исполняемый скрипт `flash_shine_subserver_ui.sh`, который автоматически ищет USB-порт `ESP32` и запускает заливку прошивки `shine_subserver_ui` без ручного указания `PORT`.
+  добавлен исполняемый скрипт `flash_shine_homeserver_ui.sh`, который автоматически ищет USB-порт `ESP32` и запускает заливку прошивки `shine_homeserver_ui` без ручного указания `PORT`.
 - что именно проверять:
   1. Подключить плату `ESP32` по USB.
   2. Перейти в папку `ESP32/esp32/ESP32-S3-Touch-AMOLED-2.16/test-device/`.
-  3. Запустить `./flash_shine_subserver_ui.sh`.
+  3. Запустить `./flash_shine_homeserver_ui.sh`.
   4. Убедиться, что скрипт сам показывает найденный порт и успешно запускает compile/upload.
 - ожидаемый результат:
-  скрипт без ручного ввода порта находит `ESP32`, печатает найденный `/dev/ttyACM*` или `/dev/ttyUSB*` и заливает `shine_subserver_ui`.
+  скрипт без ручного ввода порта находит `ESP32`, печатает найденный `/dev/ttyACM*` или `/dev/ttyUSB*` и заливает `shine_homeserver_ui`.
 - статус:
   pending

Dev_Docs/Pending_Features/2026-06-08_1245_esp32_pin_button_labels.md

@@ -1,7 +1,7 @@
 # ESP32 PIN-клавиатура: подписи кнопок
 
 - краткое описание фичи:
-  в UI-скетче `shine_subserver_ui` изменена отрисовка подписей кнопок. Вместо малого шрифта теперь используется более стабильный шрифт с явным центрированием текста внутри кнопок, чтобы на экране ввода PIN и других экранах не пропадали цифры и надписи.
+  в UI-скетче `shine_homeserver_ui` изменена отрисовка подписей кнопок. Вместо малого шрифта теперь используется более стабильный шрифт с явным центрированием текста внутри кнопок, чтобы на экране ввода PIN и других экранах не пропадали цифры и надписи.
 - что именно проверять:
   1. Включить устройство и дождаться экрана ввода PIN.
   2. Убедиться, что на всех серых кнопках видны цифры `0-9`, `Отмена` и `OK`.

Dev_Docs/Pending_Features/2026-06-08_1315_esp32_test_sketches_folder.md

@@ -6,8 +6,8 @@
   1. Запустить `./burn.sh gfx-text-test` и убедиться, что прошивается тест текста из новой папки.
   2. Запустить `./burn.sh gfx-layout-test` и проверить нижние ряды кнопок.
   3. Запустить `./burn.sh lvgl-basic-test` и проверить, что `LVGL` показывает текст и кнопки.
-  4. Убедиться, что новая папка не мешает сборке `subserver-ui`.
+  4. Убедиться, что новая папка не мешает сборке `homeserver-ui`.
 - ожидаемый результат:
-  тестовые скетчи лежат отдельно от основного UI, шьются отдельными режимами и позволяют быстро проверять разные гипотезы по экрану без правок в `shine_subserver_ui`.
+  тестовые скетчи лежат отдельно от основного UI, шьются отдельными режимами и позволяют быстро проверять разные гипотезы по экрану без правок в `shine_homeserver_ui`.
 - статус:
   pending

Dev_Docs/Pending_Features/2026-06-08_1940_esp32_nav_minimal_test.md

@@ -1,9 +1,9 @@
 # ESP32 nav minimal test
 
-- Краткое описание: минимальный UI-прототип для сабсервера на базе `LVGL + subserver touch`, с Wi-Fi flow, серверными адресами и общим экраном редактирования текста.
+- Краткое описание: минимальный UI-прототип для homeserver на базе `LVGL + subserver touch`, с Wi-Fi flow, серверными адресами и общим экраном редактирования текста.
 - Что проверять:
   - стартует экран `HOME`;
-  - на `HOME` видны реальное значение сабсервера или `subserver not set`, реальное значение логина или `login not set`, при отсутствии секрета строка `secret not set`, а также `STATUS`, верхний правый блок с процентом батареи, иконкой батареи и индикатором Wi-Fi, кнопка баланса, строка `SHiNE: ...`, кнопка `SETTINGS` уменьшенной ширины у правого края и нижняя подпись `SHiNE subserver (v.0.18)`;
+  - на `HOME` видны реальное значение homeserver или `homeserver not set`, реальное значение логина или `login not set`, при отсутствии секрета строка `secret not set`, а также `STATUS`, верхний правый блок с процентом батареи, иконкой батареи и индикатором Wi-Fi, кнопка баланса, строка `SHiNE: ...`, кнопка `SETTINGS` уменьшенной ширины у правого края и нижняя подпись `SHiNE homeserver (v.0.18)`;
   - справа от строки логина виден индикатор статуса Solana-аккаунта:
     - зелёный, если ключи совпали;
     - красный, если mismatch;
@@ -19,9 +19,9 @@
     - `unavailable`
   - пока открыт `HOME`, статус сам обновляется без перехода на другие экраны;
   - баланс обновляется кнопкой по нажатию;
-  - если логин зарегистрирован и секрет/сабсервер заданы, устройство:
+  - если логин зарегистрирован и секрет/homeserver заданы, устройство:
     - читает `user_pda` через Solana RPC;
-    - сверяет `root`, `blockchain`, `device` и `subserver` session type `100`;
+    - сверяет `root`, `blockchain`, `device` и `homeserver` session type `100`;
     - поднимает WebSocket-сессию с сервером SHiNE;
     - шлёт `Ping` раз в минуту;
   - кнопка `SETTINGS` открывает `SETTINGS_MENU`;
@@ -54,7 +54,7 @@
   - визуальный курсор в поле ввода не показывается;
   - новые символы всегда дописываются только в конец строки;
   - основные 3 ряда клавиш и нижний служебный ряд стали выше;
-  - внизу остаётся отдельная тёмная полоса с версией `SHiNE subserver (v.0.18)`, а рамка клавиатурного блока заканчивается выше неё;
+  - внизу остаётся отдельная тёмная полоса с версией `SHiNE homeserver (v.0.18)`, а рамка клавиатурного блока заканчивается выше неё;
   - одно непрерывное касание вызывает не более одного действия кнопки;
   - скольжение пальцем по клавиатуре не нажимает подряд несколько клавиш;
   - медленный свайп по экрану не должен превращаться в случайное нажатие кнопки;
@@ -75,11 +75,11 @@
   - нажатие `Account` открывает `ACCOUNT_SCREEN`;
   - `ACCOUNT_SCREEN` показывает 3 кнопки:
     - `Login (<value|not set>)`
-    - `Subserver (<value|not set>)`
+    - `Homeserver (<value|not set>)`
     - `Secret (<*****|not set>)`
   - `Login` открывает общий экран редактирования и сохраняется в NVS;
-  - `Subserver` открывает промежуточный экран с `USE SUBSERVER1` и `EDIT MANUALLY`;
-  - `USE SUBSERVER1` возвращает стандартное значение `subserver1`;
+  - `Homeserver` открывает промежуточный экран с `USE HOMESERVER1` и `EDIT MANUALLY`;
+  - `USE HOMESERVER1` возвращает стандартное значение `homeserver1`;
   - `EDIT MANUALLY` открывает общий экран редактирования и сохраняет значение в NVS;
   - `Secret` теперь открывает меню секрета с показом секрета, ручным вводом и генерацией;
   - в `SHOW SECRET` показывается прокручиваемый список всех ключей:
@@ -90,15 +90,15 @@
     - `Blockchain key priv (base58)`
     - `Device key (base58)`
     - `Device key priv (base58)`
-    - `Subserver key (base58)`
-    - `Subserver key priv (base58)`
+    - `Homeserver key (base58)`
+    - `Homeserver key priv (base58)`
   - значения ключей показываются полными строками увеличенным шрифтом;
   - при смене `login` сохранённый секрет сбрасывается в `not set`;
   - во время генерации секрета есть `CANCEL` и подтверждение остановки;
   - при отмене генерации старый секрет, если он был, не должен теряться;
   - свайп вправо из внутренних экранов возвращает в `SETTINGS_MENU`;
-  - свайп вправо из `ACCOUNT_SUBSERVER_SCREEN` и `ACCOUNT_SECRET_SCREEN` возвращает в `ACCOUNT_SCREEN`;
+  - свайп вправо из `ACCOUNT_HOMESERVER_SCREEN` и `ACCOUNT_SECRET_SCREEN` возвращает в `ACCOUNT_SCREEN`;
   - если во время реального свайпа палец проходит по кнопке, это не должно открывать кнопку как обычный `click`.
 - Ожидаемый результат: новый скетч даёт чистый навигационный каркас и уже умеет настраивать Wi-Fi и серверные адреса на самой ESP32.
-- Дополнительно ожидается: `HOME` уже показывает реальный Solana/WS-статус сабсервера, а отсутствие пользователя в Solana заметно сразу без перехода в настройки.
+- Дополнительно ожидается: `HOME` уже показывает реальный Solana/WS-статус homeserver, а отсутствие пользователя в Solana заметно сразу без перехода в настройки.
 - Статус: pending

Dev_Docs/Solana/user_pda/README.md

@@ -90,7 +90,7 @@ UserPdaRecordV1
 | `3` | `BlockchainRegistryBlock` | Один или несколько блокчейнов пользователя. |
 | `30` | `ServerProfileBlock` | Серверные данные пользователя. |
 | `40` | `AccessServersBlock` | Серверы доступа/relay. |
-| `50` | `SessionsBlock` | Опубликованные пользовательские сессии и саб-серверы. |
+| `50` | `SessionsBlock` | Опубликованные пользовательские сессии и homeserver-ы. |
 | `70` | `TrustedStateBlock` | Счетчик trusted-связей. |
 | `255` | `ReservedBlock` | Зарезервировано, пока не используется. |
 
@@ -309,7 +309,7 @@ SessionRecord
 | Значение | Смысл |
 |----------|-------|
 | `1` | Обычная пользовательская сессия. |
-| `100` | Саб-сервер пользователя. |
+| `100` | Homeserver пользователя. |
 
 Правила:
 

Dev_Docs/audit/Solana-audit-3-by-Claude-12июня2026.md

@@ -0,0 +1,134 @@
+# Аудит безопасности Solana-программ SHiNE — выпуск 3 (12.06.2026)
+
+Тематический аудит с фокусом на **полноту проверок входных аккаунтов**
+(signer / owner / каноничный PDA-адрес / system-program / sysvar инструкций /
+аккаунт оракула) — отвечает на вопрос «точно ли хватает всех проверок входных
+аккаунтов». Код перечитан целиком после исправлений аудита №2
+(`Solana-audit-2-by-Claude-11июня2026.md`):
+
+- `shine_login_guard` (183 строки) — stateless-классификатор логинов, аккаунтами не пользуется;
+- `shine_users` (1068 строк) — реестр пользователей, PDA-записи, ed25519-подписи, экономика лимитов;
+- `shine_payments` (1398 строк) — очереди тикетов, выплаты из вольта, оракул Pyth.
+
+Это ручная (не-Anchor `#[derive(Accounts)]`) реализация на `solana_program`, поэтому
+каждая проверка аккаунта выполняется явно в коде handler-а. Перебраны: подмена
+аккаунтов/PDA, подмена владельца, bump-seed атаки, отсутствие signer/authority,
+подмена system-program и sysvar, подмена аккаунта оракула, неинициализированные/
+повторно инициализируемые PDA, «лишние» аккаунты.
+
+## Итоговый вердикт
+
+**Проверок входных аккаунтов достаточно во всех трёх программах.** По каждому
+handler присутствуют все требуемые классы проверок; грубых дыр (подмена PDA на
+чужой аккаунт, отсутствие owner/signer-проверки, использование пользовательского
+bump, подмена аккаунта оракула) не найдено. Все Critical/HIGH из аудитов №1 и №2
+закрыты и в этом проходе подтверждены в коде. Новых эксплуатируемых пробелов в
+валидации аккаунтов нет; есть несколько LOW/INFO-замечаний «by design».
+
+## Статус прошлых находок (подтверждено в коде на 12.06.2026)
+
+- 🔴 Critical #1 (economy-config PDA, `shine_users`) — закрыто: `validate_users_economy_config_pda` (адрес + `owner == program_id`) вызывается и в create, и в update перед чтением.
+- 🔴 Critical #2 (singleton-PDA, `shine_payments`) — закрыто: `validate_singleton_state_pda` (адрес + `owner == id()`) во всех инструкциях.
+- 🟠 Medium (валидация Pyth) — закрыто: пин адреса `PYTH_SOL_USD_ACCOUNT`, `owner == pyth_receiver`, `PriceUpdateV2`, `feed_id`, возраст, доверительный интервал.
+- 🟡 Low (griefing на предсказуемых адресах) — закрыто: `create_pda_account` создаёт «поверх предзаполненного» в обеих программах.
+- 🔴 HIGH аудита №2 (`recipient_wallet == inflow_vault` замораживает выплаты) — закрыто: запрет `recipient == inflow_vault` в `buy_ticket_by_purchase_usd` (стр. 1026), `process_manager_add_ticket` (стр. 747), `process_change_ticket_recipient` (стр. 878) + защита по умолчанию `require!(vault.key != recipient.key)` в `transfer_from_vault` (стр. 1278).
+
+---
+
+## Матрица проверок входных аккаунтов
+
+### shine_users
+
+| Инструкция | signer | owner PDA | адрес/seed PDA | system | sysvar / подпись | прочее |
+|---|---|---|---|---|---|---|
+| `init_users_economy_config` | ✓ | `owner == system` + `data_is_empty` (анти-reinit) | деривация + сверка | ✓ | — | значения из `settings`, не из ввода |
+| `update_users_economy_config` | ✓ + `signer == DAO_AUTHORITY` | `owner == program_id` | деривация + сверка | — | — | `lamports_per_limit_step > 0` |
+| `create_user_pda` | ✓ + `signer == device_key` | user_pda `owner == system` + empty; econ_config `owner == program_id` | user_pda, econ_config, inflow_vault, login_guard — все сверены | ✓ | ed25519 (record sig idx −2, last_block idx −1) | `inflow_vault` сверен с PDA `shine_payments`; login_guard сверен дважды |
+| `update_user_pda` | ✓ + `signer == device_key` | user_pda `owner == program_id`; econ_config `owner == program_id` | деривация + сверка | ✓ | ed25519 + `version == old+1` + `prev_hash == hash(old)` | immutable-поля сверены с прежней записью |
+
+### shine_payments
+
+| Инструкция | signer | owner / валидация PDA | адрес PDA | system | прочее |
+|---|---|---|---|---|---|
+| `init` | ✓ payer | все 4 PDA `is_uninitialized` | деривация + сверка | ✓ | `dao_wallet` из `settings`, нет лишних аккаунтов |
+| `update_coef_limit` | ✓ + `signer == config.dao_wallet` | config/coef `owner == id()` | деривация + сверка | — | границы coef/limit/reward; нет лишних аккаунтов |
+| `grant_manager_limits` | ✓ + `signer == config.dao_wallet` | config `owner == id()`; allowance create/read | allowance из `manager_wallet` | ✓ | `state.manager_wallet == args.manager_wallet` |
+| `buy_ticket` / `_usd` / `_sol` | ✓ | config/coef/queues `owner == id()` | ticket деривация + сверка + `is_uninitialized` | ✓ | oracle (key+owner+возраст+confidence), `dao_wallet == config.dao_wallet`, `recipient != inflow_vault`, slippage |
+| `manager_add_ticket` | ✓ | allowance/queues `owner == id()` | allowance из `signer`; ticket деривация + сверка + uninit | ✓ | `allowance.manager_wallet == signer`, `queue_id ∈ {1,2,3}`, `recipient != inflow_vault` |
+| `step_payout` | ✓ | все singleton-PDA `owner == id()` | ticket деривация + сверка | — | `dao_wallet == config.dao_wallet`, `inflow == config.inflow_vault`, ticket `queue/index/!is_paid/recipient`, oracle |
+| `change_ticket_recipient` | ✓ + `signer == ticket.recipient_wallet` | queues + ticket `owner == id()` (через `read_state`) | ticket деривация из своих `queue_id/index` + сверка | — | `!is_paid`, запрет менять «следующий к выплате», `recipient != inflow_vault` |
+
+### shine_login_guard
+
+Аккаунты не используются (`_accounts`); программа stateless, средствами не владеет.
+Защита со стороны вызова реализована в `shine_users`: сверяется и адрес вызываемой
+программы (`login_guard_program.key == SHINE_LOGIN_GUARD_PROGRAM_ID`), и `program_id`
+в `get_return_data`. Подмена/подделка ответа исключены. Отдельных проверок входных
+аккаунтов внутри программы не требуется.
+
+---
+
+## 🟡 LOW / INFO — наблюдения без прямой эксплуатации
+
+### L1. Permissionless `init` в обеих программах
+`shine_payments::init` и `shine_users::init_users_economy_config` может вызвать кто
+угодно первым. Практического эксплойта нет: все значения (включая `dao_wallet` и
+`DAO_AUTHORITY`) берутся из констант `settings`, а не из ввода, повторная
+инициализация заблокирована проверками `is_uninitialized` / `data_is_empty`. Риск
+низкий; при желании привязать init к ожидаемому деплой-кошельку. Совпадает с моделью
+«первый init = деплой».
+
+### L2. В `shine_users` нет явной проверки «лишних аккаунтов» — ✅ ИСПРАВЛЕНО (12.06.2026)
+`shine_payments` в каждом handler делает `require!(account_iter.next().is_none())`.
+В `shine_users` такой проверки не было — лишние аккаунты в конце списка просто
+игнорировались (читается строго нужное количество через `next_account_info`). Это
+безвредно (на безопасность не влияло), но для симметрии и явности добавлено.
+Класс: гигиена, не уязвимость.
+
+Закрыто: во все 4 инструкции `shine_users` (`init_users_economy_config`,
+`update_users_economy_config`, `create_user_pda`, `update_user_pda`) после чтения
+фиксированного набора аккаунтов добавлено `require!(it.next().is_none(),
+ShineUsersError::InvalidInstruction)`. Документация — `doc/programs/shine_users.md` §3.4.
+
+### L3. Гонка за логином (first-come) в `shine_users` — known issue
+Адрес `user_pda` детерминирован из логина; после закрытия griefing-подсева остаётся
+обычное состязание за регистрацию (front-run в мемпуле). On-chain решается только
+commit-reveal; для текущей модели — приемлемый риск, ранее зафиксирован в аудите №2
+(L2). К проверкам аккаунтов не относится.
+
+### L4. Экономическая устойчивость вольта (дизайн, не баг)
+Деньги за покупку тикетов уходят на `dao_wallet`, а выплаты `step_payout` идут из
+`inflow_vault`, наполняемого регистрационными комиссиями `shine_users` (коэффициент
+по умолчанию `START_COEF_PPM = 5x`). При недостаточном притоке регистраций вольт
+истощается и выплаты останавливаются (без потери средств). Это свойство
+экономической модели «очередь/билеты», а не дефект валидации аккаунтов — отмечено
+для полноты (ранее L4 в аудите №2). Мониторить баланс вольта vs обязательств.
+
+---
+
+## ✅ Проверено и подтверждено как корректное (по входным аккаунтам)
+
+- **Подмена PDA** невозможна нигде: всюду пара «деривация `find_program_address` + сверка полного адреса». Пользовательский bump не принимается, `create_program_address` с внешним bump не используется — bump-seed атаки исключены.
+- **Проверка владельца** при каждом чтении PDA: `read_state` и `validate_singleton_state_pda` (`shine_payments`) требуют `owner == id()`; `validate_users_economy_config_pda` и проверка `user_pda.owner == program_id` (`shine_users`) — перед десериализацией данных.
+- **Создаваемые PDA**: проверка `is_uninitialized` / `owner == system && data_is_empty` исключает повторную инициализацию и перезапись чужого аккаунта.
+- **signer / authority**: все handler начинают с обязательного `is_signer`; привилегированные операции дополнительно сверяют ключ с авторитетом (`config.dao_wallet`, `DAO_AUTHORITY`, `allowance.manager_wallet`, `ticket.recipient_wallet`, `device_key`).
+- **system-program** сверяется с `system_program::ID` там, где идёт создание аккаунта/перевод; **sysvar инструкций** сверяется с `sysvar::instructions::id()` перед ed25519-интроспекцией.
+- **Аккаунт оракула**: пин адреса `PYTH_SOL_USD_ACCOUNT` + `owner == pyth_receiver` + `feed_id` + возраст (120 с) + доверительный интервал (10%).
+- **Ed25519 в `shine_users`**: относительные индексы −1/−2, `num_signatures == 1`, все три `ix_index == u16::MAX` (offset-данные внутри самой ed25519-инструкции), сверка `program_id == ed25519_program` и pubkey/signature/message по хэшу — указать на чужую инструкцию нельзя.
+- **Алиасинг аккаунтов**: `recipient != inflow_vault` запрещён на входе во всех точках задания получателя + `vault.key != recipient.key` в `transfer_from_vault`.
+- **`inflow_vault` в `shine_users`** сверяется с PDA, выведенным из `SHINE_PAYMENTS_PROGRAM_ID` и `SHINE_PAYMENTS_INFLOW_VAULT_SEED` — комиссия не может уйти на чужой адрес.
+- **Реентранси** отсутствует: CPI только в System Program и в stateless `shine_login_guard` (с проверкой возвращённого `program_id`); обратных вызовов в наши программы нет.
+
+---
+
+## Приоритет действий
+
+1. **LOW** — ✅ выполнено 12.06.2026: добавлено `require!(it.next().is_none(), …)` во
+   все инструкции `shine_users` для симметрии с `shine_payments` (L2).
+2. **INFO** — зафиксировать в эксплуатационной документации known-issue гонки за
+   логином (L3) и экономику вольта (L4); рассмотреть привязку `init` к ожидаемому
+   деплой-кошельку (L1).
+
+Критичных и высоких находок по полноте проверок входных аккаунтов в этом проходе
+нет. Единственная LOW-правка (L2) применена в рамках этого же изменения; код
+`shine_users` собирается успешно (`cargo build -p shine_users`).