Удалить закрытые записи pending features
This commit is contained in:
AidarKC
parent
f2b23ace8b
commit
a9a55da8e0
@ -1,43 +0,0 @@
|
|||||||
# Кошелёк: лимит/закрепление блокчейна Сияния
|
|
||||||
|
|
||||||
- статус: `pending`
|
|
||||||
|
|
||||||
## Кратко что сделано
|
|
||||||
|
|
||||||
- На экране `Кошелёк -> Блокчейн Сияния` добавлены 2 слоя данных:
|
|
||||||
- фактическое состояние цепочки на сервере (`кол-во блоков`, `размер`, `крайний блок`, `hash`, `размер крайнего блока`);
|
|
||||||
- закреплённое состояние в Solana PDA (`лимит`, `использовано`, `остаток`, `крайний блок`, `hash`).
|
|
||||||
- Добавлены действия:
|
|
||||||
- `Закрепить в Solana` — обновляет PDA до текущего состояния серверной цепочки;
|
|
||||||
- `Увеличить лимит` — увеличивает `paid_limit_bytes` в PDA с учётом цены из economy PDA.
|
|
||||||
- Если `rootKey`/`blockchainKey` не сохранены локально, экран запрашивает пароль, восстанавливает ключи через стандартную derivation-логику и предлагает сохранить их в зашифрованный контейнер.
|
|
||||||
|
|
||||||
## Что проверять вручную
|
|
||||||
|
|
||||||
1. Открыть `Кошелёк -> Блокчейн Сияния` под авторизованным пользователем.
|
|
||||||
2. Проверить, что в блоке "Фактическое состояние на сервере" отображаются:
|
|
||||||
- число блоков;
|
|
||||||
- размер цепочки;
|
|
||||||
- номер/хэш крайнего блока;
|
|
||||||
- размер крайнего блока.
|
|
||||||
3. Проверить, что в блоке "Закреплено в Solana" отображаются:
|
|
||||||
- лимит;
|
|
||||||
- израсходовано;
|
|
||||||
- остаток;
|
|
||||||
- номер/хэш крайнего закреплённого блока.
|
|
||||||
4. Нажать `Закрепить в Solana` и убедиться, что:
|
|
||||||
- приходит успешная транзакция;
|
|
||||||
- после обновления Solana-показатели подтягиваются до серверных (или максимально близко по актуальному состоянию).
|
|
||||||
5. Нажать `Увеличить лимит`, ввести значение кратное шагу, подтвердить списание и проверить:
|
|
||||||
- лимит увеличился;
|
|
||||||
- отображение цены/списания соответствует economy PDA.
|
|
||||||
6. Повторить пункты 4-5 в сценарии, когда `rootKey`/`blockchainKey` не сохранены, и проверить:
|
|
||||||
- появляется запрос пароля;
|
|
||||||
- после ввода пароля операции выполняются;
|
|
||||||
- предложение сохранить ключи показывается.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- Экран корректно разделяет "фактическое состояние на сервере" и "закреплённое в Solana".
|
|
||||||
- Обе операции (`Закрепить в Solana`, `Увеличить лимит`) выполняются без ошибок при валидных данных.
|
|
||||||
- Восстановление ключей через пароль работает, а без нужных ключей операция не выполняется молча.
|
|
||||||
@ -1,29 +0,0 @@
|
|||||||
# Озвучивание ответов агента
|
|
||||||
|
|
||||||
## Что сделано
|
|
||||||
|
|
||||||
В локальный Telegram-бот-сервис агента-кодера добавлены персональные настройки озвучивания финальных ответов:
|
|
||||||
|
|
||||||
- `/voice_on` включает озвучивание для текущего Telegram-пользователя;
|
|
||||||
- `/voice_off` выключает озвучивание для текущего Telegram-пользователя;
|
|
||||||
- `/voice_status` показывает текущее состояние;
|
|
||||||
- если озвучивание включено, после текстового финального ответа сервис генерирует voice-файл через OpenAI TTS и отправляет его в Telegram;
|
|
||||||
- длинные ответы делятся на несколько фрагментов озвучки.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
1. Перезапустить `shine-agent-bot-coder`.
|
|
||||||
2. Отправить `/voice_status` и убедиться, что по умолчанию озвучивание выключено.
|
|
||||||
3. Отправить `/voice_on`.
|
|
||||||
4. Дать простую задачу агенту и проверить, что пришёл полный текстовый ответ и voice-файл с тем же ответом.
|
|
||||||
5. Отправить `/voice_off`.
|
|
||||||
6. Дать ещё одну простую задачу и проверить, что приходит только текст.
|
|
||||||
7. При возможности проверить второго whitelist-пользователя: его настройка должна быть независимой.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
Настройка хранится персонально по username и сохраняется после перезапуска сервиса. При включённой настройке Telegram получает текстовый ответ и дополнительное voice-сообщение с озвучкой. При выключенной настройке поведение остаётся прежним.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
pending
|
|
||||||
@ -1,19 +0,0 @@
|
|||||||
# Голосовая адаптация ответов Telegram-бота
|
|
||||||
|
|
||||||
## Краткое описание
|
|
||||||
Добавлены персональные настройки голосовых ответов и адаптации текста перед озвучкой. Если голосовые ответы включены, сервис перед TTS может отдельно прогонять финальный текст через OpenAI-модель и отправлять более короткую голосовую версию в исходный чат, личный чат пользователя и общий чат `@shine_writing`, если эти чаты доступны и отличаются.
|
|
||||||
|
|
||||||
## Что проверить
|
|
||||||
- Команды `/voice_on`, `/voice_off`, `/voice_status` для конкретного пользователя.
|
|
||||||
- Команды `/voice_rewrite_on`, `/voice_rewrite_off`, `/voice_rewrite_status` для конкретного пользователя.
|
|
||||||
- Команда `/status` показывает очередь, голосовые ответы и адаптацию текста перед озвучкой.
|
|
||||||
- При включённых голосовых ответах после задачи приходит текстовый ответ и voice-ответ.
|
|
||||||
- При включённой адаптации voice-ответ короче и без длинных технических строк.
|
|
||||||
- При задаче из личного чата voice дополнительно появляется в общем чате `@shine_writing`.
|
|
||||||
- При задаче из общего чата voice дополнительно появляется в личном чате пользователя, если сервис уже знает его личный chat_id.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
Текстовый ответ остаётся полным. Голосовая версия приходит отдельно, звучит короче и естественнее, а персональные настройки одного пользователя не меняют поведение других пользователей.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
pending
|
|
||||||
@ -1,24 +0,0 @@
|
|||||||
# Эксперимент Understand Anything
|
|
||||||
|
|
||||||
## Краткое описание
|
|
||||||
|
|
||||||
Добавлена изолированная лаборатория для проверки `Lum1104/Understand-Anything` без подключения к сборке, деплою и рабочему коду SHiNE.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
- Установить Node.js 22+ и pnpm 10+.
|
|
||||||
- Запустить `./tools/understand-anything-lab/install_codex_skills.sh`.
|
|
||||||
- Перезапустить Codex-сессию.
|
|
||||||
- Выполнить `/understand --language ru` в корне проекта.
|
|
||||||
- После генерации выполнить `/understand-dashboard` и проверить, что граф открывается и помогает ориентироваться по серверным, UI, Solana и агентским папкам.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- В проекте появляется локальная папка `.understand-anything/` с графом знаний.
|
|
||||||
- Dashboard открывается и показывает интерактивный граф проекта.
|
|
||||||
- Основные процессы сборки и деплоя SHiNE не меняются.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
`pending`
|
|
||||||
|
|
||||||
@ -1,24 +0,0 @@
|
|||||||
# Центр задач Telegram-агента
|
|
||||||
|
|
||||||
## Краткое описание
|
|
||||||
|
|
||||||
Добавлена первая версия центра задач и предложений внутри `SHiNE-agent-bot-coder`.
|
|
||||||
|
|
||||||
Бот хранит задачи и предложения в JSON-файле данных сервиса, умеет показывать список через `/tasks`, создавать задачи для игроков по фразе Айдара, принимать предложения игроков по префиксу `предложение:`, менять статусы и добавлять короткие напоминания после ответов.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
- Айдар пишет `/tasks` и видит текущий список задач и предложений без уже закрытого предложения от Димы.
|
|
||||||
- Айдар пишет `поставь задачу Милане: проверить описание SHiNE` и задача появляется в списке Миланы.
|
|
||||||
- Милана пишет `/tasks` и видит назначенную задачу.
|
|
||||||
- Игрок пишет `предложение: ...`, после чего предложение появляется у Айдара.
|
|
||||||
- Айдар меняет статус фразами вида `одобрить TC-XXXX`, `доработать TC-XXXX`, `закрыть TC-XXXX`, где `TC-XXXX` - ID существующей задачи или предложения.
|
|
||||||
- После обычного ответа бота Айдару или игроку появляется короткое напоминание, если у пользователя есть активные задачи.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
Задачи и предложения сохраняются между перезапусками сервиса, статусы меняются корректно, напоминания не мешают основному ответу Codex.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
pending
|
|
||||||
@ -1,31 +0,0 @@
|
|||||||
# Рестарты и voice-настройки Telegram-агента
|
|
||||||
|
|
||||||
## Краткое описание
|
|
||||||
|
|
||||||
Добавлена первая версия безопасного рестарта Telegram-агента:
|
|
||||||
|
|
||||||
- `/restart` и `/restart_service` ставят отложенный рестарт после текущей задачи и до взятия следующей;
|
|
||||||
- `/restart_hard`, `/restart_now`, `/restart_force` выполняют жёсткий рестарт сразу;
|
|
||||||
- команды рестарта доступны только Айдару;
|
|
||||||
- voice-ответы включены по умолчанию для новых пользователей;
|
|
||||||
- адаптация текста перед озвучкой стала ближе к исходному ответу и не должна менять смысл;
|
|
||||||
- скрыты отдельные команды статуса voice-функций из справки, состояние показывается через `/status`.
|
|
||||||
|
|
||||||
## Что проверить
|
|
||||||
|
|
||||||
1. Отправить `/restart` во время активной задачи игрока или Айдара.
|
|
||||||
2. Убедиться, что активная задача завершается, после чего сервис перезапускается до следующей задачи.
|
|
||||||
3. Отправить `/restart_hard` и убедиться, что сервис перезапускается сразу.
|
|
||||||
4. Проверить, что игрок не может выполнить команды рестарта.
|
|
||||||
5. Проверить `/status`: он показывает очередь и состояния голосовых функций.
|
|
||||||
6. Проверить нового пользователя: voice-ответы должны быть включены по умолчанию.
|
|
||||||
7. Проверить текстовый запрос пользователя с включённым voice: после текстового ответа должен прийти voice-файл.
|
|
||||||
8. Проверить, что адаптированная озвучка не превращается в другой ответ, а только убирает длинные технические строки.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
Сервис можно обновлять без потери текущей задачи через отложенный рестарт. Жёсткий рестарт остаётся аварийной командой Айдара. Voice-ответы работают для текстовых и голосовых запросов, а голосовая версия остаётся близкой к текстовой.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
pending
|
|
||||||
@ -1,26 +0,0 @@
|
|||||||
# Кнопки вкладки «Каналы»
|
|
||||||
|
|
||||||
## Что сделано
|
|
||||||
|
|
||||||
Доработана верхняя панель вкладки «Каналы»:
|
|
||||||
- при открытии нижней кнопкой «Каналы» показывается режим «Все каналы»;
|
|
||||||
- в режиме «Все каналы» справа доступны кнопка «Мои каналы» и иконка поиска канала;
|
|
||||||
- в режиме «Мои каналы» доступен переход обратно во «Все каналы», а справа показывается плюсик создания канала.
|
|
||||||
|
|
||||||
## Что проверить
|
|
||||||
|
|
||||||
1. Открыть вкладку «Каналы» через нижнюю навигацию.
|
|
||||||
2. Убедиться, что открыт режим «Все каналы», а плюсик создания канала не отображается.
|
|
||||||
3. Нажать иконку поиска в режиме «Все каналы».
|
|
||||||
4. Убедиться, что открывается текущий сценарий поиска каналов.
|
|
||||||
5. Нажать «Мои каналы».
|
|
||||||
6. Убедиться, что справа появился плюсик создания канала.
|
|
||||||
7. Нажать «Все каналы» или стрелку назад и проверить возврат к режиму «Все каналы».
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
Кнопки верхней панели соответствуют активному режиму: поиск в «Все каналы», создание только в «Мои каналы».
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
pending
|
|
||||||
@ -1,13 +0,0 @@
|
|||||||
# Длинные voice/audio в Telegram-боте агента
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
Бот теперь умеет обрабатывать длинные voice/audio аккуратнее: учитывает лимит Telegram Bot API на скачивание слишком больших файлов, поддерживает альтернативный `TELEGRAM_API_BASE_URL` для локального `telegram-bot-api`, локально пережимает длинное аудио через `ffmpeg`, режет на куски и отправляет их в OpenAI transcription последовательно.
|
|
||||||
- что именно проверять:
|
|
||||||
1. Короткий `voice` по-прежнему распознаётся без заметной задержки.
|
|
||||||
2. Длинный `audio/voice`, который помещается в скачивание Telegram, успешно пережимается, режется на части и даёт цельную расшифровку.
|
|
||||||
3. Очень большой файл через обычный `https://api.telegram.org` даёт понятное сообщение про лимит Telegram.
|
|
||||||
4. После переключения на локальный `telegram-bot-api` такой же большой файл начинает скачиваться и распознаваться.
|
|
||||||
- ожидаемый результат:
|
|
||||||
Бот не падает на длинных аудио, даёт либо расшифровку, либо понятное объяснение, какой именно лимит мешает и что нужно включить.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,14 +0,0 @@
|
|||||||
# Диагностика больших voice/audio в Telegram-боте
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
- Бот при большом voice/audio больше не отказывается заранее по метаданным Telegram. Теперь он сначала сообщает, что пробует скачать файл, затем отдельно сообщает об успешном скачивании и только после этого переходит к подготовке аудио и распознаванию через OpenAI.
|
|
||||||
- что именно проверять:
|
|
||||||
- Отправить в бота большой `voice` или `audio`, который раньше попадал под ранний отказ.
|
|
||||||
- Проверить, что сначала приходит сообщение о попытке скачать большой файл.
|
|
||||||
- Проверить два сценария:
|
|
||||||
- скачивание удалось: бот пишет об успешной загрузке и продолжает распознавание;
|
|
||||||
- скачивание не удалось: бот пишет именно о неудачном скачивании из Telegram, без ложной привязки к ошибке OpenAI.
|
|
||||||
- ожидаемый результат:
|
|
||||||
- Пользователь видит понятную поэтапную диагностику: попытка скачивания, результат скачивания и только потом следующий этап обработки.
|
|
||||||
- статус:
|
|
||||||
- pending
|
|
||||||
@ -1,24 +0,0 @@
|
|||||||
# Перенос server UI в shine-UI
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
Веб-панель управления серверной Solana PDA перенесена в `shine-UI/` как отдельные страницы.
|
|
||||||
Новая точка входа: `shine-UI/server-ui.html`.
|
|
||||||
Общая логика работы с PDA вынесена в единый модуль `shine-UI/js/services/shine-user-pda-service.js`.
|
|
||||||
|
|
||||||
- что именно проверять:
|
|
||||||
1. Открытие `shine-UI/server-ui.html` и переходы на страницы создания и обновления PDA.
|
|
||||||
2. Генерацию ключей из логина и пароля на странице создания.
|
|
||||||
3. Ручной ввод base58-ключей и регистрацию серверного PDA.
|
|
||||||
4. Загрузку существующей серверной PDA на странице обновления.
|
|
||||||
5. Обновление `server_address` и `sync_servers` только по `root + device` без blockchain-ключа.
|
|
||||||
6. Корректное чтение нового формата `ServerProfileBlock` через общий PDA-модуль.
|
|
||||||
7. То, что актуальной точкой входа остаётся `shine-UI/server-ui.html`.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
1. Новые страницы открываются без JS-ошибок.
|
|
||||||
2. Создание серверной PDA проходит через общий модуль и пишет актуальный формат.
|
|
||||||
3. Обновление серверной PDA переиспользует существующую подпись LastBlockState и не требует blockchain-ключ.
|
|
||||||
4. Клиентский UI не ломается после перевода общего PDA-слоя на новый формат.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,20 +0,0 @@
|
|||||||
# Кнопка настройки сервера и DEVNET topup
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
На экране `entry-settings-view` добавлена кнопка `Настроить свой сервер`, открывающая `server-ui.html` в новой вкладке.
|
|
||||||
На страницах серверного UI добавлена кнопка открытия `devnet-topup-view` в новой вкладке с автоматической передачей `wallet` из device-адреса.
|
|
||||||
|
|
||||||
- что именно проверять:
|
|
||||||
1. На странице настроек входа есть кнопка `Настроить свой сервер`.
|
|
||||||
2. Кнопка открывает `shine-UI/server-ui.html` в новой вкладке.
|
|
||||||
3. На страницах `create-server-pda.html` и `update-server-pda.html` есть кнопка `Открыть пополнение DEVNET`.
|
|
||||||
4. Если device public key заполнен, новая вкладка открывает `devnet-topup-view?wallet=...` с правильным адресом.
|
|
||||||
5. Если device-адрес не введён, серверный UI показывает понятную ошибку и не открывает пустую ссылку.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
1. Переход в серверный UI с клиентской страницы настроек работает.
|
|
||||||
2. Пополнение devnet из серверного UI открывается сразу на нужный адрес.
|
|
||||||
3. Основной клиентский UI и серверные страницы не получают JS-ошибок при загрузке.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,15 +0,0 @@
|
|||||||
# Фикс DEVNET topup и автоподстановки пароля
|
|
||||||
|
|
||||||
- статус: pending
|
|
||||||
- кратко: исправлена ширина экрана `devnet-topup-view` после успешного пополнения и отключена нежелательная автоподстановка пароля в server UI и на экранах входа/регистрации.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
- Открыть страницу пополнения DEVNET, выполнить пополнение и убедиться, что после появления `Signature` экран не расширяется по ширине.
|
|
||||||
- Проверить, что кнопки на странице пополнения остаются аккуратными и не разъезжаются.
|
|
||||||
- Открыть `server-ui/update-server-pda.html`, загрузить PDA и убедиться, что поле пароля остаётся пустым.
|
|
||||||
- Проверить обычные экраны входа и регистрации: поле пароля не должно самопроизвольно заполняться длинной строкой.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
- Длинная transaction signature переносится по строкам внутри прежней ширины экрана.
|
|
||||||
- Кнопки сохраняют компактный mobile-first layout.
|
|
||||||
- Поля пароля пустые, пока пользователь сам ничего не вводил.
|
|
||||||
@ -1,17 +0,0 @@
|
|||||||
# Диагностика ключей server PDA и баланс device
|
|
||||||
|
|
||||||
- статус: pending
|
|
||||||
- кратко: на странице обновления server PDA добавлена сверка ожидаемых ключей с уже загруженной PDA, предупреждение о неверном пароле, кнопка показа баланса device-аккаунта и уточнение, что create/update оплачиваются с deviceKey.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
- На `update-server-pda.html` загрузить существующую PDA и убедиться, что видны ожидаемые `root/blockchain/device` public key.
|
|
||||||
- Ввести правильный пароль и нажать `Сгенерировать`: должно появиться сообщение, что ключи совпадают.
|
|
||||||
- Ввести неверный пароль и нажать `Сгенерировать`: должно появиться сообщение, что ключи не совпали и пароль, вероятно, неверный.
|
|
||||||
- На `create-server-pda.html` и `update-server-pda.html` нажать `Показать / обновить баланс device` и убедиться, что баланс читается по текущему `devPub`.
|
|
||||||
- Повторить `update_user_pda` после увеличения `heap frame` и проверить, ушла ли ошибка `memory allocation failed`.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
- Пользователь видит, какие именно public key должны получиться для загруженной PDA.
|
|
||||||
- Ошибка неправильного пароля выявляется до отправки транзакции.
|
|
||||||
- Баланс device-кошелька читается прямо со страницы.
|
|
||||||
- Если проблема `OOM` была только в размере heap frame/compute budget клиента, `update_user_pda` начинает проходить.
|
|
||||||
@ -1,15 +0,0 @@
|
|||||||
# Lazy-import Solana PDA: актуальный формат
|
|
||||||
|
|
||||||
- Краткое описание:
|
|
||||||
Серверный Java lazy-import пользователя из `shine_users` обновлён под актуальный формат `user_pda`. Убран RPC-фильтр по размеру PDA, добавлен разбор нового `ServerProfileBlock` (`block_type = 30`) без сохранения server-only полей в `solana_users`.
|
|
||||||
- Что проверять:
|
|
||||||
1. Взять логин пользователя, который существует в Solana PDA, но отсутствует в локальной таблице `solana_users`.
|
|
||||||
2. Выполнить вход этим логином через сервер.
|
|
||||||
3. Убедиться, что lazy-import подтянул пользователя из Solana.
|
|
||||||
4. Убедиться, что запись в `solana_users` создана с полями `login`, `blockchain_name`, `solana_key`, `blockchain_key`, `device_key`.
|
|
||||||
5. Убедиться, что отсутствие/наличие server-полей в PDA не ломает импорт.
|
|
||||||
- Ожидаемый результат:
|
|
||||||
1. Пользователь успешно находится и импортируется из Solana PDA независимо от фактического размера PDA.
|
|
||||||
2. Новый `ServerProfileBlock` не ломает парсер.
|
|
||||||
3. В БД не появляются лишние server-only поля.
|
|
||||||
- Статус: `pending`
|
|
||||||
@ -1,33 +0,0 @@
|
|||||||
# Pure Rust `shine_users` и `shine_login_guard`
|
|
||||||
|
|
||||||
Статус: `pending`
|
|
||||||
|
|
||||||
## Что сделано
|
|
||||||
|
|
||||||
- `shine_login_guard` переписан без Anchor на чистый Rust/Solana SDK.
|
|
||||||
- `shine_users` переписан без Anchor на чистый Rust/Solana SDK.
|
|
||||||
- Для `shine_users` введён новый instruction ABI без Anchor discriminator'ов.
|
|
||||||
- Для `shine_users` используются новые seed'ы:
|
|
||||||
- `user_login=` для `user_pda`
|
|
||||||
- `shine_users_economy_config` для economy PDA
|
|
||||||
- Формат блоков PDA синхронизирован:
|
|
||||||
- `SessionsBlock = 50`
|
|
||||||
- `TrustedStateBlock = 70`
|
|
||||||
- UI JS-модуль и Java lazy-import обновлены под новые seeds/ABI/коды блоков.
|
|
||||||
|
|
||||||
## Что проверить руками
|
|
||||||
|
|
||||||
1. В обычном UI выполнить регистрацию нового пользователя в Solana.
|
|
||||||
2. Проверить, что после регистрации читается новая `user_pda`.
|
|
||||||
3. В server UI выполнить создание server PDA.
|
|
||||||
4. В server UI выполнить update server PDA.
|
|
||||||
5. Проверить, что после update растёт `record_number`.
|
|
||||||
6. Проверить, что lazy-import на сервере читает новый формат PDA без ошибок.
|
|
||||||
7. Проверить, что старые Anchor discriminator'ы больше нигде не требуются.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- Регистрация и update работают на новых чисто-rust программах.
|
|
||||||
- UI не использует старый Anchor ABI.
|
|
||||||
- Серверный Java parser читает новый формат PDA.
|
|
||||||
- Ошибок `out of memory` и anchor-specific падений больше нет.
|
|
||||||
@ -1,25 +0,0 @@
|
|||||||
# ESP32 Argon2/UI совместимость и экран результата
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
выравнивание derivation на `ESP32` с текущим `UI` по нормализации логина, совместимости `master secret`/`root.key`/`bch.key`/`dev.key`, а также правки экрана результата и progress bar.
|
|
||||||
|
|
||||||
- что именно проверять:
|
|
||||||
1. На `UI` и `ESP32` ввести один и тот же логин в разном регистре, например `Anya24`, и один и тот же непустой пароль.
|
|
||||||
2. Убедиться, что после нормализации логина на `ESP32` и `UI` получаются одинаковые:
|
|
||||||
`master secret`, `root`, `blockchain`, `device` в `Base58`.
|
|
||||||
3. Проверить режим пустого пароля:
|
|
||||||
`UI` и `ESP32` должны выдать одинаковые ключи в legacy-режиме.
|
|
||||||
4. Проверить, что пустой логин на `ESP32` не запускает расчёт и показывает сообщение об ошибке.
|
|
||||||
5. Проверить progress bar:
|
|
||||||
при непустом пароле полоса должна быть видна и двигаться.
|
|
||||||
6. Проверить экран результата:
|
|
||||||
сначала `Login`, затем `Password`, затем `Master secret` и ключи;
|
|
||||||
свайп вверх/вниз должен прокручивать длинный результат без артефактов.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
`ESP32` и `UI` считают одинаковый `master secret` и одинаковые ключи для одинаковых входных данных;
|
|
||||||
progress bar виден;
|
|
||||||
экран результата читаемый и корректно прокручивается.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,17 +0,0 @@
|
|||||||
## Краткое описание
|
|
||||||
В `SHiNE-agent-bot-coder` для личных чатов добавлен режим одного редактируемого статусного сообщения. Бот принимает запрос, обновляет это сообщение по этапам обработки и в конце превращает его в финальный текстовый ответ. При длинном ответе допускается ещё одно дополнительное текстовое сообщение с продолжением. Голосовой ответ остаётся отдельным сообщением.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
1. Отправить в личный чат короткий текстовый запрос и убедиться, что бот не шлёт цепочку промежуточных сообщений, а редактирует одно сообщение до финального ответа.
|
|
||||||
2. Отправить в личный чат `voice` или `audio` и убедиться, что в том же сообщении последовательно видны этапы распознавания и выполнения.
|
|
||||||
3. Проверить длинный ответ, который не помещается в один Telegram message: должно получиться не больше двух текстовых сообщений.
|
|
||||||
4. Проверить, что `voice`-ответ приходит отдельным новым сообщением после текстового.
|
|
||||||
5. Проверить, что в `@shine_writing` по-прежнему логируются только итоговые `вопрос -> ответ`, без промежуточных статусов.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
- В личке основная переписка стала чище: промежуточные этапы живут в одном редактируемом сообщении.
|
|
||||||
- При длинном ответе бот не разбрасывает ответ на много сообщений.
|
|
||||||
- Канал `@shine_writing` работает по старой схеме без лишнего шума.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
`pending`
|
|
||||||
@ -1,24 +0,0 @@
|
|||||||
## Краткое описание
|
|
||||||
В локальный Telegram-бот `SHiNE-agent-bot-coder` добавлена команда `/settings`, которая сразу показывает текущие персональные настройки пользователя и список доступных команд для их изменения. В `/help` оставлена только ссылка на `/settings` без перечисления самих команд настроек. Также добавлен переключатель режима ответа в личке: один редактируемый статус или отдельные сообщения по этапам.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
1. Отправить `/help` и убедиться, что в справке есть `/settings`, но нет списка команд `/voice_*` и `/single_message_*`.
|
|
||||||
2. Отправить `/settings` и проверить, что бот показывает текущие значения:
|
|
||||||
- озвучивание финальных ответов;
|
|
||||||
- адаптацию текста перед озвучкой;
|
|
||||||
- режим одного редактируемого сообщения в личке.
|
|
||||||
3. По очереди переключить:
|
|
||||||
- `/voice_on` и `/voice_off`;
|
|
||||||
- `/voice_rewrite_on` и `/voice_rewrite_off`;
|
|
||||||
- `/single_message_on` и `/single_message_off`.
|
|
||||||
4. После каждого переключения снова вызвать `/settings` и убедиться, что статус изменился и сохранился.
|
|
||||||
5. При `/single_message_on` отправить обычный запрос в личку и проверить, что бот ведёт его через одно редактируемое сообщение.
|
|
||||||
6. При `/single_message_off` отправить обычный запрос в личку и проверить, что бот снова шлёт отдельные сообщения по этапам и отдельный финальный ответ.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
- `/settings` стал основной точкой входа для пользовательских настроек.
|
|
||||||
- `/help` стал короче и не дублирует список команд настроек.
|
|
||||||
- Режим ответа в личке реально переключается персонально для пользователя и сохраняется после перезапуска сервиса.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
`pending`
|
|
||||||
@ -1,210 +0,0 @@
|
|||||||
# Shine Payments: e2e после переписи без Anchor и добавления Q3
|
|
||||||
|
|
||||||
## Краткое описание
|
|
||||||
|
|
||||||
Нужно вручную и через вспомогательные CLI-проверки подтвердить, что программа `shine_payments` после:
|
|
||||||
|
|
||||||
- переписи на чистый `solana_program`;
|
|
||||||
- отказа от `programs/common`;
|
|
||||||
- добавления очереди `Q3`;
|
|
||||||
- обновления HTML UI;
|
|
||||||
|
|
||||||
корректно работает на devnet с новым `program id`.
|
|
||||||
|
|
||||||
Отличие от финального боевого сценария:
|
|
||||||
|
|
||||||
- вместо DAO-механики используется обычный кошелёк `FUc28vNixp7F3nnkpGVt6nuJbgvJ4429v4B5wS52Df6P`, которому даны права DAO на изменение коэффициента и выдачу лимитов менеджеру.
|
|
||||||
|
|
||||||
## Что именно проверять
|
|
||||||
|
|
||||||
### 1. Подготовка окружения
|
|
||||||
|
|
||||||
Проверить и зафиксировать:
|
|
||||||
|
|
||||||
- новый keypair программы `shine_payments`;
|
|
||||||
- новый `program id`;
|
|
||||||
- обновление `program id` в HTML UI и связанных настройках;
|
|
||||||
- наличие deploy authority, которой можно закрыть старый buffer/programdata, если это технически доступно;
|
|
||||||
- адреса тестовых кошельков:
|
|
||||||
- DAO/базовый кошелёк;
|
|
||||||
- менеджер;
|
|
||||||
- покупатель 1;
|
|
||||||
- покупатель 2;
|
|
||||||
- получатели выплат.
|
|
||||||
|
|
||||||
### 2. Очистка/смена старой программы
|
|
||||||
|
|
||||||
Проверить один из сценариев:
|
|
||||||
|
|
||||||
- если возможно, закрыть старый `program buffer/programdata` текущими ключами;
|
|
||||||
- если закрытие невозможно или нецелесообразно, зафиксировать это и продолжить с новым `program id`.
|
|
||||||
|
|
||||||
Отдельно проверить, что старые PDA предыдущей версии не используются новой программой.
|
|
||||||
|
|
||||||
### 3. Деплой и init новой программы
|
|
||||||
|
|
||||||
Проверить:
|
|
||||||
|
|
||||||
- `cargo build-sbf` проходит;
|
|
||||||
- новая программа деплоится на devnet;
|
|
||||||
- `init` выполняется один раз на пустых PDA;
|
|
||||||
- после `init` читаются:
|
|
||||||
- `config`;
|
|
||||||
- `coef_limit`;
|
|
||||||
- `queues`;
|
|
||||||
- `inflow_vault`.
|
|
||||||
|
|
||||||
Сразу после `init` запросить состояние очередей и зафиксировать, что:
|
|
||||||
|
|
||||||
- `Q1`, `Q2`, `Q3` пустые;
|
|
||||||
- `tickets_total = 0`;
|
|
||||||
- `tickets_paid = 0`;
|
|
||||||
- все суммы равны `0`.
|
|
||||||
|
|
||||||
### 4. Проверка покупки билета
|
|
||||||
|
|
||||||
На минимальных суммах проверить:
|
|
||||||
|
|
||||||
1. покупку через `buy_ticket_usd`;
|
|
||||||
2. покупку через `buy_ticket_sol`;
|
|
||||||
3. при необходимости ещё один вызов базового `buy_ticket`.
|
|
||||||
|
|
||||||
После каждой покупки:
|
|
||||||
|
|
||||||
- запросить состояние `Q1`;
|
|
||||||
- убедиться, что создался следующий ticket;
|
|
||||||
- проверить рост:
|
|
||||||
- `q1_tickets_total`;
|
|
||||||
- `q1_sum_total_usd_cents`;
|
|
||||||
- убедиться, что деньги покупки ушли в `dao_wallet`, а не в `inflow_vault`.
|
|
||||||
|
|
||||||
### 5. Проверка DAO-управления
|
|
||||||
|
|
||||||
Проверить:
|
|
||||||
|
|
||||||
1. изменение коэффициента через `update_coef_limit`;
|
|
||||||
2. повторный запрос `coef_limit` и подтверждение нового значения;
|
|
||||||
3. выдачу менеджеру прав через `grant_manager_limits`:
|
|
||||||
- отдельно под `Q1`;
|
|
||||||
- отдельно под `Q2`;
|
|
||||||
- отдельно под `Q3`.
|
|
||||||
|
|
||||||
После выдачи лимитов:
|
|
||||||
|
|
||||||
- считать `manager_allowance_pda`;
|
|
||||||
- убедиться, что лимиты записаны отдельно по трём очередям.
|
|
||||||
|
|
||||||
### 6. Проверка manager_add_ticket
|
|
||||||
|
|
||||||
На минимальных суммах создать менеджерские тикеты:
|
|
||||||
|
|
||||||
1. один ticket в `Q1`;
|
|
||||||
2. один ticket в `Q2`;
|
|
||||||
3. один ticket в `Q3`.
|
|
||||||
|
|
||||||
После каждого добавления:
|
|
||||||
|
|
||||||
- запросить состояние очередей;
|
|
||||||
- проверить рост счётчиков и сумм именно у нужной очереди;
|
|
||||||
- проверить уменьшение соответствующего manager allowance.
|
|
||||||
|
|
||||||
### 7. Проверка приоритета очередей
|
|
||||||
|
|
||||||
Подтвердить очередность `step_payout`:
|
|
||||||
|
|
||||||
1. сначала выплачивается `Q1`;
|
|
||||||
2. затем `Q2`;
|
|
||||||
3. затем `Q3`.
|
|
||||||
|
|
||||||
Для этого:
|
|
||||||
|
|
||||||
- между шагами регулярно читать `queues`;
|
|
||||||
- фиксировать, какой именно ticket был следующим к выплате;
|
|
||||||
- убедиться, что при наличии pending в `Q1` программа не уходит в `Q2` или `Q3`.
|
|
||||||
|
|
||||||
### 8. Проверка частичных выплат
|
|
||||||
|
|
||||||
Перед выплатами пополнять `inflow_vault` только минимально достаточными суммами.
|
|
||||||
|
|
||||||
Нужно проверить:
|
|
||||||
|
|
||||||
1. частичную серию выплат, когда часть тикетов ещё остаётся pending;
|
|
||||||
2. дополнительную покупку билета в промежутке между выплатами;
|
|
||||||
3. повторную проверку приоритета после появления нового билета в `Q1`.
|
|
||||||
|
|
||||||
После каждого `step_payout`:
|
|
||||||
|
|
||||||
- запрашивать состояние очередей;
|
|
||||||
- проверять:
|
|
||||||
- рост `tickets_paid`;
|
|
||||||
- рост `sum_paid_usd_cents`;
|
|
||||||
- `is_paid = true` у погашенного ticket;
|
|
||||||
- правильный DAO multiplier:
|
|
||||||
- `Q1 -> 1x`;
|
|
||||||
- `Q2 -> 2x`;
|
|
||||||
- `Q3 -> 3x`.
|
|
||||||
|
|
||||||
### 9. Проверка финального добора
|
|
||||||
|
|
||||||
После частичных выплат:
|
|
||||||
|
|
||||||
- купить ещё один билет;
|
|
||||||
- допополнить `inflow_vault`;
|
|
||||||
- выполнить оставшиеся `step_payout` до полного погашения всех трёх очередей.
|
|
||||||
|
|
||||||
В конце:
|
|
||||||
|
|
||||||
- все pending ticket должны отсутствовать;
|
|
||||||
- все суммы paid должны совпасть с total по каждой очереди;
|
|
||||||
- если вызвать `step_payout` на пустых очередях, доступный остаток `inflow_vault` должен уйти в `dao_wallet`.
|
|
||||||
|
|
||||||
### 10. Финальный возврат лампортов
|
|
||||||
|
|
||||||
После завершения теста вернуть все доступные остатки, которые можно вернуть текущими полномочиями, на базовый кошелёк:
|
|
||||||
|
|
||||||
- `FUc28vNixp7F3nnkpGVt6nuJbgvJ4429v4B5wS52Df6P`
|
|
||||||
|
|
||||||
Отдельно зафиксировать:
|
|
||||||
|
|
||||||
- что именно удалось вернуть;
|
|
||||||
- что именно нельзя вернуть без специальной инструкции закрытия или без deploy authority.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- `buy_ticket_usd` и `buy_ticket_sol` создают ticket без ошибок чтения state;
|
|
||||||
- `Q3` работает наравне с `Q2`, но с третьим приоритетом;
|
|
||||||
- DAO может менять коэффициент и выдавать лимиты;
|
|
||||||
- менеджер может создавать билеты во все три очереди;
|
|
||||||
- `step_payout` соблюдает порядок `Q1 -> Q2 -> Q3`;
|
|
||||||
- DAO-множитель на выплатах равен `1x/2x/3x` для `Q1/Q2/Q3`;
|
|
||||||
- HTML UI и on-chain программа используют один и тот же актуальный `program id`;
|
|
||||||
- остатки средств после теста по максимуму возвращены на базовый DAO-кошелёк.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
- `done`
|
|
||||||
|
|
||||||
## Итог выполнения
|
|
||||||
|
|
||||||
- новый `shine_payments` задеплоен в devnet с `program id`:
|
|
||||||
- `c4yTa4JT9EtQDCBX9LmWFK6T2gp4JGsuymFbom2EudW`
|
|
||||||
- старый `shine_payments`:
|
|
||||||
- `m48pWRGWrMj3TEHjuU4zsp5Gju4e7ZaPovk8RcVt7kR`
|
|
||||||
- закрыт, лампорты возвращены на базовый DAO-кошелёк
|
|
||||||
- HTML UI переведён на новый `program id`
|
|
||||||
- подтверждены:
|
|
||||||
- `init`
|
|
||||||
- `buy_ticket_usd`
|
|
||||||
- `buy_ticket_sol`
|
|
||||||
- `grant_manager_limits`
|
|
||||||
- `manager_add_ticket` для `Q1/Q2/Q3`
|
|
||||||
- `change_ticket_recipient`
|
|
||||||
- `update_coef_limit`
|
|
||||||
- `step_payout` по порядку `Q1 -> Q2 -> Q3`
|
|
||||||
- повторный возврат приоритета в `Q1` после новой покупки
|
|
||||||
- итоговые агрегаты очередей:
|
|
||||||
- `Q1 total=4, paid=4, sum_total=780, sum_paid=780`
|
|
||||||
- `Q2 total=1, paid=1, sum_total=60, sum_paid=60`
|
|
||||||
- `Q3 total=1, paid=1, sum_total=70, sum_paid=70`
|
|
||||||
- временные тестовые кошельки собраны обратно в базовый DAO-кошелёк
|
|
||||||
- в `inflow_vault` остался только rent-минимум PDA
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# Клиентская Solana-регистрация после ухода от Anchor
|
|
||||||
|
|
||||||
## Краткое описание
|
|
||||||
|
|
||||||
Исправлен рассинхрон обычного клиентского UI с no-Anchor ABI программ:
|
|
||||||
|
|
||||||
- `shine_login_guard`
|
|
||||||
- `shine_users`
|
|
||||||
|
|
||||||
Исправлены клиентские вызовы:
|
|
||||||
|
|
||||||
1. Solana-предпроверка логина в обычном UI.
|
|
||||||
2. `init_users_economy_config` в обычном UI.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
1. На странице регистрации проверка свободного логина не выдаёт `InvalidInstructionData`.
|
|
||||||
2. Для свободного обычного логина отображается корректный статус без fallback-предупреждения про недоступную Solana-предпроверку.
|
|
||||||
3. Регистрация пользователя через обычный UI проходит до конца.
|
|
||||||
4. Страница `Solana: init регистрации` в обычном UI отправляет корректную транзакцию и не падает из-за старого Anchor discriminator.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
1. `shine_login_guard` принимает клиентский precheck.
|
|
||||||
2. `init_users_economy_config` из обычного UI совместим с текущей программой `shine_users`.
|
|
||||||
3. Обычный клиентский UI ведёт себя так же, как серверный UI, там где используется общий no-Anchor путь.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
- `pending`
|
|
||||||
@ -1,32 +0,0 @@
|
|||||||
# ESP32 UI-прототип homeserver SHiNE
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
для `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. Прошить режим `homeserver-ui` и дождаться открытия главного экрана без PIN.
|
|
||||||
2. Проверить, что текст в заголовках, кнопках и статусах отображается читаемо; в текущей временной сборке допускается ASCII-транслитерация русского текста.
|
|
||||||
3. Открыть `Настройки` и убедиться, что показывается пометка о временно отключённом входе по PIN.
|
|
||||||
4. Открыть `Подключение -> Wi-Fi`, ввести `SSID` и пароль, нажать `Проверить`, дождаться реального подключения, затем перезагрузить устройство и проверить, что значения сохранились.
|
|
||||||
5. Открыть `Подключение -> Серверы`, проверить или изменить `API/RPC/WS`, нажать `Проверить` и убедиться, что показываются реальные статусы доступности, затем перезагрузить устройство и проверить сохранение значений.
|
|
||||||
6. Открыть `Аккаунт`, ввести логин, имя homeserver и нажать `Сгенерировать`; проверить, что появились секрет и адрес кошелька, а после перезагрузки они не исчезают.
|
|
||||||
7. Открыть `Кошелёк`, нажать `Проверить` и убедиться, что баланс реально читается из `Solana RPC`; затем открыть `QR и URI` и проверить, что QR-код отрисовывается и сканируется как `solana:`-ссылка.
|
|
||||||
8. При необходимости отдельно проверить тестовые кнопки `+/- SOL`: они меняют локальный баланс для UX-сценариев, но после следующей реальной RPC-проверки баланс должен вернуться к сетевому значению.
|
|
||||||
9. Вернуться на главный экран и проверить, что до выполнения всех условий кнопка регистрации недоступна, а после выполнения становится доступной; также убедиться, что между двумя нижними кнопками есть небольшой зазор.
|
|
||||||
10. Нажать кнопку регистрации и убедиться, что открывается отдельный экран проверки, где ещё раз видно `login`, статус свободного `PDA`, баланс, `homeserver1` с пометкой о стандартном значении и сообщение, если `Wi-Fi` не подключён.
|
|
||||||
11. На экране проверки нажать `REGISTER IN SHINE` и убедиться, что после этого появляется отдельный экран результата с успехом либо подробной ошибкой.
|
|
||||||
12. После успешной регистрации проверить через `Solana`/UI проекта, что `user_pda` для этого логина реально создана, сохранена в `NVS` и соответствует `device`-адресу устройства, а `tx signature` тоже сохранён.
|
|
||||||
13. После успешной регистрации вернуться на `HOME` и проверить новую жёлтую кнопку:
|
|
||||||
- если в `PDA` ещё нет текущего homeserver, должна появиться `ADD HOMESERVER`;
|
|
||||||
- если ключ homeserver в `PDA` не совпадает с локальным секретом, должна появиться `FIX HOMESERVER PASSWORD`.
|
|
||||||
14. Нажать жёлтую кнопку и убедиться, что открывается отдельный экран пояснения, а затем экран результата обновления `PDA`.
|
|
||||||
15. После успешного `ADD/FIX HOMESERVER` проверить, что основной экран больше не показывает `homeserver not in PDA` или `homeserver key mismatch`, а `SHiNE` может перейти к авторизации.
|
|
||||||
16. Открыть `Запросы`, поочерёдно открыть оба демонстрационных запроса и проверить, что кнопки `Разрешить` и `Отклонить` меняют их статус.
|
|
||||||
17. При необходимости открыть `Настройки -> Сменить PIN` и убедиться, что новый PIN сохраняется, хотя вход по PIN временно не используется на старте.
|
|
||||||
18. Выполнить `Полный сброс` и убедиться, что все поля, секрет, баланс, онлайн и регистрация очищаются.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
новый `ESP32`-скетч стабильно запускается, показывает читаемый англоязычный интерфейс, сохраняет данные во внутренней памяти устройства, реально подключается к `Wi-Fi`, реально проверяет `API/RPC/WS`, реально читает баланс из `Solana RPC`, рисует рабочий `QR` для `solana:`-URI, позволяет вручную пройти on-chain регистрацию пользователя и затем отдельным действием записать/исправить homeserver-сессию в `shine_users`.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,13 +0,0 @@
|
|||||||
# ESP32 авто-прошивка shine_homeserver_ui
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
добавлен исполняемый скрипт `flash_shine_homeserver_main.sh`, который автоматически ищет USB-порт `ESP32` и запускает заливку прошивки `shine_homeserver_ui` без ручного указания `PORT`.
|
|
||||||
- что именно проверять:
|
|
||||||
1. Подключить плату `ESP32` по USB.
|
|
||||||
2. Перейти в папку `ESP32/esp32/ESP32-S3-Touch-AMOLED-2.16/main-device/`.
|
|
||||||
3. Запустить `./flash_shine_homeserver_main.sh`.
|
|
||||||
4. Убедиться, что скрипт сам показывает найденный порт и успешно запускает compile/upload.
|
|
||||||
- ожидаемый результат:
|
|
||||||
скрипт без ручного ввода порта находит `ESP32`, печатает найденный `/dev/ttyACM*` или `/dev/ttyUSB*` и заливает `shine_homeserver_ui`.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,14 +0,0 @@
|
|||||||
# ESP32 тест рендера текста
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
добавлен отдельный диагностический скетч `text_render_test`, который показывает один экран с несколькими вариантами вывода текста: встроенный шрифт `Arduino_GFX`, `U8g2` ASCII, `U8g2` кириллица и кнопки с подписями. Скрипт нужен для изоляции проблемы, когда на экране видны только цветные кнопки и блоки, но не видно ни одной буквы.
|
|
||||||
- что именно проверять:
|
|
||||||
1. Прошить режим `text-test`.
|
|
||||||
2. Проверить, виден ли заголовок `TEXT TEST 123`.
|
|
||||||
3. Проверить, видны ли строки `A`, `B`, `C`, `D`.
|
|
||||||
4. Проверить, видны ли подписи на трёх нижних кнопках: `BTN 1`, `abc123`, `Русский`.
|
|
||||||
5. Сравнить, какой из способов вывода реально отображается, а какой нет.
|
|
||||||
- ожидаемый результат:
|
|
||||||
хотя бы один вариант вывода текста становится видим на экране, что позволяет локализовать проблему до конкретного шрифта или способа рендера.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,12 +0,0 @@
|
|||||||
# ESP32 PIN-клавиатура: подписи кнопок
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
в UI-скетче `shine_homeserver_ui` изменена отрисовка подписей кнопок. Вместо малого шрифта теперь используется более стабильный шрифт с явным центрированием текста внутри кнопок, чтобы на экране ввода PIN и других экранах не пропадали цифры и надписи.
|
|
||||||
- что именно проверять:
|
|
||||||
1. Включить устройство и дождаться экрана ввода PIN.
|
|
||||||
2. Убедиться, что на всех серых кнопках видны цифры `0-9`, `Отмена` и `OK`.
|
|
||||||
3. Открыть другие экраны с кнопками (`Главный экран`, `Wi-Fi`, `Серверы`, `Настройки`) и убедиться, что подписи отображаются и не уезжают за границы кнопок.
|
|
||||||
- ожидаемый результат:
|
|
||||||
подписи кнопок стабильно видны сразу после старта, текст визуально центрирован, пустых серых кнопок без цифр и названий нет.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,13 +0,0 @@
|
|||||||
# ESP32 папка тестовых скетчей
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
добавлена отдельная папка `test_sketches/` с изолированными диагностическими скетчами для экрана `ESP32-S3-Touch-AMOLED-2.16`: тест рендера текста через `Arduino_GFX`, тест геометрии кнопок и минимальный тест `LVGL`.
|
|
||||||
- что именно проверять:
|
|
||||||
1. Запустить `./burn.sh gfx-text-test` и убедиться, что прошивается тест текста из новой папки.
|
|
||||||
2. Запустить `./burn.sh gfx-layout-test` и проверить нижние ряды кнопок.
|
|
||||||
3. Запустить `./burn.sh lvgl-basic-test` и проверить, что `LVGL` показывает текст и кнопки.
|
|
||||||
4. Убедиться, что новая папка не мешает сборке `homeserver-ui`.
|
|
||||||
- ожидаемый результат:
|
|
||||||
тестовые скетчи лежат отдельно от основного UI, шьются отдельными режимами и позволяют быстро проверять разные гипотезы по экрану без правок в `shine_homeserver_ui`.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,14 +0,0 @@
|
|||||||
# ESP32 LVGL interaction test
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
добавлен отдельный скетч `lvgl_interaction_test` на `LVGL`: экран с 9 кнопками, touch-вводом и нижней статусной строкой. При нажатии на кнопку на экране и в `Serial` показывается, какая именно кнопка нажата и сколько нажатий уже было.
|
|
||||||
- что именно проверять:
|
|
||||||
1. Прошить режим `lvgl-interaction-test`.
|
|
||||||
2. Убедиться, что виден заголовок, подзаголовок, 9 кнопок и нижняя статусная панель.
|
|
||||||
3. Поочерёдно нажать разные кнопки.
|
|
||||||
4. Проверить, что нижняя строка меняется на `Pressed: <button> (#N)`.
|
|
||||||
5. Проверить, что touch устойчиво работает по всей сетке кнопок.
|
|
||||||
- ожидаемый результат:
|
|
||||||
`LVGL` стабильно рисует плотный экран с множеством кнопок, а нажатия корректно обрабатываются и визуально подтверждаются без глюков позиционирования.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,14 +0,0 @@
|
|||||||
# ESP32 LVGL touch debug test
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
добавлен отдельный диагностический скетч `lvgl_touch_debug_test`, который одновременно показывает сырые координаты touch, маркер точки касания и одну большую кнопку `LVGL`. Он нужен, чтобы отделить проблему raw-touch от проблемы доставки событий в `LVGL`.
|
|
||||||
- что именно проверять:
|
|
||||||
1. Прошить режим `lvgl-touch-debug-test`.
|
|
||||||
2. Коснуться экрана в разных местах.
|
|
||||||
3. Проверить, меняется ли текст `RAW pressed` и координаты `x/y`.
|
|
||||||
4. Проверить, появляется ли розовый маркер точки касания.
|
|
||||||
5. Проверить, срабатывает ли большая кнопка `Tap Here` и меняется ли строка `LVGL button clicked`.
|
|
||||||
- ожидаемый результат:
|
|
||||||
становится ясно, работает ли сам touch-драйвер, правильно ли приходят координаты и доходит ли нажатие до кнопки `LVGL`.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,13 +0,0 @@
|
|||||||
# ESP32 LVGL official based test
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
добавлен отдельный скетч `lvgl_official_based_test`, который строится на максимально близкой к официальному `05_LVGL_Widgets` инициализации `display + touch + LVGL`, но вместо официального demo рисует наш компактный экран с кнопками и статусом нажатия.
|
|
||||||
- что именно проверять:
|
|
||||||
1. Прошить режим `lvgl-official-based-test`.
|
|
||||||
2. Убедиться, что экран отображается без артефактов по краям.
|
|
||||||
3. Нажать разные кнопки и проверить, меняется ли нижняя строка `Pressed: ...`.
|
|
||||||
4. Проверить, идут ли координаты touch в `Serial`.
|
|
||||||
- ожидаемый результат:
|
|
||||||
если официальный каркас инициализации действительно является рабочей базой, то на этом тесте должны заработать и touch, и кнопки, и исчезнуть визуальные артефакты, которые были в наших самодельных `LVGL`-тестах.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,12 +0,0 @@
|
|||||||
# LVGL Russian font test
|
|
||||||
|
|
||||||
- Краткое описание: тест кастомного `LVGL`-шрифта с кириллицей на базе рабочего `LVGL + subserver touch` контура.
|
|
||||||
- Что проверять:
|
|
||||||
- на экране видны русские заголовки и подписи без транслита;
|
|
||||||
- отображаются буквы `Ё/ё`;
|
|
||||||
- видны кнопки `Статус`, `Подключение`, `Кошелёк`, `Запросы`, `Настройки`, `Регистрация`, `Разрешить`, `Отклонить`, `Назад`;
|
|
||||||
- длинная кнопка `Проверка переноса русского текста` отображается читаемо;
|
|
||||||
- строка `Нажато:` меняется при клике;
|
|
||||||
- строка `Касание:` меняется при касании.
|
|
||||||
- Ожидаемый результат: кириллица стабильно отображается на `LVGL`-экране и не ломает touch.
|
|
||||||
- Статус: pending
|
|
||||||
@ -1,104 +0,0 @@
|
|||||||
# ESP32 nav minimal test
|
|
||||||
|
|
||||||
- Краткое описание: легаси-заметка по старому навигационному тесту UI для homeserver на базе `LVGL + subserver touch`. Актуальный основной скетч уже переехал в `shine_homeserver_main/`, а этот файл оставлен как историческая справка по старой версии.
|
|
||||||
- Что проверять:
|
|
||||||
- стартует экран `HOME`;
|
|
||||||
- на `HOME` видны реальное значение homeserver или `homeserver not set`, реальное значение логина или `login not set`, при отсутствии секрета строка `secret not set`, а также `STATUS`, верхний правый блок с процентом батареи, иконкой батареи и индикатором Wi-Fi, кнопка баланса, строка `SHiNE: ...`, кнопка `SETTINGS` уменьшенной ширины у правого края и нижняя подпись `SHiNE homeserver (v.0.18)`;
|
|
||||||
- справа от строки логина виден индикатор статуса Solana-аккаунта:
|
|
||||||
- зелёный, если ключи совпали;
|
|
||||||
- красный, если mismatch;
|
|
||||||
- белый контур, если пользователь не найден;
|
|
||||||
- если статус не зелёный, рядом выводится краткое текстовое пояснение;
|
|
||||||
- строка Wi-Fi на `HOME` корректно показывает одно из состояний:
|
|
||||||
- `Wi-Fi (not configured) not configured`
|
|
||||||
- `Wi-Fi (<saved_ssid>) disconnected`
|
|
||||||
- `Wi-Fi (<current_ssid>) connected`
|
|
||||||
- строка `SHiNE:` корректно показывает одно из состояний:
|
|
||||||
- `connected`
|
|
||||||
- `account not configured`
|
|
||||||
- `unavailable`
|
|
||||||
- пока открыт `HOME`, статус сам обновляется без перехода на другие экраны;
|
|
||||||
- баланс обновляется кнопкой по нажатию;
|
|
||||||
- если логин зарегистрирован и секрет/homeserver заданы, устройство:
|
|
||||||
- читает `user_pda` через Solana RPC;
|
|
||||||
- сверяет `root`, `blockchain`, `device` и `homeserver` session type `100`;
|
|
||||||
- поднимает WebSocket-сессию с сервером SHiNE;
|
|
||||||
- шлёт `Ping` раз в минуту;
|
|
||||||
- кнопка `SETTINGS` открывает `SETTINGS_MENU`;
|
|
||||||
- свайп влево на `HOME` открывает `SETTINGS_MENU`;
|
|
||||||
- если пользователь не найден в Solana PDA, слева снизу появляется `REGISTER ACCOUNT`;
|
|
||||||
- `REGISTER ACCOUNT` открывает экран-заглушку только в старой тестовой версии;
|
|
||||||
- в `SETTINGS_MENU` сначала видны только `Wi-Fi` и `Server`;
|
|
||||||
- обе видимые карточки меню одного цвета;
|
|
||||||
- свайп вверх показывает `Server` и `Account`;
|
|
||||||
- свайп вниз возвращает `Wi-Fi` и `Server`;
|
|
||||||
- свайп вправо из `SETTINGS_MENU` возвращает на `HOME`;
|
|
||||||
- нажатие `Wi-Fi` открывает `WIFI_SCREEN`;
|
|
||||||
- `SELECT NETWORK` запускает скан;
|
|
||||||
- после скана показывается список доступных SSID;
|
|
||||||
- выбор SSID открывает общий экран редактирования текста для пароля;
|
|
||||||
- если для этого SSID пароль уже сохранялся раньше, он автоматически подставляется в редактор;
|
|
||||||
- если затем ввести пароль для другого SSID, пароль первой сети не теряется;
|
|
||||||
- одновременно хранится до `8` паролей для разных SSID;
|
|
||||||
- на этом экране видно старое значение, курсор стоит в конце;
|
|
||||||
- две верхние служебные строки над полем ввода отсутствуют;
|
|
||||||
- при вводе пароля Wi-Fi текст показывается открыто, без точек;
|
|
||||||
- большая клавиатура реально видна на экране и занимает большую часть высоты;
|
|
||||||
- буквы разбиты на 2 страницы;
|
|
||||||
- режим символов тоже разбит на 2 страницы;
|
|
||||||
- на правой странице кнопки стоят в ровных вертикальных колонках;
|
|
||||||
- свайп влево/вправо на экране ввода переключает страницы клавиатуры;
|
|
||||||
- при этом свайп страниц клавиатуры срабатывает только из нижней клавиатурной зоны, а не из верхней части экрана;
|
|
||||||
- при переключении `ABC/123` и `SHIFT` уже введённый текст не пропадает;
|
|
||||||
- при свайпе между левой и правой половиной клавиатуры уже введённый текст тоже не пропадает, в том числе для цифр, символов и заглавных букв;
|
|
||||||
- визуальный курсор в поле ввода не показывается;
|
|
||||||
- новые символы всегда дописываются только в конец строки;
|
|
||||||
- основные 3 ряда клавиш и нижний служебный ряд стали выше;
|
|
||||||
- внизу остаётся отдельная тёмная полоса с версией `SHiNE homeserver (v.0.18)`, а рамка клавиатурного блока заканчивается выше неё;
|
|
||||||
- одно непрерывное касание вызывает не более одного действия кнопки;
|
|
||||||
- скольжение пальцем по клавиатуре не нажимает подряд несколько клавиш;
|
|
||||||
- медленный свайп по экрану не должен превращаться в случайное нажатие кнопки;
|
|
||||||
- `ABC/123`, `SHIFT`, `DEL`, `SAVE`, `CANCEL` работают;
|
|
||||||
- при успехе SSID и пароль сохраняются, а `HOME` показывает `Wi-Fi connected`;
|
|
||||||
- если после подключения ко второй сети снова выбрать первую, её старый пароль уже подставлен и достаточно нажать `SAVE`;
|
|
||||||
- при ошибке показывается `Connection failed`;
|
|
||||||
- `CLEAR SAVED WI-FI` очищает сохранённые настройки;
|
|
||||||
- если сеть была ранее успешно сохранена, после потери связи устройство автоматически пытается переподключиться;
|
|
||||||
- первые повторные попытки идут раз в `10` секунд, а после долгого отсутствия связи интервал увеличивается до `30` секунд;
|
|
||||||
- нажатие `Server` открывает `SERVER_SCREEN`;
|
|
||||||
- в `SERVER_SCREEN` видны и редактируются два значения:
|
|
||||||
- `https://api.devnet.solana.com`
|
|
||||||
- `https://shineup.me`
|
|
||||||
- нажатие `SOLANA RPC` открывает общий экран редактирования;
|
|
||||||
- нажатие `SHINE SERVER` открывает общий экран редактирования;
|
|
||||||
- после `SAVE` новые адреса сохраняются в NVS;
|
|
||||||
- нажатие `Account` открывает `ACCOUNT_SCREEN`;
|
|
||||||
- `ACCOUNT_SCREEN` показывает 3 кнопки:
|
|
||||||
- `Login (<value|not set>)`
|
|
||||||
- `Homeserver (<value|not set>)`
|
|
||||||
- `Secret (<*****|not set>)`
|
|
||||||
- `Login` открывает общий экран редактирования и сохраняется в NVS;
|
|
||||||
- `Homeserver` открывает промежуточный экран с `USE HOMESERVER1` и `EDIT MANUALLY`;
|
|
||||||
- `USE HOMESERVER1` возвращает стандартное значение `homeserver1`;
|
|
||||||
- `EDIT MANUALLY` открывает общий экран редактирования и сохраняет значение в NVS;
|
|
||||||
- `Secret` теперь открывает меню секрета с показом секрета, ручным вводом и генерацией;
|
|
||||||
- в `SHOW SECRET` показывается прокручиваемый список всех ключей:
|
|
||||||
- `Secret (base58)`
|
|
||||||
- `Root key (base58)`
|
|
||||||
- `Root key priv (base58)`
|
|
||||||
- `Blockchain key (base58)`
|
|
||||||
- `Blockchain key priv (base58)`
|
|
||||||
- `Device key (base58)`
|
|
||||||
- `Device key priv (base58)`
|
|
||||||
- `Homeserver key (base58)`
|
|
||||||
- `Homeserver key priv (base58)`
|
|
||||||
- значения ключей показываются полными строками увеличенным шрифтом;
|
|
||||||
- при смене `login` сохранённый секрет сбрасывается в `not set`;
|
|
||||||
- во время генерации секрета есть `CANCEL` и подтверждение остановки;
|
|
||||||
- при отмене генерации старый секрет, если он был, не должен теряться;
|
|
||||||
- свайп вправо из внутренних экранов возвращает в `SETTINGS_MENU`;
|
|
||||||
- свайп вправо из `ACCOUNT_HOMESERVER_SCREEN` и `ACCOUNT_SECRET_SCREEN` возвращает в `ACCOUNT_SCREEN`;
|
|
||||||
- если во время реального свайпа палец проходит по кнопке, это не должно открывать кнопку как обычный `click`.
|
|
||||||
- Ожидаемый результат: новый скетч даёт чистый навигационный каркас и уже умеет настраивать Wi-Fi и серверные адреса на самой ESP32.
|
|
||||||
- Дополнительно ожидается: `HOME` уже показывает реальный Solana/WS-статус homeserver, а отсутствие пользователя в Solana заметно сразу без перехода в настройки.
|
|
||||||
- Статус: done
|
|
||||||
@ -1,16 +0,0 @@
|
|||||||
# Deeplink ссылки профиля и связей
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
Исправлена загрузка UI по прямым ссылкам вида `https://shineup.me/shine.<login>` и `https://shineup.me/shine.<login>/links` через добавление корневого `<base href="/">` в основной `index.html`.
|
|
||||||
- что проверять:
|
|
||||||
1. Открыть прямую ссылку на профиль в новой вкладке: `https://shineup.me/shine.<login>`.
|
|
||||||
2. Открыть прямую ссылку на связи в новой вкладке: `https://shineup.me/shine.<login>/links`.
|
|
||||||
3. Повторить оба сценария в состоянии гостя.
|
|
||||||
4. Повторить оба сценария в состоянии, когда в браузере залогинен другой пользователь.
|
|
||||||
- ожидаемый результат:
|
|
||||||
1. Страница загружается напрямую без поломки ассетов и без ухода на неверный экран.
|
|
||||||
2. Открывается профиль/связи именно пользователя из URL.
|
|
||||||
3. Для гостя экран открывается в read-only режиме.
|
|
||||||
4. Для залогиненного другого пользователя URL не подменяется на текущую сессию.
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,33 +0,0 @@
|
|||||||
# Запрет получателя тикета, равного inflow-вольту (защита от заморозки очереди)
|
|
||||||
|
|
||||||
## Краткое описание
|
|
||||||
Закрыта HIGH-находка второго аудита (`Dev_Docs/audit/Solana-audit-2-by-Claude-11июня2026.md`).
|
|
||||||
Тикет с `recipient_wallet == адрес inflow_vault` приводил к алиасингу аккаунта в
|
|
||||||
`step_payout` (вольт одновременно источник и получатель), второй mutable-займ
|
|
||||||
лампортов в `transfer_from_vault` падал, и такой тикет навсегда блокировал
|
|
||||||
обслуживание очереди и замораживал средства вольта.
|
|
||||||
|
|
||||||
Исправление в `shine_payments`:
|
|
||||||
- `buy_ticket_by_purchase_usd` — `require!(recipient_wallet != config.inflow_vault)`;
|
|
||||||
- `process_manager_add_ticket` — запрет через `find_single_pda(INFLOW_VAULT_SEED)`;
|
|
||||||
- `process_change_ticket_recipient` — тот же запрет для `new_recipient_wallet`;
|
|
||||||
- `transfer_from_vault` — защита по умолчанию `require!(vault.key != recipient.key)`.
|
|
||||||
|
|
||||||
Ошибка во всех случаях — `InvalidTicketRecipient`.
|
|
||||||
|
|
||||||
## Что проверять (devnet/localnet)
|
|
||||||
1. Покупка тикета с `recipient_wallet = <адрес inflow_vault PDA>` → отклоняется
|
|
||||||
(`InvalidTicketRecipient`), тикет не создаётся.
|
|
||||||
2. `manager_add_ticket` с тем же recipient → отклоняется.
|
|
||||||
3. `change_ticket_recipient` с `new_recipient = inflow_vault` → отклоняется.
|
|
||||||
4. Обычные покупки/выплаты с нормальным получателем → работают как раньше, очередь
|
|
||||||
обслуживается, `step_payout` выплачивает корректно.
|
|
||||||
5. Регресс не затронул выплаты в `dao_wallet` и `call_reward` подписанту (их адреса
|
|
||||||
не совпадают с вольтом).
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
Тикет с получателем-вольтом невозможно создать; ранее существовавший вектор
|
|
||||||
перманентной заморозки очереди закрыт. Прочая логика выплат без изменений.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
pending
|
|
||||||
@ -1,32 +0,0 @@
|
|||||||
# Устойчивое создание PDA (защита от «минирования» адреса)
|
|
||||||
|
|
||||||
## Краткое описание
|
|
||||||
В `shine_payments` и `shine_users` функция `create_pda_account` переведена с жёсткого
|
|
||||||
`system_instruction::create_account` на паттерн «создание поверх предзаполненного»:
|
|
||||||
- если на детерминированном адресе будущего PDA нет лампортов — обычный `create_account`;
|
|
||||||
- если лампорты уже есть («подсев» атакующим) — добор ренты переводом, затем
|
|
||||||
`allocate` + `assign` под подписью PDA.
|
|
||||||
|
|
||||||
Дополнительно в `shine_payments` `is_uninitialized_account` перестала требовать нулевой
|
|
||||||
баланс (проверяет только пустые данные + владельца System Program).
|
|
||||||
|
|
||||||
Это закрывает последний (LOW) пункт аудита: griefing-DoS на покупку тикетов и сквоттинг
|
|
||||||
логинов через предсказуемые адреса PDA.
|
|
||||||
|
|
||||||
## Что проверять (devnet/localnet)
|
|
||||||
1. Обычная покупка тикета без «подсева» — создаётся как раньше (быстрый путь).
|
|
||||||
2. На адрес следующего тикета заранее переведены лампорты обычным system-переводом →
|
|
||||||
покупка/`manager_add_ticket` всё равно проходит, тикет создаётся корректно, данные
|
|
||||||
и владелец = program id.
|
|
||||||
3. На адрес `user_pda` будущего логина заранее переведены лампорты → регистрация логина
|
|
||||||
(`create_user_pda`) всё равно проходит; запись и комиссия корректны.
|
|
||||||
4. Повторная инициализация уже существующего тикета/пользователя по-прежнему отклоняется
|
|
||||||
(`PdaAlreadyExists` / `UserAlreadyExists`).
|
|
||||||
5. Singleton-PDA (`init`, economy config) и manager allowance создаются без регрессий.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
Подсев лампортов на заранее известный адрес PDA не блокирует создание; вся остальная
|
|
||||||
экономика и проверки повторной инициализации работают как прежде.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
pending
|
|
||||||
@ -1,45 +0,0 @@
|
|||||||
# ESP32 USB-диагностика регистрации Solana
|
|
||||||
|
|
||||||
- статус: `pending`
|
|
||||||
|
|
||||||
## Что сделано
|
|
||||||
|
|
||||||
- В основной скетч `shine_homeserver_main` добавено сохранение последней диагностики регистрации Solana в `Preferences`.
|
|
||||||
- Добавлены USB-команды через `Serial`:
|
|
||||||
- `last_error`
|
|
||||||
- `last_diag`
|
|
||||||
- `reg_diag`
|
|
||||||
- `clear_error`
|
|
||||||
- `clear_diag`
|
|
||||||
- `help`
|
|
||||||
- Перед отправкой `create_user_pda` добавлена RPC-проверка `users_economy_config_pda`.
|
|
||||||
- Стартовый `paid_limit_bytes` в подписываемой записи теперь берётся из on-chain `users_economy_config`, а не из хардкода.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
1. Подключить устройство по USB.
|
|
||||||
2. Открыть последовательный порт `115200`.
|
|
||||||
3. Отправить команду `last_error`.
|
|
||||||
4. Убедиться, что устройство печатает сохранённую диагностику между маркерами:
|
|
||||||
- `LAST_REGISTER_DIAG_BEGIN`
|
|
||||||
- `LAST_REGISTER_DIAG_END`
|
|
||||||
5. Запустить регистрацию с устройства и дождаться ошибки или успеха.
|
|
||||||
6. Снова отправить `last_error`.
|
|
||||||
7. Проверить, что в диагностике есть:
|
|
||||||
- `status`
|
|
||||||
- `summary`
|
|
||||||
- `rpc`
|
|
||||||
- `user_pda`
|
|
||||||
- `users_economy_config_pda`
|
|
||||||
- `inflow_vault_pda`
|
|
||||||
- `root_pub`
|
|
||||||
- `blockchain_pub`
|
|
||||||
- `device_pub`
|
|
||||||
8. При ошибке `0x3` проверить, что текст стал конкретнее и помогает понять, какая PDA или RPC-конфигурация не совпала.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- Последняя ошибка регистрации читается по USB без просмотра экрана.
|
|
||||||
- После неудачной регистрации на устройстве остаётся подробная диагностическая запись.
|
|
||||||
- Если `users_economy_config_pda` отсутствует или принадлежит не той программе, это явно видно до отправки транзакции.
|
|
||||||
|
|
||||||
@ -1,26 +0,0 @@
|
|||||||
# ESP32 полный текст ошибки регистрации Solana
|
|
||||||
|
|
||||||
- статус: `pending`
|
|
||||||
|
|
||||||
## Что сделано
|
|
||||||
|
|
||||||
- Локальные правки Solana-программ для диагностических `failed at ...` логов откатены.
|
|
||||||
- В основном ESP32-скетче сохранение последней ошибки регистрации переведено на полный текст RPC-диагностики.
|
|
||||||
- В `details` теперь сохраняются полные payload:
|
|
||||||
- `send_transaction_payload`
|
|
||||||
- `simulate_payload`
|
|
||||||
- Длинный текст ошибки сохраняется в `Preferences` по частям, чтобы не теряться из-за лимита одной строки.
|
|
||||||
- Чтение по USB-команде `last_error` / `last_diag` / `reg_diag` выводит сохранённый текст целиком.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
1. Запустить регистрацию на устройстве до ошибки.
|
|
||||||
2. По USB отправить `last_error`.
|
|
||||||
3. Проверить, что в ответе есть полный JSON/текст `sendTransaction` и `simulateTransaction`, а не только короткий summary.
|
|
||||||
4. Убедиться, что текст после перезагрузки устройства остаётся доступным через ту же команду.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- Последняя ошибка регистрации читается по USB почти целиком.
|
|
||||||
- Если Solana уже вернула строку с местом падения, она не теряется из-за агрессивного обрезания на ESP32.
|
|
||||||
|
|
||||||
@ -1,16 +0,0 @@
|
|||||||
# ESP32 sessionType homeserver
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
- `ESP32` homeserver теперь должен отправлять в `CreateAuthSession` и `SessionLogin` поля `sessionType = 100` и `clientPlatform = "ESP32"`.
|
|
||||||
|
|
||||||
- что проверять:
|
|
||||||
- после перепрошивки устройство должно заново подключиться к `SHiNE`;
|
|
||||||
- в списке устройств у этой сессии должен отображаться тип `Homeserver` и платформа `ESP32`;
|
|
||||||
- детальная страница сеанса должна показывать те же значения.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
- сервер принимает homeserver-сеанс без ошибки `SESSION_TYPE_MISMATCH`;
|
|
||||||
- UI сервера/клиента показывает `Homeserver · ESP32`.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
- in_progress
|
|
||||||
@ -1,16 +0,0 @@
|
|||||||
# online flag в ListSessions
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
- серверный `ListSessions` теперь возвращает флаг `isOnlineOnThisServer` для каждой сессии;
|
|
||||||
- клиентский UI показывает его и в списке устройств, и на подробной странице сеанса.
|
|
||||||
|
|
||||||
- что проверять:
|
|
||||||
- у текущего web-клиента в списке должен быть статус `Online now`;
|
|
||||||
- у активной `ESP32`-сессии должен быть статус `Online now`, пока устройство подключено;
|
|
||||||
- после ручного закрытия одной из сессий её статус должен стать `Offline`.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
- online-флаг соответствует живому наличию `WebSocket`-контекста на этом сервере, а не только данным БД.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
- in_progress
|
|
||||||
@ -1,24 +0,0 @@
|
|||||||
# ESP32: добавление и исправление homeserver в user PDA
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
в основном ESP32-скетче добавлен отдельный flow после регистрации пользователя: если homeserver-сессия отсутствует в `shine_users` PDA или её ключ не совпадает с локальным секретом, на главном экране показывается жёлтая кнопка `ADD HOMESERVER` или `FIX HOMESERVER PASSWORD`. Действие открывает отдельный экран объяснения, затем отправляет `update_user_pda` и показывает экран результата.
|
|
||||||
|
|
||||||
- что именно проверять:
|
|
||||||
1. Зарегистрировать пользователя или взять уже существующего пользователя без корректной homeserver-сессии.
|
|
||||||
2. На `HOME` убедиться, что вместо кнопки регистрации появилась жёлтая кнопка:
|
|
||||||
`ADD HOMESERVER` либо `FIX HOMESERVER PASSWORD`.
|
|
||||||
3. Нажать её и проверить, что открывается отдельный экран с пояснением причины и кнопкой действия.
|
|
||||||
4. Выполнить действие и дождаться экрана результата.
|
|
||||||
5. После успеха проверить, что:
|
|
||||||
- `homeserver not in PDA` или `homeserver key mismatch` исчезли;
|
|
||||||
- в USB-диагностике есть успешный `tx_signature`;
|
|
||||||
- `SHiNE` может перейти к авторизации на сервере.
|
|
||||||
6. Если действие завершается ошибкой, проверить, что:
|
|
||||||
- текст ошибки показан на экране результата;
|
|
||||||
- команда `last_error` по USB возвращает полный сохранённый payload.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
устройство после обычной регистрации пользователя способно отдельной транзакцией добавить или исправить homeserver-сессию в `shine_users` PDA, а ошибки этого шага сохраняются в ту же USB/NVS-диагностику.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,21 +0,0 @@
|
|||||||
# sessionType API и UI
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
- серверный API авторизации и списка сессий расширен полями `sessionType` и `clientPlatform`;
|
|
||||||
- сервер сверяет `sessionType` с записью в Solana `PDA`, если для данного `sessionKey` уже есть `SessionRecord`;
|
|
||||||
- `shine-UI` теперь отправляет `sessionType=1` и `clientPlatform=Web`, а также показывает тип/платформу в экранах сессий;
|
|
||||||
- в документации Solana `PDA` добавлен тип `50` для `wallet`.
|
|
||||||
|
|
||||||
- что проверять:
|
|
||||||
- вход через `CreateAuthSession` и повторный вход через `SessionLogin`;
|
|
||||||
- ответ `ListSessions` должен содержать `sessionType` и `clientPlatform`;
|
|
||||||
- в UI "Устройства" должен отображаться тип сессии и платформа;
|
|
||||||
- при искусственном несовпадении `sessionType` с `PDA` сервер должен вернуть `460 / SESSION_TYPE_MISMATCH`.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
- обычный web-клиент успешно создаёт/возобновляет сессию с `sessionType=1`;
|
|
||||||
- список сессий возвращает новые поля;
|
|
||||||
- несовпадение типа с `PDA` даёт явную прикладную ошибку `460`.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
- in_progress
|
|
||||||
@ -1,20 +0,0 @@
|
|||||||
# ESP32 wallet QR button
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
- на `HOME` кнопка баланса стала уже;
|
|
||||||
- справа появилась отдельная кнопка с иконкой `QR`;
|
|
||||||
- по нажатию открывается экран с QR-кодом `solana:<wallet>` и подписью адреса;
|
|
||||||
- тап по любому месту экрана возвращает на главный экран.
|
|
||||||
|
|
||||||
- что именно проверять:
|
|
||||||
- на `HOME` кнопка баланса визуально уже прежней;
|
|
||||||
- справа от неё есть отдельная кнопка с QR-иконкой;
|
|
||||||
- QR-экран открывается по нажатию;
|
|
||||||
- QR сканируется кошельком как `solana:` URI;
|
|
||||||
- тап по экрану QR возвращает на `HOME`.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
- пользователь может быстро показать адрес кошелька для пополнения без захода в дополнительные экраны.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
- pending
|
|
||||||
@ -1,28 +0,0 @@
|
|||||||
# ESP32 wallet QR через LVGL
|
|
||||||
|
|
||||||
- Статус: `pending`
|
|
||||||
|
|
||||||
## Что сделано
|
|
||||||
|
|
||||||
- для `WALLET_QR` включён штатный `LVGL`-виджет `lv_qrcode`;
|
|
||||||
- кнопка на главном экране оставлена текстовой `QR`;
|
|
||||||
- экран должен показывать реальный крупный `QR` для `solana:<wallet_address>`;
|
|
||||||
- адрес кошелька под `QR` увеличен;
|
|
||||||
- тап по экрану должен возвращать на `HOME`, без перезагрузки устройства и без потери `Wi-Fi`/`SHiNE`.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
1. На главном экране нажать кнопку `QR`.
|
|
||||||
2. Убедиться, что открывается экран `WALLET QR`.
|
|
||||||
3. Проверить, что виден настоящий QR-код.
|
|
||||||
4. Проверить, что под `QR` крупно показан адрес кошелька.
|
|
||||||
5. Нажать в любое место экрана и убедиться, что устройство возвращается на `HOME`.
|
|
||||||
6. Убедиться, что после открытия и закрытия QR-экрана не рвутся `Wi-Fi` и подключение к `SHiNE`.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- QR-экран открывается стабильно;
|
|
||||||
- QR-код читается приложением кошелька;
|
|
||||||
- размер `QR` и адреса визуально достаточен для удобного сканирования;
|
|
||||||
- возврат на главный экран работает обычным тапом;
|
|
||||||
- устройство не перезагружается, сетевые подключения не теряются.
|
|
||||||
@ -1,29 +0,0 @@
|
|||||||
# ESP32 home status layout и авто-баланс
|
|
||||||
|
|
||||||
- Статус: `pending`
|
|
||||||
|
|
||||||
## Что сделано
|
|
||||||
|
|
||||||
- на `HOME` блок `STATUS` поднят выше;
|
|
||||||
- строка логина теперь идёт после статусного кружка, сам кружок расположен слева;
|
|
||||||
- строка `Wi-Fi` показывает `Wi-Fi: <SSID> connected|disconnected`;
|
|
||||||
- строка `SHiNE` показывает `SHiNE: <server address> connected|unavailable`;
|
|
||||||
- слово `connected` на обеих строках окрашивается зелёным;
|
|
||||||
- текст на кнопке баланса сдвинут левее;
|
|
||||||
- после старта устройство автоматически пытается подгрузить баланс при готовых секрете и `Wi-Fi`;
|
|
||||||
- в `SETTINGS` первые три пункта переименованы в `1. Wi-Fi`, `2. Server`, `3. Account`.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
1. Перезагрузить устройство.
|
|
||||||
2. Проверить, что на `HOME` баланс подгружается сам, без нажатия на кнопку.
|
|
||||||
3. Проверить, что строки `Wi-Fi` и `SHiNE` читаются и слово `connected` зелёное при хорошем состоянии.
|
|
||||||
4. Проверить, что кружок аккаунта расположен слева от логина.
|
|
||||||
5. Открыть `SETTINGS` и убедиться, что первые три пункта нумеруются как `1. Wi-Fi`, `2. Server`, `3. Account`.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- `HOME` выглядит компактнее и читаемее;
|
|
||||||
- баланс после старта появляется автоматически;
|
|
||||||
- статусные строки не перекрываются;
|
|
||||||
- меню `SETTINGS` показывает нужную нумерацию.
|
|
||||||
@ -1,26 +0,0 @@
|
|||||||
# ESP32 антифриз при неверном SHiNE server
|
|
||||||
|
|
||||||
- Статус: `pending`
|
|
||||||
|
|
||||||
## Что сделано
|
|
||||||
|
|
||||||
- уменьшены таймауты `SHiNE`-запросов и `WS`-подключения;
|
|
||||||
- повторные попытки подключения переведены на backoff:
|
|
||||||
- `10s`
|
|
||||||
- `20s`
|
|
||||||
- максимум `30s`
|
|
||||||
- пока открыт экран настроек или редактирования, новые фоновые попытки `SHiNE reconnect` не запускаются.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
1. Указать неверный адрес `SHiNE server`.
|
|
||||||
2. Дождаться статуса `unavailable`.
|
|
||||||
3. Проверить, что `HOME` не подвисает на секунды.
|
|
||||||
4. Проверить, что можно открыть `SETTINGS -> Server` и исправить адрес без лагов.
|
|
||||||
5. После сохранения правильного адреса убедиться, что reconnect снова идёт и устройство подключается.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- при неверном адресе UI остаётся управляемым;
|
|
||||||
- вход в настройки и редактирование сервера остаются быстрыми;
|
|
||||||
- после исправления адреса устройство снова подключается без долгой паузы.
|
|
||||||
@ -1,23 +0,0 @@
|
|||||||
# server esp pairing
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
- на сервере добавлен отдельный pairing-сценарий для подключения нового устройства через доверенную уже авторизованную сессию пользователя без выдачи приватных ключей сервером;
|
|
||||||
- добавлены `op`: `UpsertEspPairingSettings`, `StartEspPairing`, `ListEspPairingRequests`, `ApproveEspPairing`, `RejectEspPairing`, `GetEspPairingStatus`;
|
|
||||||
- подтверждать pairing может любая доверенная сессия пользователя.
|
|
||||||
|
|
||||||
- что именно проверять:
|
|
||||||
- любая уже авторизованная сессия пользователя включает pairing и задаёт `passwordHash`;
|
|
||||||
- новое устройство создаёт заявку через `StartEspPairing`;
|
|
||||||
- другая доверенная сессия пользователя видит заявку в `ListEspPairingRequests`;
|
|
||||||
- доверенная сессия подтверждает заявку через `ApproveEspPairing`;
|
|
||||||
- новое устройство получает `approved + encryptedPayload` через `GetEspPairingStatus`;
|
|
||||||
- неавторизованное новое устройство не может вызывать управляющие pairing-операции.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
- заявка создаётся со статусом `created`;
|
|
||||||
- у заявки есть `pairingId`, `shortCode`, `fingerprintB58`, `expiresAtMs`;
|
|
||||||
- после approve статус становится `approved`, а `encryptedPayload` возвращается новому устройству;
|
|
||||||
- неавторизованное соединение получает отказ `463 / PAIRING_REQUIRES_AUTH_SESSION`.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
- `pending`
|
|
||||||
@ -1,36 +0,0 @@
|
|||||||
# ui подключение по коду
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
- в UI добавлен новый сценарий подключения устройства через доверенную уже авторизованную сессию пользователя;
|
|
||||||
- на экране входа появилась кнопка `Войти через другое устройство`;
|
|
||||||
- на доверённом устройстве в `Подключить устройство` появилась кнопка `Подключить по коду`;
|
|
||||||
- доверённое устройство может включить pairing с доп. паролем или без него, увидеть заявки, подтвердить подключение только с `device key` или с передачей выбранных ключей.
|
|
||||||
|
|
||||||
- что именно проверять:
|
|
||||||
- на уже авторизованном устройстве включить pairing без доп. пароля;
|
|
||||||
- на новом устройстве открыть `Войти через другое устройство`, оставить галочку доп. пароля выключенной и получить 7-значный код;
|
|
||||||
- отдельно включить pairing с доп. паролем;
|
|
||||||
- на новом устройстве открыть `Войти через другое устройство`, включить галочку доп. пароля, ввести `login + pairing password` и получить 7-значный код;
|
|
||||||
- на доверённом устройстве открыть `Подключить по коду`, найти заявку по коду и подтвердить её:
|
|
||||||
- без доп. ключей;
|
|
||||||
- с передачей выбранных ключей;
|
|
||||||
- убедиться, что новое устройство реально входит в аккаунт и сохраняет нужные ключи;
|
|
||||||
- отдельно проверить отклонение заявки и истечение TTL.
|
|
||||||
- при отклонении заявки убедиться, что на новом устройстве сразу исчезает карточка со старым 7-значным кодом и остаётся только сообщение об отклонении;
|
|
||||||
- убедиться, что экран `Войти` больше не показывает неработающую QR-заглушку сверху.
|
|
||||||
- убедиться, что при неверном pairing-пароле и при попытке ввести пароль там, где он не включён, пользователь видит одинаковую ошибку `Пароль подключения не подходит.`;
|
|
||||||
- убедиться, что без онлайн доверённой сессии новое устройство сразу получает явную ошибку и код вообще не создаётся;
|
|
||||||
- убедиться, что countdown под кодом убывает в реальном времени;
|
|
||||||
- убедиться, что кнопка `Отмена` на новом устройстве действительно снимает заявку и она пропадает у доверённого устройства без ожидания TTL.
|
|
||||||
- убедиться, что на экране `Подключить по коду` блок дополнительного пароля показывает два понятных состояния: пароль не задан / пароль установлен;
|
|
||||||
- убедиться, что `Задать пароль` и `Изменить пароль` открывают верхний диалог с двумя полями и кнопками-глазами;
|
|
||||||
- убедиться, что `Убрать пароль` не выключает pairing целиком, а переводит его в режим без дополнительного пароля.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
- новое устройство получает код, доверённое устройство видит ту же заявку и может её подтвердить или отклонить;
|
|
||||||
- после approve новое устройство автоматически входит в аккаунт;
|
|
||||||
- в режиме без доп. ключей переносится только `device key`;
|
|
||||||
- в расширенном режиме переносятся `device key` и отмеченные ключи `blockchain/root`, если они есть на доверённом устройстве.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
- `pending`
|
|
||||||
@ -1,22 +0,0 @@
|
|||||||
# wallet-session pairing и SHA-256 пароль pairing
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
- добавлен сценарий `session-only` подключения wallet-plugin через доверенное устройство без передачи постоянных ключей;
|
|
||||||
- для pairing-пароля убран `argon2id`, вместо него используется только формат `sha256$<hex>`;
|
|
||||||
- новый plugin `SHiNE-browser-plugin-wallet` получает и хранит только `wallet-session`.
|
|
||||||
|
|
||||||
- что проверять:
|
|
||||||
- в `shine-UI` экран `Войти через другое устройство` создаёт заявку и получает `session-only` approve;
|
|
||||||
- на доверенном устройстве в `Подключить по коду` кнопка `Подключить wallet-session` действительно не передаёт `device/root/blockchain` ключи;
|
|
||||||
- новый plugin загружается как Chrome MV3 extension и получает wallet-session;
|
|
||||||
- pairing c доп. паролем работает только с форматом `sha256$<hex>`;
|
|
||||||
- pairing без доп. пароля продолжает работать.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
- requester получает только `sessionId/sessionKey/sessionPriv/storagePwd`;
|
|
||||||
- доверенное устройство не пересылает постоянные ключи в `session-only` режиме;
|
|
||||||
- сервер принимает только новый формат pairing-пароля;
|
|
||||||
- логин по сохранённой wallet-session восстанавливается успешно.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
- pending
|
|
||||||
@ -1,22 +0,0 @@
|
|||||||
# Закрытие сессий и сортировка устройств
|
|
||||||
|
|
||||||
- краткое описание фичи:
|
|
||||||
- добровольный выход и переключение устройства/аккаунта теперь сначала пытаются закрыть текущую серверную сессию, а затем очищают локальные данные;
|
|
||||||
- на экране `Устройства` сессии сортируются так, чтобы онлайн-сессии шли раньше оффлайн;
|
|
||||||
- статус онлайн-сессии выделяется зелёным.
|
|
||||||
|
|
||||||
- что именно проверять:
|
|
||||||
- в `Настройки` нажать выход из текущей сессии и убедиться, что запись исчезает из списка сессий после повторного входа;
|
|
||||||
- в `Устройства` нажать `Завершить текущую сессию` и убедиться, что локальные данные очищены, а серверная сессия удалена;
|
|
||||||
- выполнить вход/переключение через `Подключить устройство` или QR и убедиться, что старая сессия не остаётся висеть на сервере;
|
|
||||||
- открыть `Устройства` при наличии нескольких сессий и убедиться, что сначала показаны `Online now`, затем `Offline`;
|
|
||||||
- проверить, что строки со статусом `Online now` визуально выделены зелёным.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
- при добровольном завершении сессии серверная запись удаляется;
|
|
||||||
- при локальном переключении на другой аккаунт старая текущая сессия не остаётся в `active_sessions`;
|
|
||||||
- порядок сессий в UI соответствует онлайн-статусу сервера;
|
|
||||||
- зелёный статус виден и не ломает верстку на экране `Устройства`.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
- pending
|
|
||||||
@ -1,16 +0,0 @@
|
|||||||
# Автоопределение SHiNE-сервера по PDA
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
в основном UI и в `SHiNE-browser-plugin-wallet` ручной ввод адреса SHiNE-сервера заменён на ввод логина серверного аккаунта. Клиент читает `server_address` из PDA сервера и сам строит `https://...` и `wss://...`.
|
|
||||||
|
|
||||||
- что проверять:
|
|
||||||
1. В `shine-UI` на экранах настроек входа и серверов в поле SHiNE вводится логин `shineupme`, а статус показывает точный адрес `https://shineup.me`.
|
|
||||||
2. После сохранения настроек обычный вход и login через другое устройство продолжают работать.
|
|
||||||
3. В `SHiNE-browser-plugin-wallet` поле сервера принимает логин `shineupme`, а popup показывает `Текущий адрес: https://shineup.me`.
|
|
||||||
4. В plugin pairing и повторное восстановление wallet-session продолжают работать через авторазрешённый адрес.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
пользователь больше не вводит вручную `wss://...`; внутренний WS-адрес строится автоматически из PDA серверного аккаунта.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,18 +0,0 @@
|
|||||||
# Wallet plugin: PDA-ключи и выбор homeserver
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
`SHiNE-browser-plugin-wallet` после session-only подключения сохраняет `login`, публичные `root/device/blockchain` ключи из PDA и список опубликованных `homeserver`-сессий. Постоянное подключение не удерживается: plugin остаётся офлайн, а список trusted devices обновляет по запросу.
|
|
||||||
|
|
||||||
- что проверять:
|
|
||||||
0. На стартовом экране plugin для подключения запрашивается только логин пользователя; серверный логин вручную не вводится, а показывается как информационная строка после чтения PDA.
|
|
||||||
1. После успешного pairing plugin показывает сохранённую wallet-session без автоматического постоянного подключения.
|
|
||||||
2. В карточке wallet-session виден сокращённый `deviceKey`.
|
|
||||||
3. Кнопка `Обновить устройства` подтягивает homeserver-сессии из PDA и показывает их список со статусом `online/offline/unknown`.
|
|
||||||
4. В селекте ключа подписи доступны `rootKey (ed25519, ...)` и `deviceKey (ed25519, ...)`.
|
|
||||||
5. Кнопка `Запросить подпись` не падает и честно сообщает, что signaling подписи ещё не доделан.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
кошелёк хранит PDA-метаданные локально, не висит всё время онлайн и показывает каркас выбора ключа и устройства перед будущим этапом signaling подписи.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
@ -1,24 +0,0 @@
|
|||||||
# TrustedDeviceLogin settings и новый режим по умолчанию
|
|
||||||
|
|
||||||
- краткое описание:
|
|
||||||
серверный API сценария входа через доверенное устройство переименован в `TrustedDeviceLogin`, добавлен `GetTrustedDeviceLoginSettings`, а отсутствие серверной записи настроек теперь трактуется как `enabled = true` и `hasPassword = false`. В UI вынесен отдельный экран настроек входа через доверенное устройство.
|
|
||||||
|
|
||||||
- что проверять:
|
|
||||||
1. Для логина без записи в `esp_pairing_settings` `StartTrustedDeviceLogin` работает без предварительного ручного включения.
|
|
||||||
2. Экран `Подключить по коду` показывает один из трёх статусов:
|
|
||||||
- вход запрещён;
|
|
||||||
- вход разрешён без пароля;
|
|
||||||
- вход разрешён только с паролем.
|
|
||||||
3. Кнопка `Изменить настройки входа` открывает отдельный экран.
|
|
||||||
4. На отдельном экране:
|
|
||||||
- можно запретить вход;
|
|
||||||
- можно разрешить вход;
|
|
||||||
- можно задать новый пароль;
|
|
||||||
- можно сделать вход без пароля.
|
|
||||||
5. `Войти через другое устройство` в основном UI и в browser wallet работает через новые `TrustedDeviceLogin`-операции.
|
|
||||||
|
|
||||||
- ожидаемый результат:
|
|
||||||
вход через доверенное устройство по умолчанию доступен без лишнего ручного включения, а текущий режим и пароль управляются с отдельного экрана настроек.
|
|
||||||
|
|
||||||
- статус:
|
|
||||||
pending
|
|
||||||
Loading…
Reference in New Issue
Block a user