Убраны непроверенные готовые фичи и перенесён QR-план

2026-06-03 14:20:45 +04:00
parent 9949935bcc
commit 2c2aad1355
8 changed files with 46 additions and 142 deletions
@@ -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