Убраны непроверенные готовые фичи и перенесён QR-план
This commit is contained in:
AidarKC
parent
9949935bcc
commit
2c2aad1355
@ -36,6 +36,7 @@
|
||||
- `medium/2026-05-24_1140_репосты_в_каналах_и_тредах.md` - репосты в каналах и тредах.
|
||||
- `medium/2026-05-25_1106_shine_balance_wallet.md` - кошелёк и пополнение баланса сияния через блокчейн.
|
||||
- `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 с версией записи.
|
||||
|
||||
### Дальнее будущее
|
||||
|
||||
@ -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