Убраны непроверенные готовые фичи и перенесён QR-план
This commit is contained in:
AidarKC
parent
9949935bcc
commit
2c2aad1355
@ -36,6 +36,7 @@
|
|||||||
- `medium/2026-05-24_1140_репосты_в_каналах_и_тредах.md` - репосты в каналах и тредах.
|
- `medium/2026-05-24_1140_репосты_в_каналах_и_тредах.md` - репосты в каналах и тредах.
|
||||||
- `medium/2026-05-25_1106_shine_balance_wallet.md` - кошелёк и пополнение баланса сияния через блокчейн.
|
- `medium/2026-05-25_1106_shine_balance_wallet.md` - кошелёк и пополнение баланса сияния через блокчейн.
|
||||||
- `medium/2026-05-26_0029_esp32s3_file_storage.md` - ESP32S3 как личное файловое хранилище SHiNE для файлов переписок и вложений.
|
- `medium/2026-05-26_0029_esp32s3_file_storage.md` - ESP32S3 как личное файловое хранилище SHiNE для файлов переписок и вложений.
|
||||||
|
- `medium/2026-06-03_подключение_других_устройств_через_qr.md` - довести подключение других устройств через QR: сейчас заготовка есть, но сценарий работает нестабильно и его нужно будет отдельно доделать.
|
||||||
- `medium/2026-06-02_сессионные_саб_серверы_в_pda.md` - несколько саб-серверов пользователя как типизированные сессии в PDA с версией записи.
|
- `medium/2026-06-02_сессионные_саб_серверы_в_pda.md` - несколько саб-серверов пользователя как типизированные сессии в PDA с версией записи.
|
||||||
|
|
||||||
### Дальнее будущее
|
### Дальнее будущее
|
||||||
|
|||||||
@ -0,0 +1,45 @@
|
|||||||
|
# Подключение других устройств через QR
|
||||||
|
|
||||||
|
- Горизонт:
|
||||||
|
`medium`
|
||||||
|
- Ориентир:
|
||||||
|
позже, не сейчас
|
||||||
|
- Статус:
|
||||||
|
`future`
|
||||||
|
|
||||||
|
## Зачем нужна фича
|
||||||
|
|
||||||
|
Нужно нормально довести подключение другого устройства через QR-код. Сейчас есть полуготовая заготовка, но сценарий работает нестабильно и требует отдельной доработки.
|
||||||
|
|
||||||
|
## Что уже есть
|
||||||
|
|
||||||
|
- В UI уже есть экраны:
|
||||||
|
- `shine-UI/js/pages/connect-device-view.js`
|
||||||
|
- `shine-UI/js/pages/device-qr-view.js`
|
||||||
|
- Есть сервис переноса ключей через QR:
|
||||||
|
- `shine-UI/js/services/qr-key-transfer-service.js`
|
||||||
|
- Логика частично собрана, но её нельзя считать завершённой или надёжной.
|
||||||
|
|
||||||
|
## Что нужно будет сделать потом
|
||||||
|
|
||||||
|
1. Проверить и довести формат QR-передачи.
|
||||||
|
2. Проверить сканирование и ручной ввод QR-текста.
|
||||||
|
3. Проверить перенос `device`, `blockchain`, `root` ключей только по реальному наличию на исходном устройстве.
|
||||||
|
4. Проверить, что после переноса очищается старая история нужного логина и не ломается вход.
|
||||||
|
5. Отдельно проверить сценарий без `BarcodeDetector`.
|
||||||
|
6. Довести экран подтверждения на втором устройстве.
|
||||||
|
|
||||||
|
## Что сейчас важно
|
||||||
|
|
||||||
|
- Не считать эту часть готовой.
|
||||||
|
- Не возвращать её в активную разработку без отдельной команды пользователя.
|
||||||
|
- Если вернёмся к задаче, сначала нужно понять, что именно уже работает, а что нет, и потом починить целиком.
|
||||||
|
|
||||||
|
## Что обновить при возврате
|
||||||
|
|
||||||
|
- `Dev_Docs/Pending_Features/README.md`
|
||||||
|
- `shine-UI/js/pages/connect-device-view.js`
|
||||||
|
- `shine-UI/js/pages/device-qr-view.js`
|
||||||
|
- `shine-UI/js/services/qr-key-transfer-service.js`
|
||||||
|
- документацию по ключам, если формат переноса меняется
|
||||||
|
|
||||||
@ -1,25 +0,0 @@
|
|||||||
# QR-перенос ключей между устройствами
|
|
||||||
|
|
||||||
## Краткое описание
|
|
||||||
|
|
||||||
Добавлен перенос логина и сохранённых на устройстве ключей через QR-код без дополнительного шифрования QR.
|
|
||||||
|
|
||||||
Передаются только те ключи, которые реально есть на устройстве: `device`, `blockchain`, `root`.
|
|
||||||
|
|
||||||
## Что проверить
|
|
||||||
|
|
||||||
- На авторизованном устройстве открыть «Устройства» → «Подключить устройство».
|
|
||||||
- Убедиться, что недоступные ключи нельзя выбрать.
|
|
||||||
- Нажать «Показать QR-код» и проверить, что QR содержит текущий логин и выбранные доступные ключи.
|
|
||||||
- На другом устройстве открыть вход и нажать «Отсканировать QR-код».
|
|
||||||
- После сканирования проверить экран подтверждения: показывается отсканированный логин и список полученных ключей.
|
|
||||||
- Нажать «Да» и проверить, что локальная история старого логина очищена, а вход выполнен под логином из QR.
|
|
||||||
- Проверить ручной ввод QR-текста как запасной сценарий для браузеров без `BarcodeDetector`.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
Новое устройство входит под логином из QR-кода, сохраняет полученные ключи и не показывает локальную историю старого логина.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
pending
|
|
||||||
@ -1,23 +0,0 @@
|
|||||||
# Solana user_pda v2
|
|
||||||
|
|
||||||
## Краткое описание
|
|
||||||
|
|
||||||
Функции `create_user_pda` и `update_user_pda` в Solana-модуле переведены на блочный формат пользовательской PDA-записи `format_major = 2`.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
- Создание `user_pda` через `create_user_pda`.
|
|
||||||
- Обновление `user_pda` через `update_user_pda`.
|
|
||||||
- Проверку root-подписи записи.
|
|
||||||
- Проверку подписи `LastBlockState` ключом `blockchain_public_key`.
|
|
||||||
- Корректную запись блоков `RootKey`, `DeviceKey`, `BlockchainRegistry`, `ServerProfile`, `AccessServers`, `TrustedState`.
|
|
||||||
- Рост `paid_limit_bytes`, `used_bytes` и `last_block_number` без возможности уменьшения.
|
|
||||||
- Совместимость тестового клиента с актуальной IDL после `anchor build`.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
Пользовательская PDA создается и обновляется в формате `format_major = 2`, содержит один основной блокчейн `blockchain_type = 1` с именем `<login>-001`, а неверные подписи или попытки уменьшить счетчики отклоняются программой.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
pending
|
|
||||||
@ -1,26 +0,0 @@
|
|||||||
# Solana: init регистрации + деплой обязательных программ
|
|
||||||
|
|
||||||
- дата: 2026-05-24 20:35 (Europe/Moscow)
|
|
||||||
- статус: `pending`
|
|
||||||
|
|
||||||
## Кратко
|
|
||||||
|
|
||||||
Добавлена dev-страница в UI для вызова `init_users_economy_config` программы `shine_users` через подключённый кошелёк Phantom.
|
|
||||||
Задеплоены и зафиксированы адреса двух обязательных программ регистрации: `shine_users` и `shine_login_guard`.
|
|
||||||
|
|
||||||
## Что проверять вручную
|
|
||||||
|
|
||||||
1. Открыть UI и перейти в `Настройки разработчика`.
|
|
||||||
2. Нажать `Solana: init регистрации`.
|
|
||||||
3. Подключить Phantom devnet-кошелёк.
|
|
||||||
4. Выполнить `init_users_economy_config`.
|
|
||||||
5. Проверить отображение статуса и хэша транзакции.
|
|
||||||
6. Повторно нажать init и убедиться, что корректно показывается "уже инициализировано".
|
|
||||||
7. Выполнить тестовую регистрацию пользователя и убедиться, что CPI-вызов `shine_login_guard` не падает.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- Первая транзакция выполняется успешно (если PDA ещё не создан).
|
|
||||||
- Вторая попытка возвращает ожидаемую ошибку о повторной инициализации.
|
|
||||||
- UI не падает, статус понятный, Program ID отображается корректно.
|
|
||||||
- Регистрация пользователя проходит с подключённым `shine_login_guard`.
|
|
||||||
@ -1,26 +0,0 @@
|
|||||||
# Отчёт private-запросов агента в группу
|
|
||||||
|
|
||||||
## Что сделано
|
|
||||||
|
|
||||||
После успешной обработки задачи из личного чата Айдара Telegram-бот агента отправляет итоговую копию в группу `@shine_writing`:
|
|
||||||
|
|
||||||
- первым сообщением исходный запрос;
|
|
||||||
- вторым сообщением, reply на первое, финальный ответ Codex.
|
|
||||||
|
|
||||||
Промежуточные статусы выполнения в группу не дублируются.
|
|
||||||
|
|
||||||
## Что проверять
|
|
||||||
|
|
||||||
1. Отправить боту личный текстовый запрос.
|
|
||||||
2. Дождаться полного ответа в личном чате.
|
|
||||||
3. Проверить, что в `@shine_writing` появилось сообщение с запросом.
|
|
||||||
4. Проверить, что итоговый ответ опубликован reply на это сообщение.
|
|
||||||
5. Отправить личный voice-запрос и проверить, что в отчёте есть распознанный текст.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
Личный чат работает как раньше, а группа получает только итоговую пару сообщений по завершённой задаче.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
pending
|
|
||||||
@ -1,23 +0,0 @@
|
|||||||
# Отчёт voice/audio-запросов с исходным файлом
|
|
||||||
|
|
||||||
## Краткое описание
|
|
||||||
|
|
||||||
Публичный отчёт по приватным voice/audio-запросам агента должен отправлять исходный Telegram voice/audio-файл с подписью, где указан распознанный текст. `file_id` не должен показываться пользователям в тексте отчёта.
|
|
||||||
|
|
||||||
## Что проверить
|
|
||||||
|
|
||||||
1. Отправить боту приватный voice-запрос от Айдара.
|
|
||||||
2. Дождаться обработки Codex.
|
|
||||||
3. Проверить группу/канал публичных отчётов.
|
|
||||||
4. Повторить сценарий для audio-файла, если он используется.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
|
|
||||||
- В публичном отчёте появляется исходное голосовое/audio-сообщение.
|
|
||||||
- В подписи к нему есть распознанный текст.
|
|
||||||
- В отчёте нет строки `Голосовой file_id` и самого `file_id`.
|
|
||||||
- Итоговый ответ Codex отправляется ответом на сообщение с исходным файлом.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
|
|
||||||
pending
|
|
||||||
@ -1,19 +0,0 @@
|
|||||||
# Улучшенная обработка длинных voice/audio
|
|
||||||
|
|
||||||
## Что сделано
|
|
||||||
- Увеличены и вынесены в `.env` тайм-ауты скачивания Telegram-файла и OpenAI-распознавания.
|
|
||||||
- Добавлены подробные логи стадий распознавания: старт, скачивание, размер файла, завершение, причина ошибки.
|
|
||||||
- Ошибки voice/audio теперь показываются пользователю как ошибка распознавания с понятной причиной.
|
|
||||||
|
|
||||||
## Как проверять
|
|
||||||
- Отправить короткое голосовое сообщение и убедиться, что оно распознаётся и передаётся в Codex.
|
|
||||||
- Отправить длинное голосовое сообщение и убедиться, что сервис не падает на прежнем коротком тайм-ауте.
|
|
||||||
- Смоделировать ошибку распознавания или временно указать неверный OpenAI-ключ и проверить текст ошибки в Telegram.
|
|
||||||
|
|
||||||
## Ожидаемый результат
|
|
||||||
- При успешном распознавании пользователь видит распознанный текст и задача уходит в Codex.
|
|
||||||
- При ошибке пользователь видит, что не удалось именно распознать voice/audio, и получает конкретную причину.
|
|
||||||
- В логах сервиса видны стадия и техническая причина сбоя.
|
|
||||||
|
|
||||||
## Статус
|
|
||||||
pending
|
|
||||||
Loading…
Reference in New Issue
Block a user