# Синхронизация mainnet-адресов Solana по UI/серверу/ESP32

- статус: `pending`

## Кратко

Во все основные клиентские и серверные точки проекта протянуты актуальные mainnet-адреса программ:

- `shine_login_guard`: `SHiGxGsXGioQYCYhchQ5R7KWoxN5UjFAFsucPf6sfnh`
- `shine_users`: `SHiNEPr1APdAgNBteUyBXcNovaHctpSjUu8oH2ZJdN6`
- `shine_payments`: `SHiPmXbM9Fs9khzRUW3TGKsS2W84aqaXTxs3ZkajW9v`

Также по умолчанию переключены основные RPC defaults на `https://api.mainnet-beta.solana.com` там, где это нужно для рабочего mainnet-сценария.

## Что проверять

1. Основной UI:
   - отображение и использование новых program id;
   - регистрация/чтение Solana PDA в mainnet;
   - экран кошелька и покупка лимита.

2. Server UI:
   - создание server PDA в mainnet;
   - чтение PDA;
   - обновление PDA;
   - корректная блокировка devnet-автопополнения при mainnet endpoint.

3. Browser plugin wallet:
   - резолв `user_pda` и `server PDA` через mainnet RPC.

4. Web UI `shine_payments`:
   - чтение очередей;
   - покупка билета;
   - admin/manager/dao tools открываются с новыми program id и mainnet RPC.

5. ESP32 homeserver UI:
   - отображаются новые 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 символов.