Синхронизировать изменения проекта

2026-07-05 18:18:03 +04:00
parent 0240db59ee
commit 81bef1e1cc
36 changed files with 573 additions and 335 deletions
@@ -37,9 +37,15 @@
   - отображаются новые program id;
   - дефолтный Solana RPC теперь mainnet.

+6. Временный режим регистрации:
+   - в основном UI логины длиной 5-7 символов без временного кода не проходят;
+   - в основном UI логины длиной 5-7 символов с временным кодом проходят локальную проверку;
+   - в основном UI любой другой временный код отклоняется сразу;
+   - ESP32 и прямой on-chain вызов `shine_users` полагаются на текущий временный `shine_login_guard`, то есть валидные логины длиной от 5 символов допускаются без словарной классификации.
+
 ## Ожидаемый результат

 - Во всех перечисленных поверхностях используются новые mainnet program id.
 - Запросы по умолчанию идут в mainnet, кроме явно devnet-утилит.
 - Нет обращений к старым devnet program id.
-
+- Временный UI-барьер для коротких логинов работает так, как задумано, и не ломает обычную регистрацию для логинов от 8 символов.
@@ -0,0 +1,42 @@
+# Временный режим коротких логинов
+
+- статус: `pending`
+
+## Кратко
+
+Временно упрощён `shine_login_guard`:
+
+- on-chain допускаются любые валидные логины длиной от `5` символов;
+- словарная premium/trademark-классификация временно отключена.
+
+Поверх этого основной UI вводит временное ограничение:
+
+- логины длиной `8+` проходят обычную проверку;
+- логины длиной `5..7` допускаются только при вводе временного кода;
+- любой другой код отклоняется сразу.
+
+ESP32 в этом временном режиме не ограничивается UI-кодом и использует только on-chain правила.
+
+## Что проверять
+
+1. Основной UI:
+   - логин длиной `4` символа отклоняется;
+   - логин длиной `5..7` без временного кода отклоняется;
+   - логин длиной `5..7` с корректным временным кодом проходит локальную проверку;
+   - логин длиной `5..7` с любым другим кодом отклоняется;
+   - логин длиной `8+` проходит без временного кода.
+
+2. Solana on-chain:
+   - `shine_login_guard` возвращает `CLASS_FREE` для валидных логинов длиной от `5`;
+   - `shine_login_guard` возвращает `CLASS_PREMIUM` для логинов короче `5` или с невалидными символами.
+
+3. ESP32 / прямой вызов:
+   - валидный логин длиной `5+` регистрируется без временного кода;
+   - логин короче `5` не регистрируется.
+
+## Ожидаемый результат
+
+- Основной UI удерживает обычных пользователей от коротких логинов без временного кода.
+- Свои пользователи могут временно регистрировать короткие логины через UI-код.
+- ESP32 продолжает работать без отдельной промо-логики.
+- On-chain логика остаётся простой и компактной.
@@ -16,7 +16,7 @@

 В Solana-модуле сейчас три основные программы:

-1. `shine_login_guard` — проверяет логин и возвращает класс логина: обычный, premium или trademark.
+1. `shine_login_guard` — в текущем временном режиме проверяет базовую валидность логина и пропускает on-chain любые валидные логины длиной от 5 символов.
 2. `shine_users` — создает и обновляет пользовательскую PDA-запись, проверяет подписи и берет оплату за регистрацию/увеличение лимита.
 3. `shine_payments` — принимает входящий поток средств в `inflow_vault`, ведет очереди тикетов, позволяет DAO выдавать лимиты менеджерам и выполняет выплаты.

@@ -35,7 +35,7 @@ DAO в текущем виде не является отдельной Anchor-

 | Блок | Папка/имя | Текущие функции из кода | Основной смысл |
 | --- | --- | --- | --- |
-| 1 | `shine_login_guard` | `classify_login` | Проверка логина перед регистрацией. |
+| 1 | `shine_login_guard` | `classify_login` | Временная on-chain проверка логина перед регистрацией. |
 | 2 | `shine_users` | `init_users_economy_config`, `update_users_economy_config`, `create_user_pda`, `update_user_pda` | Регистрация пользователя, обновление записи, экономика лимита. |
 | 3 | `shine_payments` | `init`, `update_coef_limit`, `grant_manager_limits`, `buy_ticket`, `buy_ticket_usd`, `buy_ticket_sol`, `manager_add_ticket`, `step_payout`, `change_ticket_recipient` | Vault, билеты, очереди, выплаты, DAO-настройки, лимиты менеджеров. |
 | DAO | governance/authority | Вызовы через governance и управляющие ключи | Управление правами, казной, настройками и будущими обновлениями программ. |
@@ -62,7 +62,7 @@ DAO в текущем виде не является отдельной Anchor-
 Для удобного понимания на старте можно считать, что есть четыре группы ключей:

 1. `key_1` / authority программы `shine_login_guard`.
-   - Сейчас программа только классифицирует логин.
+   - Сейчас программа только выполняет временную базовую проверку логина.
   - На первом этапе ее можно оставить под отдельным ключом.
   - В будущем право обновления можно передать DAO.

@@ -140,7 +140,7 @@ Solana-модуль лежит в основном репозитории как

 1. `shine_login_guard`
   - Пока оставить на отдельном ключе `key_1`.
-   - Передачу DAO сделать позже, когда логика premium/trademark стабилизируется.
+   - Передачу DAO сделать позже, когда временный режим будет заменён на постоянную логику промокодов и/или premium/trademark.

 2. `shine_users`
   - Economy-настройки уже должны обновляться DAO-authority.