diff --git a/Dev_Docs/Pending_Features/2026-05-28_0020_wallet_shine_blockchain_limit_sync.md b/Dev_Docs/Pending_Features/2026-05-28_0020_wallet_shine_blockchain_limit_sync.md deleted file mode 100644 index 06596de..0000000 --- a/Dev_Docs/Pending_Features/2026-05-28_0020_wallet_shine_blockchain_limit_sync.md +++ /dev/null @@ -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`, `Увеличить лимит`) выполняются без ошибок при валидных данных. -- Восстановление ключей через пароль работает, а без нужных ключей операция не выполняется молча. diff --git a/Dev_Docs/Pending_Features/2026-05-29_2255_озвучивание_ответов_агента.md b/Dev_Docs/Pending_Features/2026-05-29_2255_озвучивание_ответов_агента.md deleted file mode 100644 index b85cc6b..0000000 --- a/Dev_Docs/Pending_Features/2026-05-29_2255_озвучивание_ответов_агента.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-05-30_0013_голосовая_адаптация_telegram_бота.md b/Dev_Docs/Pending_Features/2026-05-30_0013_голосовая_адаптация_telegram_бота.md deleted file mode 100644 index e1c8c9b..0000000 --- a/Dev_Docs/Pending_Features/2026-05-30_0013_голосовая_адаптация_telegram_бота.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-05-30_1015_understand-anything-lab.md b/Dev_Docs/Pending_Features/2026-05-30_1015_understand-anything-lab.md deleted file mode 100644 index 05fd282..0000000 --- a/Dev_Docs/Pending_Features/2026-05-30_1015_understand-anything-lab.md +++ /dev/null @@ -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` - diff --git a/Dev_Docs/Pending_Features/2026-05-30_1756_центр_задач_telegram_агента.md b/Dev_Docs/Pending_Features/2026-05-30_1756_центр_задач_telegram_агента.md deleted file mode 100644 index 9b8d539..0000000 --- a/Dev_Docs/Pending_Features/2026-05-30_1756_центр_задач_telegram_агента.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-05-30_1807_рестарты_и_voice_telegram_агента.md b/Dev_Docs/Pending_Features/2026-05-30_1807_рестарты_и_voice_telegram_агента.md deleted file mode 100644 index 6c38c59..0000000 --- a/Dev_Docs/Pending_Features/2026-05-30_1807_рестарты_и_voice_telegram_агента.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-05-30_1907_кнопки_вкладки_каналы.md b/Dev_Docs/Pending_Features/2026-05-30_1907_кнопки_вкладки_каналы.md deleted file mode 100644 index da25e36..0000000 --- a/Dev_Docs/Pending_Features/2026-05-30_1907_кнопки_вкладки_каналы.md +++ /dev/null @@ -1,26 +0,0 @@ -# Кнопки вкладки «Каналы» - -## Что сделано - -Доработана верхняя панель вкладки «Каналы»: -- при открытии нижней кнопкой «Каналы» показывается режим «Все каналы»; -- в режиме «Все каналы» справа доступны кнопка «Мои каналы» и иконка поиска канала; -- в режиме «Мои каналы» доступен переход обратно во «Все каналы», а справа показывается плюсик создания канала. - -## Что проверить - -1. Открыть вкладку «Каналы» через нижнюю навигацию. -2. Убедиться, что открыт режим «Все каналы», а плюсик создания канала не отображается. -3. Нажать иконку поиска в режиме «Все каналы». -4. Убедиться, что открывается текущий сценарий поиска каналов. -5. Нажать «Мои каналы». -6. Убедиться, что справа появился плюсик создания канала. -7. Нажать «Все каналы» или стрелку назад и проверить возврат к режиму «Все каналы». - -## Ожидаемый результат - -Кнопки верхней панели соответствуют активному режиму: поиск в «Все каналы», создание только в «Мои каналы». - -## Статус - -pending diff --git a/Dev_Docs/Pending_Features/2026-06-03_0013_длинные_voice_audio_telegram_бота.md b/Dev_Docs/Pending_Features/2026-06-03_0013_длинные_voice_audio_telegram_бота.md deleted file mode 100644 index 5ec4a9c..0000000 --- a/Dev_Docs/Pending_Features/2026-06-03_0013_длинные_voice_audio_telegram_бота.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-06-03_0040_диагностика_больших_voice_audio.md b/Dev_Docs/Pending_Features/2026-06-03_0040_диагностика_больших_voice_audio.md deleted file mode 100644 index 8cea128..0000000 --- a/Dev_Docs/Pending_Features/2026-06-03_0040_диагностика_больших_voice_audio.md +++ /dev/null @@ -1,14 +0,0 @@ -# Диагностика больших voice/audio в Telegram-боте - -- краткое описание фичи: - - Бот при большом voice/audio больше не отказывается заранее по метаданным Telegram. Теперь он сначала сообщает, что пробует скачать файл, затем отдельно сообщает об успешном скачивании и только после этого переходит к подготовке аудио и распознаванию через OpenAI. -- что именно проверять: - - Отправить в бота большой `voice` или `audio`, который раньше попадал под ранний отказ. - - Проверить, что сначала приходит сообщение о попытке скачать большой файл. - - Проверить два сценария: - - скачивание удалось: бот пишет об успешной загрузке и продолжает распознавание; - - скачивание не удалось: бот пишет именно о неудачном скачивании из Telegram, без ложной привязки к ошибке OpenAI. -- ожидаемый результат: - - Пользователь видит понятную поэтапную диагностику: попытка скачивания, результат скачивания и только потом следующий этап обработки. -- статус: - - pending diff --git a/Dev_Docs/Pending_Features/2026-06-03_1508_перенос_server_ui_в_shine_ui.md b/Dev_Docs/Pending_Features/2026-06-03_1508_перенос_server_ui_в_shine_ui.md deleted file mode 100644 index c3dc4bc..0000000 --- a/Dev_Docs/Pending_Features/2026-06-03_1508_перенос_server_ui_в_shine_ui.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-06-03_1521_кнопка_настроить_сервер_и_devnet_topup.md b/Dev_Docs/Pending_Features/2026-06-03_1521_кнопка_настроить_сервер_и_devnet_topup.md deleted file mode 100644 index b23d816..0000000 --- a/Dev_Docs/Pending_Features/2026-06-03_1521_кнопка_настроить_сервер_и_devnet_topup.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-06-03_1610_fix_devnet_topup_и_пароль_autofill.md b/Dev_Docs/Pending_Features/2026-06-03_1610_fix_devnet_topup_и_пароль_autofill.md deleted file mode 100644 index 2a54d1c..0000000 --- a/Dev_Docs/Pending_Features/2026-06-03_1610_fix_devnet_topup_и_пароль_autofill.md +++ /dev/null @@ -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. -- Поля пароля пустые, пока пользователь сам ничего не вводил. diff --git a/Dev_Docs/Pending_Features/2026-06-03_1648_диагностика_server_pda_и_device_balance.md b/Dev_Docs/Pending_Features/2026-06-03_1648_диагностика_server_pda_и_device_balance.md deleted file mode 100644 index 4cabd96..0000000 --- a/Dev_Docs/Pending_Features/2026-06-03_1648_диагностика_server_pda_и_device_balance.md +++ /dev/null @@ -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` начинает проходить. diff --git a/Dev_Docs/Pending_Features/2026-06-04_1433_lazy_import_solana_pda_актуальный_формат.md b/Dev_Docs/Pending_Features/2026-06-04_1433_lazy_import_solana_pda_актуальный_формат.md deleted file mode 100644 index 817e5c0..0000000 --- a/Dev_Docs/Pending_Features/2026-06-04_1433_lazy_import_solana_pda_актуальный_формат.md +++ /dev/null @@ -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` diff --git a/Dev_Docs/Pending_Features/2026-06-04_2315_pure_rust_solana_users_and_login_guard.md b/Dev_Docs/Pending_Features/2026-06-04_2315_pure_rust_solana_users_and_login_guard.md deleted file mode 100644 index 5d3fd19..0000000 --- a/Dev_Docs/Pending_Features/2026-06-04_2315_pure_rust_solana_users_and_login_guard.md +++ /dev/null @@ -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 падений больше нет. diff --git a/Dev_Docs/Pending_Features/2026-06-05_1240_esp32_argon2_ui_совместимость.md b/Dev_Docs/Pending_Features/2026-06-05_1240_esp32_argon2_ui_совместимость.md deleted file mode 100644 index fb9357d..0000000 --- a/Dev_Docs/Pending_Features/2026-06-05_1240_esp32_argon2_ui_совместимость.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-06-05_1735_редактируемый_статус_telegram_бота.md b/Dev_Docs/Pending_Features/2026-06-05_1735_редактируемый_статус_telegram_бота.md deleted file mode 100644 index 54c18d2..0000000 --- a/Dev_Docs/Pending_Features/2026-06-05_1735_редактируемый_статус_telegram_бота.md +++ /dev/null @@ -1,17 +0,0 @@ -## Краткое описание -В `SHiNE-agent-bot-coder` для личных чатов добавлен режим одного редактируемого статусного сообщения. Бот принимает запрос, обновляет это сообщение по этапам обработки и в конце превращает его в финальный текстовый ответ. При длинном ответе допускается ещё одно дополнительное текстовое сообщение с продолжением. Голосовой ответ остаётся отдельным сообщением. - -## Что проверять -1. Отправить в личный чат короткий текстовый запрос и убедиться, что бот не шлёт цепочку промежуточных сообщений, а редактирует одно сообщение до финального ответа. -2. Отправить в личный чат `voice` или `audio` и убедиться, что в том же сообщении последовательно видны этапы распознавания и выполнения. -3. Проверить длинный ответ, который не помещается в один Telegram message: должно получиться не больше двух текстовых сообщений. -4. Проверить, что `voice`-ответ приходит отдельным новым сообщением после текстового. -5. Проверить, что в `@shine_writing` по-прежнему логируются только итоговые `вопрос -> ответ`, без промежуточных статусов. - -## Ожидаемый результат -- В личке основная переписка стала чище: промежуточные этапы живут в одном редактируемом сообщении. -- При длинном ответе бот не разбрасывает ответ на много сообщений. -- Канал `@shine_writing` работает по старой схеме без лишнего шума. - -## Статус -`pending` diff --git a/Dev_Docs/Pending_Features/2026-06-06_1324_settings_telegram_агента.md b/Dev_Docs/Pending_Features/2026-06-06_1324_settings_telegram_агента.md deleted file mode 100644 index ca2e0eb..0000000 --- a/Dev_Docs/Pending_Features/2026-06-06_1324_settings_telegram_агента.md +++ /dev/null @@ -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` diff --git a/Dev_Docs/Pending_Features/2026-06-06_1659_shine_payments_e2e_перепись_и_q3.md b/Dev_Docs/Pending_Features/2026-06-06_1659_shine_payments_e2e_перепись_и_q3.md deleted file mode 100644 index 1436bc6..0000000 --- a/Dev_Docs/Pending_Features/2026-06-06_1659_shine_payments_e2e_перепись_и_q3.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-06-07_1345_клиентская_solana_регистрация_no_anchor.md b/Dev_Docs/Pending_Features/2026-06-07_1345_клиентская_solana_регистрация_no_anchor.md deleted file mode 100644 index e7d6526..0000000 --- a/Dev_Docs/Pending_Features/2026-06-07_1345_клиентская_solana_регистрация_no_anchor.md +++ /dev/null @@ -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` diff --git a/Dev_Docs/Pending_Features/2026-06-07_1650_esp32_homeserver_ui_прототип.md b/Dev_Docs/Pending_Features/2026-06-07_1650_esp32_homeserver_ui_прототип.md deleted file mode 100644 index 874809d..0000000 --- a/Dev_Docs/Pending_Features/2026-06-07_1650_esp32_homeserver_ui_прототип.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-06-08_1150_esp32_auto_flash_script.md b/Dev_Docs/Pending_Features/2026-06-08_1150_esp32_auto_flash_script.md deleted file mode 100644 index f2d019f..0000000 --- a/Dev_Docs/Pending_Features/2026-06-08_1150_esp32_auto_flash_script.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-06-08_1240_esp32_text_render_test.md b/Dev_Docs/Pending_Features/2026-06-08_1240_esp32_text_render_test.md deleted file mode 100644 index b4f8376..0000000 --- a/Dev_Docs/Pending_Features/2026-06-08_1240_esp32_text_render_test.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-06-08_1245_esp32_pin_button_labels.md b/Dev_Docs/Pending_Features/2026-06-08_1245_esp32_pin_button_labels.md deleted file mode 100644 index 786a26e..0000000 --- a/Dev_Docs/Pending_Features/2026-06-08_1245_esp32_pin_button_labels.md +++ /dev/null @@ -1,12 +0,0 @@ -# ESP32 PIN-клавиатура: подписи кнопок - -- краткое описание фичи: - в UI-скетче `shine_homeserver_ui` изменена отрисовка подписей кнопок. Вместо малого шрифта теперь используется более стабильный шрифт с явным центрированием текста внутри кнопок, чтобы на экране ввода PIN и других экранах не пропадали цифры и надписи. -- что именно проверять: - 1. Включить устройство и дождаться экрана ввода PIN. - 2. Убедиться, что на всех серых кнопках видны цифры `0-9`, `Отмена` и `OK`. - 3. Открыть другие экраны с кнопками (`Главный экран`, `Wi-Fi`, `Серверы`, `Настройки`) и убедиться, что подписи отображаются и не уезжают за границы кнопок. -- ожидаемый результат: - подписи кнопок стабильно видны сразу после старта, текст визуально центрирован, пустых серых кнопок без цифр и названий нет. -- статус: - pending diff --git a/Dev_Docs/Pending_Features/2026-06-08_1315_esp32_test_sketches_folder.md b/Dev_Docs/Pending_Features/2026-06-08_1315_esp32_test_sketches_folder.md deleted file mode 100644 index 80e7579..0000000 --- a/Dev_Docs/Pending_Features/2026-06-08_1315_esp32_test_sketches_folder.md +++ /dev/null @@ -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 diff --git a/Dev_Docs/Pending_Features/2026-06-08_1355_esp32_lvgl_interaction_test.md b/Dev_Docs/Pending_Features/2026-06-08_1355_esp32_lvgl_interaction_test.md deleted file mode 100644 index f1a593b..0000000 --- a/Dev_Docs/Pending_Features/2026-06-08_1355_esp32_lvgl_interaction_test.md +++ /dev/null @@ -1,14 +0,0 @@ -# ESP32 LVGL interaction test - -- краткое описание фичи: - добавлен отдельный скетч `lvgl_interaction_test` на `LVGL`: экран с 9 кнопками, touch-вводом и нижней статусной строкой. При нажатии на кнопку на экране и в `Serial` показывается, какая именно кнопка нажата и сколько нажатий уже было. -- что именно проверять: - 1. Прошить режим `lvgl-interaction-test`. - 2. Убедиться, что виден заголовок, подзаголовок, 9 кнопок и нижняя статусная панель. - 3. Поочерёдно нажать разные кнопки. - 4. Проверить, что нижняя строка меняется на `Pressed: