diff --git a/AGENTS.md b/AGENTS.md index f9a5b91..541497d 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -74,11 +74,6 @@ - Подробный рабочий регламент: `Dev_Docs/Figma/TRANSFER_UI_SCREENS.md`. - Для экранов регистрации, входа и других чувствительных UI-flow по умолчанию переносить экраны в Figma по одному, а не пачкой, если пользователь отдельно не подтвердил иной способ. -## Известная проблема (временная пометка) -- Мнения по связям пользователя (`known_person`, `shine_confirmed`, `shine_seen`) в UI могут отображаться нестабильно. -- Требуется отдельная доработка и финальная проверка end-to-end: запись мнения в блокчейн → обновление `connections_state` → ответ `GetUserConnectionsGraph` → отображение в UI. -- До фикса считать эту часть функционала незавершённой и обязательно перепроверять вручную после каждого деплоя. - ## Версионирование - Единый файл версий проекта: `VERSION.properties` (в корне репозитория). - Перед каждым новым коммитом обязательно увеличивать версии в `VERSION.properties`: diff --git a/Dev_Docs/Pending_Features/2026-06-19_1605_call-decline-ui-and-ring-stop.md b/Dev_Docs/Pending_Features/2026-06-19_1605_call-decline-ui-and-ring-stop.md deleted file mode 100644 index 9b57221..0000000 --- a/Dev_Docs/Pending_Features/2026-06-19_1605_call-decline-ui-and-ring-stop.md +++ /dev/null @@ -1,22 +0,0 @@ -# Быстрое скрытие экрана звонка и остановка гудков при отклонении - -- краткое описание фичи: - - Исправлена нижняя подпись вкладки личных сообщений на `личные`. - - Исправлена логика звонка, когда одна из входящих сессий отклоняет вызов до принятия: исходящая сессия теперь должна прекращать гудки даже если ранее `RINGING` пришёл от другой входящей сессии. - - На устройстве, где пользователь нажимает отмену/сброс звонка, экран вызова теперь скрывается сразу локально, без ожидания сетевого ответа. - -- что именно проверять: - - В нижней панели с 5 кнопками подпись первой кнопки должна отображаться как `личные`. - - Сценарий: один пользователь звонит, у второго входящий вызов приходит на несколько устройств; на любом одном входящем устройстве нажать `Сбросить`. - - Проверить, что у звонящего сразу прекращаются гудки и экран вызова корректно завершается. - - Проверить, что на устройстве, где нажали `Сбросить` или `Положить трубку`, overlay звонка исчезает сразу, без заметной задержки. - - Проверить, что после принятия звонка на одном устройстве поздние отмены с других устройств не ломают уже выбранную пару соединения. - -- ожидаемый результат: - - Подпись в нижней панели корректная. - - При отклонении входящего звонка любым устройством звонящего не оставляет в состоянии бесконечных гудков. - - Локальный экран звонка скрывается мгновенно после нажатия кнопки отмены. - - Уже зафиксированный сценарий соединения после `ACCEPT` не сбивается другими сессиями. - -- статус: - - `pending` diff --git a/Dev_Docs/Pending_Features/2026-06-19_1742_turn-uzel-93-only.md b/Dev_Docs/Pending_Features/2026-06-19_1742_turn-uzel-93-only.md deleted file mode 100644 index afee8ba..0000000 --- a/Dev_Docs/Pending_Features/2026-06-19_1742_turn-uzel-93-only.md +++ /dev/null @@ -1,14 +0,0 @@ -# Отключение устаревшего TURN-узла `45.136.124.227` - -- краткое описание: - - из конфигурации звонков убран устаревший TURN-узел `45.136.124.227:3478`; - - основным и единственным выдаваемым TURN-узлом оставлен `93.170.12.154:3478`. -- что проверять: - - сделать несколько тестовых звонков между разными устройствами/сетями; - - убедиться, что звонок доходит до стадии соединения и появляется звук; - - убедиться, что в логах `CallDeliveryReport` больше не фигурирует `45.136.124.227`. -- ожидаемый результат: - - клиентам больше не выдаётся устаревший TURN-адрес; - - звонки не заваливаются из-за попыток использовать отключённый TURN-узел. -- статус: - - pending diff --git a/Dev_Docs/Pending_Features/2026-06-19_1835_fix-stop-call-push-self-kill.md b/Dev_Docs/Pending_Features/2026-06-19_1835_fix-stop-call-push-self-kill.md deleted file mode 100644 index 891e248..0000000 --- a/Dev_Docs/Pending_Features/2026-06-19_1835_fix-stop-call-push-self-kill.md +++ /dev/null @@ -1,15 +0,0 @@ -# Фикс самообрыва звонка из-за `stop_call` push своей же сессии - -- краткое описание: - - исправлена ситуация, когда активный звонок мог оборваться сразу после соединения; - - причина была в том, что `stop_call` push, предназначенный для других сессий того же пользователя, обрабатывался и в исходной сессии. -- что проверять: - - открыть несколько вкладок/устройств одного пользователя; - - принять звонок на одной сессии; - - убедиться, что активная сессия не обрывает звонок сразу после соединения; - - убедиться, что лишние сессии при этом закрывают свой локальный экран звонка. -- ожидаемый результат: - - звонок не завершается сразу после `call_connected`; - - `accepted_on_other_device` и связанные `stop_call` события больше не убивают исходную активную сессию. -- статус: - - pending diff --git a/Dev_Docs/Pending_Features/2026-06-19_1905_call-push-target-session-fix.md b/Dev_Docs/Pending_Features/2026-06-19_1905_call-push-target-session-fix.md deleted file mode 100644 index 05a2f13..0000000 --- a/Dev_Docs/Pending_Features/2026-06-19_1905_call-push-target-session-fix.md +++ /dev/null @@ -1,16 +0,0 @@ -# Фикс привязки call push к целевой sessionId - -- краткое описание: - - push-события `incoming_call` и `stop_call` теперь помечаются целевой `sessionId`; - - UI и service worker обрабатывают call push только для своей целевой сессии; - - `stop_call` для лишних сессий закрывает локальный экран тихо, без обратных сигналов и без лишних тех-сообщений. -- что проверять: - - держать несколько сессий одного пользователя в одном браузере/на одном origin; - - позвонить этому пользователю и убедиться, что входящий экран закрывается корректно только на целевых сессиях; - - после `ACCEPT` одной сессии остальные должны тихо убрать экран вызова и не ломать выбранную пару; - - после отмены входящей сессией исходящая сессия должна централизованно завершить сценарий. -- ожидаемый результат: - - push одного session endpoint больше не влияет на чужие сессии этого же origin; - - исчезают ложные `stop_call_push:accepted_on_other_device` и `terminal_call_signal_150` на неправильных сессиях. -- статус: - - pending diff --git a/Dev_Docs/Pending_Features/2026-06-19_2015_esp32_pairing_requests.md b/Dev_Docs/Pending_Features/2026-06-19_2015_esp32_pairing_requests.md deleted file mode 100644 index 2966137..0000000 --- a/Dev_Docs/Pending_Features/2026-06-19_2015_esp32_pairing_requests.md +++ /dev/null @@ -1,24 +0,0 @@ -# ESP32 homeserver: заявки на подключение устройств - -- краткое описание фичи: - - на ESP32 homeserver в `SETTINGS` добавлен первый пункт `Device requests`, который появляется только после авторизации homeserver в SHiNE; - - экран показывает список активных pairing-заявок, позволяет открыть каждую заявку и подтвердить или отклонить её; - - формат кода подключения изменён на `10` цифр и показывается как `5` пар. - -- что проверять: - - на обычном клиенте и в wallet-plugin код отображается как `XX XX XX XX XX`; - - на доверенном веб-клиенте экран `Подключить по коду` показывает все активные заявки без поля ручного ввода; - - на ESP32 после успешной homeserver-авторизации в `SETTINGS` появляется пункт `Device requests` первым; - - `REFRESH` реально загружает активные заявки; - - на экране видно две плитки, список листается вертикально; - - client-session заявка после `YES` подключается с передачей только `client key`; - - wallet-session заявка после `YES` подключается без передачи ключей, через выпуск отдельной wallet-session; - - `NO` отклоняет заявку и она исчезает из списка активных. - -- ожидаемый результат: - - все три клиента используют единый формат кода; - - активные заявки видны без ручного ввода кода; - - ESP32 может одобрять и отклонять живые pairing-заявки пользователя. - -- статус: - - pending diff --git a/Dev_Docs/Pending_Features/2026-06-21_1226_fix_dm_chatid_lowercase.md b/Dev_Docs/Pending_Features/2026-06-21_1226_fix_dm_chatid_lowercase.md deleted file mode 100644 index ce8b296..0000000 --- a/Dev_Docs/Pending_Features/2026-06-21_1226_fix_dm_chatid_lowercase.md +++ /dev/null @@ -1,19 +0,0 @@ -# Исправление chatId личных сообщений через lowercase - -- краткое описание фичи: - - В клиентском UI SHiNE для личных сообщений технический `chatId` теперь канонизируется через `trim().toLowerCase()` при приёме DM, открытии чата и восстановлении сообщений из IndexedDB. - - Цель: исключить рассинхрон, когда unread-индикатор есть, а входящие сообщения конкретного собеседника не видны из-за разного регистра логина. - -- что именно проверять: - - Отправить личные сообщения между двумя пользователями, у одного из которых логин отображается с заглавными буквами. - - Убедиться, что входящие сообщения показываются внутри открытого чата, а не только в общем unread-индикаторе. - - Перезагрузить страницу и проверить, что история чата после гидрации из IndexedDB остаётся в одном диалоге. - - Проверить, что переход в чат из списка диалогов и из графа связей открывает тот же диалог без дублирования. - -- ожидаемый результат: - - Все сообщения одного собеседника попадают в один и тот же DM-чат независимо от регистра логина. - - Общий unread, список диалогов и содержимое открытого чата совпадают между собой. - - После перезагрузки UI не появляется отдельный дубль диалога с тем же логином в другом регистре. - -- статус: - - pending diff --git a/Dev_Docs/Pending_Features/2026-06-21_1735_esp32_wallet_selector_and_extension_rpc.md b/Dev_Docs/Pending_Features/2026-06-21_1735_esp32_wallet_selector_and_extension_rpc.md deleted file mode 100644 index 416f383..0000000 --- a/Dev_Docs/Pending_Features/2026-06-21_1735_esp32_wallet_selector_and_extension_rpc.md +++ /dev/null @@ -1,27 +0,0 @@ -# ESP32 выбор кошелька и wallet RPC для browser extension - -- краткое описание: - - в ESP32 заменён домашний блок `баланс + QR` на единый вход в экран кошелька; - - добавлен выбор активного кошелька `ClientKey / RootKey / Custom`; - - для browser extension добавлен первый RPC `get_wallet_public_key` через существующий `wallet-session` и `CallSignalToSession`; - - в popup расширения добавлен запрос текущего кошелька и копирование `publicKeyBase58`. - -- что проверять: - - на ESP32 после ввода секрета на главном экране видна кнопка `Кошелёк: ...`; - - экран `WALLET` открывается и показывает текущий тип кошелька; - - экран `WALLET_SELECT` переключает `ClientKey`, `RootKey` и `Custom`; - - для `Custom` открывается ввод имени и после сохранения derivation работает; - - `Показать баланс кошелька` читает баланс именно активного кошелька; - - `Показать QR-код кошелька` показывает QR и адрес именно активного кошелька; - - browser extension после подключения wallet-session может запросить текущий кошелёк у ESP32; - - extension показывает тип кошелька, полный `publicKeyBase58`, результат проверки через PDA и копирует ключ в буфер; - - для `client.key` и `root.key` проверка через PDA даёт ожидаемое совпадение. - -- ожидаемый результат: - - активный кошелёк на ESP32 реально влияет на баланс, QR и ответ `get_wallet_public_key`; - - browser extension получает ответ без ручного ввода `walletSelector`; - - homeserver выбирается из опубликованных в PDA sessions и запрос приходит в нужное устройство; - - копирование ключа из extension работает. - -- статус: - - pending diff --git a/Dev_Docs/Pending_Features/2026-06-21_2045_esp32_english_ui_and_trusted_login_fix.md b/Dev_Docs/Pending_Features/2026-06-21_2045_esp32_english_ui_and_trusted_login_fix.md deleted file mode 100644 index 2a922b1..0000000 --- a/Dev_Docs/Pending_Features/2026-06-21_2045_esp32_english_ui_and_trusted_login_fix.md +++ /dev/null @@ -1,18 +0,0 @@ -# ESP32 English UI and trusted login fix - -- Краткое описание: - переведён экранный UI ESP32 homeserver на английский язык; добавлена локальная инструкция для AGENTS по ограничению кириллицы; исправлено падение `StartTrustedDeviceLogin`, когда у пользователя ещё нет записи `esp_pairing_settings`. - -- Что проверять: - 1. На ESP32 открыть `HOME`, `WALLET`, `SELECT WALLET`, `WALLET QR` и убедиться, что пользовательские строки на экране только на английском. - 2. Проверить сценарий выбора `ClientKey`, `RootKey`, `Custom` и чтение баланса/QR после переключения. - 3. В расширении открыть popup, запустить `Подключить` для логина, у которого ещё не настраивался trusted-device login. - 4. Убедиться, что `StartTrustedDeviceLogin` больше не падает с `NullPointerException`. - 5. После создания pairing-запроса проверить, что homeserver/UI может его увидеть и обработать как раньше. - -- Ожидаемый результат: - - ESP32 UI читается на устройстве без кириллических строк. - - Подключение через trusted-device login стартует без server-side `INTERNAL_HANDLER_ERROR`, даже если настройки pairing ещё ни разу не сохранялись. - -- Статус: - `pending` diff --git a/Dev_Docs/Pending_Features/2026-06-21_2125_browser_wallet_side_panel.md b/Dev_Docs/Pending_Features/2026-06-21_2125_browser_wallet_side_panel.md deleted file mode 100644 index ca1d167..0000000 --- a/Dev_Docs/Pending_Features/2026-06-21_2125_browser_wallet_side_panel.md +++ /dev/null @@ -1,20 +0,0 @@ -# Browser wallet side panel - -- Краткое описание: - browser extension `SHiNE Wallet` переведён с toolbar popup на штатный Chromium side panel. - -- Что проверять: - 1. Перезагрузить unpacked extension в Chromium-браузере. - 2. Нажать на иконку `SHiNE Wallet` в toolbar. - 3. Убедиться, что открывается side panel, а не всплывающий popup. - 4. Проверить, что панель можно держать открытой при навигации по сайтам. - 5. Проверить сценарии `Подключить`, `Отключить`, `Обновить устройства`, `Запросить кошелёк`. - 6. Проверить, что сторона панели управляется браузером, а UI корректно выглядит и слева, и справа. - -- Ожидаемый результат: - - расширение открывается в штатной боковой панели Chromium; - - UI работает так же, как раньше в popup; - - панель остаётся доступной как постоянная колонка браузера. - -- Статус: - `pending` diff --git a/Dev_Docs/Pending_Features/2026-06-21_2235_wallet_provider_and_esp_sign_transaction.md b/Dev_Docs/Pending_Features/2026-06-21_2235_wallet_provider_and_esp_sign_transaction.md deleted file mode 100644 index 1573d9f..0000000 --- a/Dev_Docs/Pending_Features/2026-06-21_2235_wallet_provider_and_esp_sign_transaction.md +++ /dev/null @@ -1,23 +0,0 @@ -# Wallet provider and ESP sign_transaction - -- Краткое описание: - browser extension `SHiNE Wallet` теперь внедряет `window.solana` для сайтов и умеет выполнять `connect` и `signTransaction`; подпись транзакции уходит на ESP32 через wallet RPC `sign_transaction`, а подтверждение делается на устройстве. - -- Что проверять: - 1. Перезагрузить unpacked extension в Chromium. - 2. Открыть сайт/тестовую страницу, которая вызывает `window.solana.connect()`. - 3. Подтвердить подключение кошелька и убедиться, что сайт получает публичный ключ. - 4. Открыть сайт/тестовую страницу, которая вызывает `window.solana.signTransaction(...)`. - 5. Убедиться, что на ESP32 открывается экран `SIGN REQUEST` с комментарием. - 6. Проверить оба варианта: - - `APPROVE` возвращает сайту подписанную транзакцию; - - `REJECT` возвращает отказ. - 7. Проверить сценарии для `ClientKey`, `RootKey`, `Custom`. - -- Ожидаемый результат: - - сайт может подключить кошелёк через provider расширения; - - транзакция подписывается только после подтверждения на ESP32; - - отказ на ESP32 корректно доходит до сайта. - -- Статус: - `pending` diff --git a/Dev_Docs/Pending_Features/2026-06-22_0135_wallet_standard_support.md b/Dev_Docs/Pending_Features/2026-06-22_0135_wallet_standard_support.md deleted file mode 100644 index 3f0e2b9..0000000 --- a/Dev_Docs/Pending_Features/2026-06-22_0135_wallet_standard_support.md +++ /dev/null @@ -1,18 +0,0 @@ -# Wallet Standard support - -- Краткое описание: - расширение `SHiNE Wallet` теперь не только внедряет legacy `window.solana`, но и регистрирует себя как `Wallet Standard` wallet для Solana dapp. - -- Что проверять: - 1. Перезагрузить unpacked extension. - 2. Открыть dapp, который использует Wallet Standard, например `app.realms.today` на `devnet`. - 3. Открыть список кошельков и убедиться, что `SHiNE Wallet` появился отдельным вариантом. - 4. Проверить `connect`. - 5. Проверить подпись транзакции через сценарий dapp, который использует стандартный wallet interface. - -- Ожидаемый результат: - - dapp видит `SHiNE Wallet` как standard wallet, а не только как legacy Phantom-style provider. - - connect и подпись работают через тот же ESP32 approval-flow. - -- Статус: - `pending` diff --git a/Dev_Docs/Pending_Features/2026-06-23_1245_esp32_homeserver_pda_update_fix.md b/Dev_Docs/Pending_Features/2026-06-23_1245_esp32_homeserver_pda_update_fix.md deleted file mode 100644 index 6da227a..0000000 --- a/Dev_Docs/Pending_Features/2026-06-23_1245_esp32_homeserver_pda_update_fix.md +++ /dev/null @@ -1,26 +0,0 @@ -## Кратко - -Исправлена ESP32-ветка обновления `user_pda` для добавления `homeserver`-сессии после миграции формата PDA на `RecoveryKeyBlock`. - -## Что сделано - -- В `shine_homeserver_main.ino` синхронизирован `create/update` payload с новым форматом `shine_users`. -- В сериализацию и парсинг PDA добавлен `RecoveryKeyBlock`. -- Для ветки `Add Homeserver` добавлены промежуточные checkpoint-записи в NVS, чтобы после crash или reset было видно, на каком шаге оборвалась операция. -- В `ESP32/AGENTS.md` добавлена памятка по чтению `last_error`. - -## Что проверять - -- Зарегистрировать или использовать уже существующий аккаунт на ESP32. -- Дойти до состояния `homeserver not in PDA`. -- Нажать `Add Homeserver`. -- Если операция не успешна, считать `last_error` по USB serial и убедиться, что видна свежая запись именно по шагам `Homeserver PDA update ...`, а не старый diag. - -## Ожидаемый результат - -- `Add Homeserver` добавляет `homeserver1` в `sessions` блока `SessionsBlock`. -- Если операция падает, в NVS сохраняется свежая диагностическая запись с текущим этапом, а не устаревший лог регистрации. - -## Статус - -`pending` diff --git a/Dev_Docs/Pending_Features/2026-06-25_0645_chat_mobile_keyboard_and_autoscroll.md b/Dev_Docs/Pending_Features/2026-06-25_0645_chat_mobile_keyboard_and_autoscroll.md deleted file mode 100644 index a7f3d1f..0000000 --- a/Dev_Docs/Pending_Features/2026-06-25_0645_chat_mobile_keyboard_and_autoscroll.md +++ /dev/null @@ -1,39 +0,0 @@ -## Краткое описание - -Доработан UX личного чата на мобильных устройствах: -- при открытой экранной клавиатуре нижний тулбар на 5 кнопок временно скрывается; -- после отправки собственного сообщения чат автоматически прокручивается вниз так, чтобы новое сообщение было видно сразу. -- при открытии уже существующего личного чата стартовая позиция выбирается по хвосту переписки: - - если есть непрочитанные сообщения, открытие происходит на линии `Новые сообщения`; - - если непрочитанных нет, чат открывается сразу в самом низу. -- на мобильной экранной клавиатуре `Enter` больше не отправляет сообщение, а создаёт новую строку; -- отправка выполняется только кнопкой `Отправить`; -- после отправки фокус остаётся в поле ввода, чтобы экранная клавиатура не закрывалась автоматически. - -## Что проверять - -- открыть личный чат на телефоне; -- тапнуть в поле ввода и убедиться, что нижний тулбар скрывается после появления клавиатуры; -- закрыть клавиатуру и убедиться, что тулбар возвращается; -- отправить короткое сообщение, находясь не в самом низу переписки; -- убедиться, что после отправки экран прокручивается вниз и новое сообщение видно сразу; -- проверить то же поведение после прихода подтверждения отправки/перерисовки списка. -- открыть существующий чат с непрочитанными сообщениями и убедиться, что видна линия `Новые сообщения` и сообщения ниже неё; -- открыть существующий чат без непрочитанных сообщений и убедиться, что открыт конец переписки, а не начало. -- на телефоне нажать кнопку `Enter` на экранной клавиатуре и убедиться, что появляется новая строка, а сообщение не уходит; -- нажать кнопку отправки и убедиться, что сообщение отправилось, осталось видимым внизу и клавиатура не закрылась; -- отдельно проверить два сценария прокрутки после отправки: - - пользователь уже почти внизу и прокрутка идёт плавно; - - пользователь был заметно выше и чат догоняет новый хвост без лишних скачков. - -## Ожидаемый результат - -- клавиатура не конфликтует по высоте с нижним тулбаром; -- при наборе доступно больше вертикального места; -- собственное только что отправленное сообщение сразу попадает в видимую область. -- при открытии чата пользователь сразу попадает в актуальную часть переписки. -- мобильный ввод не конфликтует с привычным поведением экранной клавиатуры. - -## Статус - -`pending` diff --git a/Dev_Docs/Pending_Features/2026-06-25_0735_hidden_dm_notifications.md b/Dev_Docs/Pending_Features/2026-06-25_0735_hidden_dm_notifications.md deleted file mode 100644 index e245e0e..0000000 --- a/Dev_Docs/Pending_Features/2026-06-25_0735_hidden_dm_notifications.md +++ /dev/null @@ -1,31 +0,0 @@ -## Краткое описание - -Доработаны входящие уведомления для личных сообщений в сценарии, когда UI открыт, но страница скрыта на телефоне: - -- для входящего DM при `document.visibilityState !== visible` UI пытается показать системное уведомление через `service worker`; -- добавлен `best effort` сигнал через `navigator.vibrate()`; -- добавлен короткий локальный звуковой сигнал через Web Audio, если аудио-контекст был ранее разблокирован пользовательским действием. -- для видимой активной страницы этот же сигнал теперь проигрывается на каждое новое входящее DM; -- для скрытой страницы звуковой сигнал сделан длиннее и заметнее. - -## Что проверять - -- открыть SHiNE в Chrome/Android и один раз взаимодействовать со страницей; -- свернуть браузер или увести вкладку в фон, не закрывая её полностью; -- отправить DM с другого аккаунта; -- при открытой видимой странице тоже отправить DM и убедиться, что короткий сигнал воспроизводится без системного уведомления в шторке; -- проверить, что: - - сообщение пришло в шторку как системное уведомление; - - при поддержке устройства есть вибрация; - - на части устройств/браузеров может прозвучать локальный сигнал; -- отдельно проверить, что при открытой видимой странице не появилось лишних дублей системного уведомления. - -## Ожидаемый результат - -- скрытая, но живая страница стала заметнее реагировать на входящий DM; -- уведомление в фоне не зависит только от `new Notification(...)` из страницы; -- если браузер разрешает локальный аудио-сигнал, пользователь слышит короткое оповещение. - -## Статус - -`pending` diff --git a/VERSION.properties b/VERSION.properties index 7037333..b49fb38 100644 --- a/VERSION.properties +++ b/VERSION.properties @@ -1,2 +1,2 @@ -client.version=1.2.275 -server.version=1.2.255 +client.version=1.2.276 +server.version=1.2.256