Регистрация: пополнение в том же окне и тестовый top-up

TODO/Близкое/Solana_смарт_контракты/Восстановить_полную_логику_shine_login_guard.md

@@ -0,0 +1,190 @@
+# Восстановить полную логику `shine_login_guard`
+
+
+Тоесть сделать что бы нормально проверялись логины пользователей
+
+
+
+
+
+
+Статус: отложено.
+
+## Зачем это нужно
+
+Сейчас в проекте включена временная заглушка для регистрации коротких логинов:
+
+- on-chain `shine_login_guard` пропускает любые валидные логины длиной от `5` символов;
+- словарная `premium/trademark`-классификация временно отключена;
+- основной UI удерживает обычных пользователей от логинов `5..7` через временный код;
+- это сделано только до внедрения полноценной схемы продажи/выдачи красивых имён и промокодов.
+
+Когда полноценная логика будет готова, нужно вернуть полный режим `shine_login_guard`.
+
+## Что именно было в полной версии
+
+Последняя полная словарная реализация зафиксирована в коммите:
+
+- `0240db5` — `Подготовка перед деплоем в mainnet`
+
+Ключевой файл полной реализации:
+
+- `shine-solana/shine/programs/shine_login_guard/src/lib.rs`
+
+Как быстро посмотреть старую версию:
+
+```bash
+git show 0240db5:shine-solana/shine/programs/shine_login_guard/src/lib.rs
+```
+
+## Как работала старая логика
+
+Полная версия делала следующее:
+
+1. Нормализовала логин:
+   - удаляла `_`;
+   - требовала только ASCII alnum;
+   - приводила к lower-case;
+   - запрещала пустой логин и логин длиннее `20`.
+
+2. Пыталась разбить логин на `1..3` словарных слова:
+   - premium-слова;
+   - trademark-слова.
+
+3. Приоритеты классов были такие:
+   - если найден хотя бы один trademark-компонент -> `CLASS_TRADEMARK`;
+   - если найден только premium-набор -> `CLASS_PREMIUM`;
+   - если словарного матча нет и длина нормализованного логина `<= 7` -> `CLASS_PREMIUM`;
+   - иначе -> `CLASS_FREE`.
+
+4. Для разбивки использовался DFS/backtracking по префиксам строки.
+
+## Какие файлы участвовали в полной логике
+
+### Обязательно восстановить или проверить
+
+1. Код программы:
+   - `shine-solana/shine/programs/shine_login_guard/src/lib.rs`
+
+2. Генерация словаря:
+   - `shine-solana/shine/programs/shine_login_guard/build.rs`
+
+3. Словари:
+   - `shine-solana/shine/programs/shine_login_guard/src/dictionaries/premium/**/*.txt`
+   - `shine-solana/shine/programs/shine_login_guard/src/dictionaries/trademarks/**/*.txt`
+
+4. Документация программы:
+   - `shine-solana/shine/doc/programs/shine_login_guard.md`
+
+5. Архитектурная документация:
+   - `docs/Solana_Architecture/README.md`
+
+6. UI-логика precheck:
+   - `shine-UI/js/pages/register-view.js`
+   - `shine-UI/js/pages/registration-payment-view.js`
+
+## Что именно сейчас временно удалено из `lib.rs`
+
+Временная упрощённая версия убрала:
+
+- `mod wordlist { include!(...) }`
+- `MAX_WORDS_PER_LOGIN`
+- `classify_split(...)`
+- `is_premium_word(...)`
+- `is_trademark_word(...)`
+- словарную DFS-сегментацию
+- fallback `len <= 7 => premium` в пользу временного `len < 5 => premium`
+
+Сейчас `classify(login)` делает только:
+
+1. нормализацию;
+2. проверку минимальной длины `5`;
+3. возврат `CLASS_FREE` для всего остального.
+
+## Как вернуть полную логику
+
+### Минимальный путь
+
+1. Взять старую версию `lib.rs` из коммита `0240db5`.
+2. Вернуть в файл:
+   - `mod wordlist`
+   - `MAX_WORDS_PER_LOGIN`
+   - `classify_split`
+   - `is_premium_word`
+   - `is_trademark_word`
+3. Вернуть старые тесты и при необходимости дописать новые.
+4. Проверить, что `build.rs` всё ещё генерирует `generated_dictionary.rs` в прежнем формате.
+5. Сверить актуальность словарей в `src/dictionaries`.
+6. Обновить `shine_login_guard.md` обратно под словарную логику.
+7. Обновить `docs/Solana_Architecture/README.md`.
+
+### Проверка после возврата
+
+Нужно убедиться, что:
+
+- trademark-логины снова помечаются как `CLASS_TRADEMARK`;
+- premium-логины снова помечаются как `CLASS_PREMIUM`;
+- короткие логины `<= 7` без словарного совпадения снова считаются premium;
+- UI больше не использует временный код для коротких логинов.
+
+## Что поменять в UI при возврате
+
+После возврата полной on-chain логики нужно убрать временный клиентский костыль:
+
+1. Из `shine-UI/js/pages/register-view.js` удалить:
+   - `TEMP_MIN_LOGIN_WITHOUT_PROMO`
+   - `TEMP_ABSOLUTE_MIN_LOGIN_LEN`
+   - `TEMP_PROMO_HASH_HEX`
+   - локальную проверку временного кода
+   - временные тексты про код для логинов `5..7`
+
+2. В `shine-UI/js/pages/registration-payment-view.js` пересмотреть временную строку:
+   - сейчас `promoCode: ''` передаётся принудительно;
+   - после внедрения нормальной promo/on-chain схемы это место надо вернуть к реальной логике промокодов.
+
+## Что учитывать по размеру программы
+
+Текущая временная версия сильно уменьшила размер `shine_login_guard.so`.
+
+При возврате полной словарной логики:
+
+- бинарь снова заметно вырастет;
+- потребуется больший `programdata` rent;
+- для апгрейда понадобится больший временный buffer.
+
+Перед апгрейдом стоит отдельно:
+
+1. собрать `.so`;
+2. измерить размер;
+3. проверить `solana rent <size>`;
+4. убедиться, что на кошельке достаточно SOL для upgrade buffer.
+
+## Что ещё проверить перед возвратом
+
+1. Не осталось ли временных пометок в документации и UI.
+2. Не завязаны ли новые сценарии на допуск логинов длиной `5..7`.
+3. Готова ли полноценная схема:
+   - продажа красивых имён;
+   - промокоды;
+   - менеджеры/селлеры;
+   - DAO-квоты;
+   - или другая финальная модель, которая заменит временный режим.
+
+## Откуда продолжать
+
+Практически продолжать так:
+
+```bash
+git show 0240db5:shine-solana/shine/programs/shine_login_guard/src/lib.rs
+git show 0240db5:shine-solana/shine/programs/shine_login_guard/build.rs
+git show 0240db5:shine-solana/shine/doc/programs/shine_login_guard.md
+```
+
+Потом:
+
+1. вернуть код;
+2. обновить UI;
+3. обновить документы;
+4. собрать `cargo test`;
+5. собрать `cargo build-sbf`;
+6. только потом делать апгрейд on-chain программы.

TODO/Близкое/Solana_смарт_контракты/Сделать_полноценные_инвестиционные_инструменты.md

@@ -0,0 +1 @@
+Передачу билетов владельцами со счёта на счёт