Перенести backlog в TODO

TODO/README.md

@@ -15,8 +15,30 @@
 
 ## Текущие задачи
 
-- `2026-06-26_1800_graceful_shutdown_30s.md` - дать сервису до 30 секунд на корректное завершение опасных операций перед рестартом.
-- `2026-06-26_1805_server_to_server_ws_and_dm_sync.md` - постоянный server-to-server WebSocket, push новых блоков и DM, ACK и backfill.
-- `2026-06-26_1810_qr_device_sessions.md` - довести подключение других устройств по QR и перевести это в нормальные типизированные сессии.
-- `2026-06-26_1815_esp32_file_storage.md` - использовать ESP32 как личное файловое хранилище для переписок и вложений.
+- `2026-06-26_1800_корректное_завершение_за_30с.md` - дать сервису до 30 секунд на корректное завершение опасных операций перед рестартом.
+- `2026-06-26_1805_межсерверный_ws_и_dm_sync.md` - постоянный server-to-server WebSocket, push новых блоков и DM, ACK и backfill.
+- `2026-06-26_1810_подключение_устройств_по_qr.md` - довести подключение других устройств по QR и перевести это в нормальные типизированные сессии.
+- `2026-06-26_1815_esp32_файловое_хранилище.md` - использовать ESP32 как личное файловое хранилище для переписок и вложений.
 
+## Перенесённые планы из `Dev_Docs/Future_Features/`
+
+### near
+
+- `near/2026-05-25_1106_telegram_agent_players.md` - разрешённые пользователи Telegram для агента, отдельные папки игроков, персональные истории и публикация краткого вопроса/ответа в общий канал.
+- `near/2026-05-25_1106_wallet_topup_solana_arweave.md` - пополнение Solana и Arweave через внешний сервис покупки с подсказкой и копированием адреса.
+
+### medium
+
+- `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-02_сессионные_homeserver_в_pda.md` - несколько homeserver-ов пользователя как типизированные сессии в PDA с версией записи.
+- `medium/2026-06-03_подключение_других_устройств_через_qr.md` - довести подключение других устройств через QR: сейчас заготовка есть, но сценарий работает нестабильно и его нужно будет отдельно доделать.
+
+### dao_запуск
+
+- `dao_запуск/2026-06-05_esp32_hardware_wallet_device_session.md` - ESP32 как аппаратный кошелёк: постоянная device-сессия на сервере, подтверждение операций на экране, делегированные сессии для браузера/телефона.
+
+### far
+
+- `far/2026-06-20_1639_homeserver_technical_commands_and_file_transfer.md` - технические команды для homeserver через SHiNE/WebRTC DataChannel и обмен файлами по чанкам с адресацией по `SHA-256`.

TODO/dao_запуск/2026-06-05_esp32_hardware_wallet_device_session.md

@@ -0,0 +1,64 @@
+# ESP32 как аппаратный кошелёк (device-сессия)
+
+## Суть фичи
+
+ESP32 становится аппаратным HSM (hardware security module): хранит ключи, постоянно подключён к SHiNE-серверу как device-сессия, подтверждает операции нажатием на экране. Другие устройства (браузер, телефон) взаимодействуют с ESP32 через сервер — без прямого соединения.
+
+## Два ключевых сценария
+
+### Сценарий 1 — Создание делегированной сессии
+1. Браузер/телефон → сервер: «хочу делегированную сессию от имени пользователя X»
+2. Сервер → ESP32 (device-сессия): «запрос на одобрение»
+3. Пользователь нажимает «Да» на сенсорном экране ESP32
+4. ESP32 → сервер: одобрено → сервер создаёт делегированную сессию для браузера
+
+### Сценарий 2 — Подпись транзакции / блока
+1. Браузер (через делегированную сессию) → сервер → ESP32: «подпиши вот это»
+2. ESP32 показывает запрос на экране, пользователь подтверждает
+3. ESP32 подписывает нужным ключом → ответ через сервер → браузер
+
+## Что нужно сделать
+
+### ESP32 (основная работа)
+- [ ] Инициализация WiFi (SSID/пароль в NVS)
+- [ ] WebSocket-клиент (`WebSocketsClient`) — постоянное соединение с сервером
+- [ ] Авторизация на сервере: `AuthChallenge` → `CreateAuthSession` через `clientKey` (уже есть в NVS), сохранить `sessionId` в NVS
+- [ ] Обработчик входящих WebSocket-событий: JSON-парсинг, диспетчер по типу
+- [ ] Новые UI-экраны: «Разрешить сессию?» и «Подписать?» с кнопками Да/Нет
+- [ ] Расширенное хранилище ключей в NVS (произвольные именованные ключи сверх базовых трёх)
+- [ ] Переподключение при разрыве (reconnect loop)
+
+### Сервер (минимальные изменения)
+- [ ] Добавить поле `sessionType` (`USER` / `DEVICE`) в таблицу `active_sessions`
+- [ ] Новая операция `DeviceApprovalRequest` — браузер запрашивает одобрение у device-сессии
+- [ ] Новая операция `DeviceApprovalResponse` — ESP32 отвечает (одобрено/отклонено)
+- [ ] Новые операции `SignRequest` / `SignResponse` — запрос подписи и ответ
+- [ ] Роутинг: при получении запроса найти device-сессию через `ActiveConnectionsRegistry.getByLogin(login)` + фильтр по `sessionType=DEVICE`, переслать туда
+
+### Клиент (отдельный этап)
+- [ ] Браузерное расширение или UI: создание делегированной сессии, отправка `SignRequest`
+
+## Что уже готово (переиспользуем)
+
+- **Роутинг сообщений** — `SendDirectMessage` с `TARGET_ONE_SESSION` и `CallSignalToSession` уже умеют точечно доставлять в конкретный `sessionId`. Механизм готов, нужно добавить только новые op-коды поверх него.
+- **Ed25519 на ESP32** — библиотека `<Ed25519.h>` уже используется в скетче. Подписи работают.
+- **NVS** — уже хранит логин, мастер-секрет, 3 пары ключей. Расширяется легко.
+- **`ActiveConnectionsRegistry`** — поиск по `login` и `sessionId` уже есть на сервере.
+- **Аутентификация** — схема `AuthChallenge` → `CreateAuthSession` через Ed25519 уже полностью реализована.
+
+## Оценка сложности
+
+| Компонент | Сложность |
+|---|---|
+| ESP32: WiFi + WebSocket-клиент + авторизация | Средняя |
+| ESP32: обработчик входящих + UI подтверждений | Средняя |
+| Сервер: флаг sessionType + 4 новых op-а + роутинг | Низкая–средняя |
+| Браузерное расширение | Высокая (отдельный этап) |
+
+**Итого фазы ESP32 + сервер: ~1–1.5 недели.**
+
+## С чего начинать
+
+1. Серверная часть проще и быстрее — начать с добавления `sessionType` и `DeviceApprovalRequest/Response`.
+2. Затем ESP32: WiFi → WebSocket → авторизация → обработчик входящих → UI.
+3. Браузерное расширение — отдельная итерация после того как ESP32 + сервер работают.

TODO/far/2026-06-20_1639_homeserver_technical_commands_and_file_transfer.md

@@ -0,0 +1,114 @@
+# Homeserver: технические команды и передача файлов через SHiNE/WebRTC
+
+## Зачем нужна фича
+
+Идея на дальнее будущее: дать возможность обращаться к homeserver не только как к участнику сети SHiNE, но и как к удалённой технической точке управления.
+
+Цели:
+- отправлять на homeserver технические команды в текстовом виде;
+- получать текстовый ответ на команду;
+- при наличии WebRTC DataChannel передавать части файлов в обе стороны;
+- хранить полученные файлы на SD-карте homeserver;
+- использовать единый механизм доставки как через сервер SHiNE, так и напрямую через DataChannel.
+
+## Горизонт
+
+`far` - идея без ближайшего срока реализации. Сейчас приоритет ниже, чем запуск и стабилизация основного проекта.
+
+## Что именно имеется в виду
+
+### 1. Единая модель технической команды
+
+Техническая команда должна иметь единый смысл независимо от транспорта доставки:
+- через любой доступный сервер SHiNE;
+- через уже установленный WebRTC DataChannel.
+
+Если конкретный транспорт недоступен, ответ по нему может не прийти. Это считается нормальным поведением протокола.
+
+### 2. Команда как короткоживущий подписанный сигнал
+
+У команды должны быть:
+- `commandId`;
+- временная метка;
+- TTL около 10 секунд;
+- криптографическая подпись.
+
+Смысл такой:
+- если команда быстро дошла, homeserver подтверждает принятие;
+- если не дошла вовремя, команда считается протухшей;
+- отправитель может безопасно послать повтор;
+- при повторе homeserver отвечает либо `команда принята`, либо `уже выполнено ранее`.
+
+Это даёт дедупликацию и безопасный resend без повторного выполнения действия.
+
+### 3. Текстовые технические команды
+
+Базовый сценарий похож на короткий удалённый shell-протокол, но на уровне строго ограниченных команд:
+- отправил строку-команду;
+- получил строку-ответ.
+
+Команды не обязаны исполнять произвольный shell. Предпочтительная модель - белый список операций с контролируемым форматом аргументов и ответа.
+
+### 4. Передача файлов только при наличии DataChannel
+
+Если между устройствами есть WebRTC DataChannel, через него можно передавать технические сообщения для файлового обмена.
+
+Предварительная модель:
+- имя файла = `SHA-256` содержимого;
+- можно запросить диапазон байт `from..to`;
+- можно отправить диапазон байт `from..to`;
+- homeserver хранит полученные данные на SD-карте;
+- если DataChannel нет, на запрос файловой передачи возвращается ответ в духе `не могу передать, нет data channel`.
+
+Фактически файл-обмен должен быть частным случаем общего протокола технических команд.
+
+### 5. Установка data-соединения по явной команде
+
+Нужна техническая команда уровня:
+- `установить data-соединение`.
+
+Ответ:
+- либо `да`, после чего запускается обычная процедура `offer/answer/ICE`;
+- либо `нет` и причина отказа.
+
+### 6. Доставка на пользовательские сессии
+
+Логика должна быть совместима с общей моделью SHiNE, где технические сигналы можно отправлять на конкретные активные сессии пользователя.
+
+Идея:
+- на любую активную сессию пользователя можно посылать техническую команду;
+- контакт пользователя может инициировать такую техническую коммуникацию так же, как он уже инициирует звонок или другой служебный сигнал.
+
+## Что нужно будет сделать при возврате к задаче
+
+- Спроектировать отдельный формат технических команд и ack-ответов.
+- Решить, будет ли это новый тип служебных сообщений в существующем протоколе блокчейн/сигналинга или отдельная ветка поверх уже имеющихся transport-операций.
+- Отдельно продумать авторизацию: кто именно из контактов и какие команды имеет право слать.
+- Ограничить набор допустимых команд, чтобы не превратить механизм в небезопасный удалённый shell.
+- Спроектировать протокол чанков файлов: размер чанка, нумерация, повторная отправка, контроль целостности, дозагрузка, завершение файла.
+- Продумать хранение на SD-карте: временные файлы, сборка чанков, проверка итогового `SHA-256`, очистка мусора.
+- Продумать поведение при отсутствии DataChannel, таймаутах и дублирующихся командах.
+- Проверить, как это лучше встраивать в текущие клиентские сессии, звонки и homeserver-логику.
+
+## Вопросы для будущего уточнения
+
+- Это должен быть строго служебный протокол или пользователь сможет вызывать его и вручную из UI.
+- Нужен ли доступ только к заранее разрешённым каталогам/файлам.
+- Нужна ли двусторонняя синхронизация файлов или достаточно ручных команд `запросить кусок` / `отправить кусок`.
+- Нужно ли разрешать передачу файлов через сервер SHiNE как fallback, или файл-обмен должен идти только через DataChannel.
+- Какой максимальный размер файлов и допустимый объём хранения на SD-карте.
+
+## Что уже сделано
+
+Пока только зафиксирована идея и базовая концепция. Реализация не начиналась.
+
+## Какие документы нужно будет обновить при реализации
+
+- `Dev_Docs/Blockchain/README.md` и связанные файлы, если изменятся типы служебных сообщений или форматы блокчейн-команд.
+- `Dev_Docs/API/` если изменится публичный серверный API или появятся новые операции.
+- `Dev_Docs/Personal_Messages/README.md` если часть маршрутизации или подтверждений будет встроена в существующую логику доставки/сессий.
+- Документацию по homeserver/ESP32, если появится пользовательская или сервисная файловая логика на устройстве.
+
+## С какого места продолжать позже
+
+Возвращаться к задаче только после стабилизации запуска проекта и базовых текущих функций. Начинать с проектирования протокола команд и матрицы прав доступа, а уже потом переходить к DataChannel-файлообмену.

TODO/medium/2026-05-24_1140_репосты_в_каналах_и_тредах.md

@@ -0,0 +1,99 @@
+# Репосты в каналах и тредах
+
+- Статус:
+  `future`
+
+- Горизонт:
+  `medium`
+
+- Ориентир:
+  1-2 месяца
+
+- Решение от 2026-05-24:
+  Репосты временно убраны из активной разработки. Фича уже была частично реализована, но не доведена до финальной проверки. Чтобы она не мешала запуску проекта, пользовательский вход в репосты отключён в UI, а сервер больше не принимает новые `TEXT_REPOST` через `AddBlock`.
+
+## Что должна делать фича
+
+Репост должен позволять взять сообщение из канала или треда и опубликовать его в один из своих каналов с комментарием.
+
+Ожидаемый пользовательский сценарий после возврата к задаче:
+
+1. Пользователь открывает сообщение в канале или треде.
+2. Нажимает `Репост`.
+3. Выбирает один из своих каналов.
+4. Добавляет комментарий.
+5. Отправляет репост.
+6. В целевом канале появляется новый пост-репост.
+7. У репоста есть переход к исходному сообщению через действие `Оригинал`.
+
+## Что уже есть в коде
+
+- В блокчейн-формате зарезервирован и описан подтип `TEXT_REPOST (30)`.
+- Парсер блокчейна умеет распознавать тело репоста как `TextLineBody`.
+- В UI есть функция сборки тела репоста:
+  `shine-UI/js/services/auth-service.js`, `makeTextRepostBodyBytes`.
+- В UI есть клиентская операция:
+  `shine-UI/js/services/auth-service.js`, `addBlockRepost`.
+- В экране канала был обработчик репоста:
+  `shine-UI/js/pages/channel-view.js`, `onRepost`.
+- В экране треда был обработчик репоста:
+  `shine-UI/js/pages/channel-thread-view.js`, `onRepost`.
+- Серверная выдача каналов и тредов частично учитывает `TEXT_REPOST` и target-поля:
+  `targetBlockchainName`, `targetBlockNumber`, `targetBlockHash`.
+- В списке подписок `TEXT_REPOST` считается публикацией канала.
+
+## Что сейчас отключено
+
+- В `shine-UI/js/pages/channel-view.js` кнопка `Репост` больше не создаётся и не добавляется в список действий сообщения.
+- В `shine-UI/js/pages/channel-thread-view.js` кнопка `Репост` больше не создаётся и не добавляется в список действий ответа/сообщения треда.
+- В `shine-server-net-protocol/src/main/java/server/logic/ws_protocol/JSON/handlers/blockchain/Net_AddBlock_Handler.java` добавлена явная временная блокировка:
+  если новый блок имеет `type=1` и `subType=TEXT_REPOST (30)`, `AddBlock` возвращает ошибку `repost_disabled`.
+
+## Что осталось активным намеренно
+
+- Константа `TEXT_REPOST (30)` остаётся в коде и документации как зарезервированный формат.
+- Парсер блокчейна продолжает знать формат `TEXT_REPOST`, чтобы не потерять уже написанную основу и не ломать потенциальное чтение старых тестовых данных.
+- Код формирования репоста в `auth-service.js` не удалён: его можно будет использовать как основу при возвращении к задаче.
+- Код отображения target-полей и перехода к оригиналу не удалён: он нужен для будущей проверки и возможной совместимости с уже созданными тестовыми блоками.
+
+## Почему это не лежит в Pending_Features
+
+`Dev_Docs/Pending_Features/` предназначена для фич, которые уже реализованы и ждут ручной проверки.
+
+Репосты сейчас не подходят под этот статус: они не должны проверяться как готовая фича, потому что пользовательский сценарий временно закрыт, а серверная запись новых репостов заблокирована. Поэтому старый pending-файл удалён, а задача перенесена сюда как будущая.
+
+## Что сделать при возврате к реализации
+
+1. Решить, остаётся ли формат `TEXT_REPOST (30)` финальным.
+2. Если формат меняется, заранее предупредить пользователя и получить отдельное подтверждение на изменение блокчейн-формата.
+3. Вернуть UI-кнопки репоста в:
+   - `shine-UI/js/pages/channel-view.js`;
+   - `shine-UI/js/pages/channel-thread-view.js`.
+4. Снять временную блокировку `repost_disabled` в:
+   `shine-server-net-protocol/src/main/java/server/logic/ws_protocol/JSON/handlers/blockchain/Net_AddBlock_Handler.java`.
+5. Проверить `auth-service.js`:
+   - `makeTextRepostBodyBytes`;
+   - `addBlockRepost`;
+   - актуализацию вершины блокчейна перед `AddBlock`;
+   - корректность target-полей исходного сообщения.
+6. Проверить серверное чтение:
+   - `GetChannelMessages`;
+   - `GetMessageThread`;
+   - отображение `targetBlockchainName`, `targetBlockNumber`, `targetBlockHash`.
+7. Добавить или обновить тесты на успешный репост и отказ некорректных target-полей.
+8. Обновить документацию:
+   - `Dev_Docs/Blockchain/11_TEXT_Blocks.md`;
+   - `Dev_Docs/Blockchain/CHANGELOG.md`;
+   - `Dev_Docs/API/04_Add_Block_to_Blockchain_API.md`;
+   - документы API чтения каналов/тредов, если изменятся поля ответа.
+9. После реализации перенести задачу из `Dev_Docs/Future_Features/` в `Dev_Docs/Pending_Features/` как фичу, требующую ручной проверки.
+
+## Минимальный чек-лист ручной проверки в будущем
+
+1. Репост из сообщения канала в свой канал.
+2. Репост из ответа в треде в свой канал.
+3. Ошибка при попытке репоста в чужой канал.
+4. Переход `Оригинал` из репоста к исходному сообщению.
+5. Корректное отображение комментария к репосту.
+6. Корректная работа после перезагрузки страницы.
+7. Отсутствие поломки обычных постов, ответов, лайков и отправки ссылки.

TODO/medium/2026-05-25_1106_shine_balance_wallet.md

@@ -0,0 +1,62 @@
+# Кошелёк и пополнение баланса сияния
+
+- Горизонт:
+  `medium`
+- Ориентир:
+  среднесрочно
+- Статус:
+  `proposal`
+
+## Кратко
+
+Нужно добавить кошелёк для внутреннего баланса сияния и пополнение этого баланса через блокчейн-логику проекта. Задача связана с регистрацией пользователя и будущим учётом баланса.
+
+## Предполагаемый сценарий
+
+1. Пользователь регистрируется и получает/подключает нужные кошельки.
+2. В интерфейсе появляется баланс сияния.
+3. Пользователь открывает пополнение баланса сияния.
+4. Система создаёт или принимает блокчейн-операцию пополнения.
+5. После подтверждения баланса UI обновляет значение.
+
+## Что нужно продумать
+
+1. Что именно является единицей баланса сияния.
+2. Где хранится состояние баланса: в существующем блокчейне SHiNE, Solana-модуле или комбинированно.
+3. Какая операция отвечает за пополнение.
+4. Нужно ли делать отдельную регистрацию кошелька сияния или использовать существующую регистрацию пользователя.
+5. Как баланс восстанавливается после перезагрузки клиента.
+6. Какие права нужны для пополнения и списания.
+7. Нужна ли история операций баланса.
+
+## Вопросы перед реализацией
+
+1. Пополнение баланса сияния должно идти через основной блокчейн SHiNE или через Solana-программу.
+2. Нужна ли конвертация из SOL/AR в сияние.
+3. Кто может выпускать или начислять сияние.
+4. Нужно ли поддерживать перевод сияния между пользователями.
+5. Нужны ли лимиты, комиссии или статусы подтверждения.
+6. Какой экран должен показывать баланс: регистрация, профиль, кошелёк или отдельная страница.
+7. Нужно ли отображать неподтверждённый баланс отдельно от подтверждённого.
+
+## Важное ограничение
+
+Если для баланса сияния потребуется новый формат блокчейн-блока или изменение существующего формата, перед реализацией нужно отдельно предупредить пользователя и получить явное подтверждение на изменение формата блокчейна.
+
+Если потребуется новый серверный API или изменение существующих `op`, перед реализацией нужно отдельно предупредить пользователя и получить явное подтверждение на изменение API.
+
+## Документы, которые обновить при реализации
+
+- `Dev_Docs/Blockchain/`, если появятся или изменятся блоки баланса.
+- `Dev_Docs/Blockchain/CHANGELOG.md`, если меняется блокчейн-формат.
+- `Dev_Docs/API/`, если меняется серверный API.
+- `Dev_Docs/Pending_Features/` - добавить файл ручной проверки после реализации.
+- Документацию Solana-регистрации, если баланс будет связан с Solana-модулем.
+
+## Минимальная проверка в будущем
+
+1. Новый пользователь видит корректный начальный баланс.
+2. Пополнение создаёт правильную операцию.
+3. Баланс обновляется после подтверждения.
+4. После перезагрузки UI баланс остаётся корректным.
+5. Ошибочные или повторные операции не начисляют баланс дважды.

TODO/medium/2026-05-26_0029_esp32s3_file_storage.md

@@ -0,0 +1,44 @@
+# ESP32S3 как личное файловое хранилище SHiNE
+
+## Горизонт
+
+Среднесрочный: ближайшие недели или 1-2 месяца.
+
+## Зачем нужна фича
+
+Нужно проработать маленький физический сервер на ESP32S3 как персональное или доверенное файловое хранилище SHiNE.
+
+Идея: при обмене сообщениями пользователи смогут использовать такой сервер для хранения своих файлов, вложений, файлов общих переписок и связанных данных.
+
+## Что нужно сделать
+
+- Описать роль ESP32S3-сервера в общей архитектуре ключей и сессий.
+- Определить, какие ключи может хранить такое устройство.
+- Решить, хранит ли устройство только файлы или также подписывает пользовательские операции.
+- Описать протокол загрузки, скачивания и удаления файлов.
+- Определить правила шифрования файлов до отправки на устройство.
+- Продумать индексацию файлов для личных и общих переписок.
+- Решить, как устройство авторизуется на основном сервере SHiNE.
+
+## Вопросы перед реализацией
+
+- ESP32S3 должен работать как полностью локальное устройство или как публично доступный мини-сервер?
+- Нужен ли внешний relay, если устройство находится за NAT?
+- Какие ограничения по размеру файла считаем допустимыми?
+- Хранит ли устройство метаданные переписок или только зашифрованные blob-файлы?
+- Как восстанавливать доступ, если устройство потеряно или заменено?
+
+## Что уже сделано
+
+Код не реализован. Идея зафиксирована как будущая задача после описания модели ключей.
+
+## Документы, которые нужно обновить при возврате
+
+- `Dev_Docs/Keys/README.md`
+- `Dev_Docs/Personal_Messages/README.md`
+- `Dev_Docs/API/`
+- `Dev_Docs/Blockchain/`, если появятся новые блоки или команды для файлов.
+
+## С какого места продолжать
+
+Начать с короткого протокольного документа: роли устройства, авторизация, шифрование файлов, минимальные API-операции и сценарии восстановления.

TODO/medium/2026-06-02_сессионные_homeserver_в_pda.md

@@ -0,0 +1,105 @@
+# Сессионные homeserver-ы в PDA пользователя
+
+- Статус:
+  `future`
+
+- Горизонт:
+  `medium`
+
+- Ориентир:
+  после завершения первого этапа по пользовательским сессиям
+
+- Основание:
+  Идея зафиксирована после обсуждения архитектуры пользовательских сессий и внутренних homeserver-ов. Сейчас задача сознательно отложена: сначала нужно аккуратно ввести базовую модель сессий, а затем возвращаться к расширенной серверной роли.
+
+## Зачем нужна фича
+
+У одного пользователя может быть несколько доверенных внутренних homeserver-ов, и каждый из них должен жить как отдельная пользовательская сессия, а не как отдельная особая сущность вне общей модели.
+
+Это нужно, чтобы:
+
+- хранить несколько homeserver-ов у одного пользователя одновременно;
+- различать обычные клиентские сессии и серверные сессии по явному типу;
+- дать расширяемый формат записи с версией;
+- использовать единый подход для DM, звонков и внутренних команд между сессиями.
+
+## Целевая идея
+
+В пользовательском PDA должен появиться список записей сессий, где каждая запись содержит как минимум:
+
+- `sessionType` (`u8`);
+- `sessionVersion` (`u8`);
+- `sessionName`;
+- `sessionPubKey`.
+
+Предварительные значения:
+
+- тип `1` - обычная пользовательская сессия;
+- тип `100` - homeserver пользователя;
+- версия `1` - первая рабочая версия формата записи сессии.
+
+На текущем этапе под это уже зарезервирован отдельный блок `SessionsBlock` с `block_type = 55`, а `TrustedStateBlock` остаётся на `50`.
+
+Важно: homeserver-ов у одного пользователя может быть несколько.
+
+## Архитектурный принцип
+
+Внутренний протокол взаимодействия должен оставаться транспортным.
+
+То есть SHiNE-сервер не должен разбирать прикладной смысл внутренней нагрузки homeserver-а, а должен:
+
+- доставлять сообщения между сессиями;
+- доставлять сигналы звонков между сессиями;
+- хранить и маршрутизировать адресацию;
+- не принимать на себя бизнес-логику содержимого внутренних команд.
+
+## Что уже подтверждается текущим кодом
+
+- Личные сообщения уже доставляются по всем сессиям целевого пользователя с отдельным учётом доставки на каждую сессию.
+- Подтверждение доставки DM уже идёт отдельно по каждой сессии.
+- Вызов звонка уже рассылается по нескольким активным сессиям пользователя.
+- Сигналы звонка уже адресуются конкретной сессии, а stop-сигналы дублируются на остальные сессии того же пользователя.
+
+Иными словами, текущая серверная логика ближе к модели "сервер доставляет между сессиями", чем к модели "сервер понимает внутренний протокол homeserver-а".
+
+## Что нужно сделать при возврате к задаче
+
+1. Согласовать финальный бинарный формат записи сессии в PDA пользователя.
+2. Проверить, не меняет ли это уже опубликованный формат пользовательской PDA-записи.
+3. Если формат PDA меняется, заранее предупредить пользователя и получить отдельное подтверждение.
+4. Решить, где именно хранится массив сессий:
+   - в основной записи пользователя;
+   - в отдельной PDA-структуре расширения;
+   - или в смешанной схеме с базовой записью и внешними индексами.
+5. Зафиксировать ограничения:
+   - максимальное число сессий;
+   - максимальную длину `sessionName`;
+   - правила удаления и обновления записи;
+   - правила ротации `sessionPubKey`.
+6. Продумать, как UI и сервер будут отличать тип `1` и тип `100`.
+7. Определить, какие внутренние сообщения homeserver-а останутся полностью прозрачными для SHiNE-сервера, а какие потребуют только технической маршрутизации.
+8. Добавить API/операции чтения и обновления списка сессий, если для этого не хватит существующих механизмов.
+9. После реализации обязательно обновить документацию.
+
+## Что нужно обновить при реализации
+
+- `shine-solana/shine/doc/formats/shine-user-pda-format-v.1.0.md`
+- `Dev_Docs/Solana_Architecture/README.md`
+- `Dev_Docs/Инициализация_Solana_регистрации/README.md`
+- `Dev_Docs/Keys/README.md`
+- `Dev_Docs/Personal_Messages/README.md`, если изменится адресация DM по типам сессий
+- `Dev_Docs/API/`, если появятся новые серверные операции или изменятся ответы
+
+## Что пока не делать
+
+- Не включать это автоматически в основной deploy сервера.
+- Не менять сейчас Solana PDA-формат без отдельного подтверждения.
+- Не добавлять временные поля в публичный API "на всякий случай".
+
+## С какого места продолжать
+
+Продолжать после завершения первой части:
+
+1. описать минимальный формат записи пользовательской сессии;
+2. отдельно решить, живут ли homeserver-ы в том же списке, что и обычные сессии;
+3. затем уже проектировать операции регистрации, обновления и отключения таких сессий.

TODO/medium/2026-06-03_подключение_других_устройств_через_qr.md

@@ -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`
+- документацию по ключам, если формат переноса меняется
+

TODO/near/2026-05-25_1106_telegram_agent_players.md

@@ -0,0 +1,94 @@
+# Telegram-агент для разрешённых игроков
+
+- Горизонт:
+  `near`
+- Ориентир:
+  сегодня/завтра
+- Статус:
+  `proposal`
+
+## Кратко
+
+Нужно расширить `SHiNE-agent-bot-coder`, чтобы агент мог принимать личные сообщения от заранее разрешённых пользователей, вести по каждому отдельную рабочую папку и историю, помогать им с обсуждениями/документами без изменения кода, а краткий результат публиковать в общий канал.
+
+## Пользовательский сценарий
+
+1. Разрешённый пользователь пишет агенту в личные сообщения текстом или голосом.
+2. Голосовое сообщение распознаётся так же, как сейчас распознаются voice/audio-задачи.
+3. Сервис определяет пользователя по разрешённому списку логинов.
+4. Для пользователя используется отдельная папка в `Players/`.
+5. Codex запускается с системным контекстом: от имени какого человека он работает, где лежит его папка, какие у него локальные инструкции.
+6. Агент может читать код и документацию проекта, но писать должен только в папку этого пользователя, если нет отдельного согласования на изменение общего проекта.
+7. После ответа пользователю агент отправляет в общий канал короткую сводку двумя сообщениями или двумя блоками: вопрос пользователя и полученный ответ.
+8. Команда `/new` или `New` сбрасывает только сессию этого пользователя.
+
+## Предлагаемая структура
+
+- `Players/`
+  - `Ivan/`
+    - `AGENTS.md`
+    - `history/`
+    - `files/`
+  - `Sergey/`
+    - `AGENTS.md`
+    - `history/`
+    - `files/`
+  - `Milana/`
+    - `AGENTS.md`
+    - `history/`
+    - `files/`
+
+Имена папок можно уточнить после получения точных Telegram-логинов.
+
+## Что нужно сделать
+
+1. Добавить конфигурацию разрешённых Telegram-пользователей.
+2. Описать соответствие `telegram username -> имя игрока -> папка`.
+3. Создавать или использовать отдельную историю диалога для каждого игрока.
+4. Поддержать личные сообщения от разрешённых пользователей.
+5. Запретить постановку задач от неизвестных пользователей.
+6. Для групп/каналов оставить текущую логику: команды Айдара имеют приоритет.
+7. При запуске Codex для игрока добавлять отдельный системный контекст:
+   - имя пользователя;
+   - путь к его папке;
+   - правило записи только в эту папку;
+   - путь к персональному `AGENTS.md`.
+8. После ответа игроку отправлять краткую сводку в общий канал.
+9. Поддержать `/new`/`New` как сброс только персональной сессии игрока.
+10. Добавить защиту от случайного изменения общего кода в режиме игрока.
+
+## Вопросы перед реализацией
+
+1. Точные Telegram-логины Ивана, Сергея и Миланы.
+2. Какой общий канал использовать для сводок: текущий `@shine_writing` или отдельный чат.
+3. Нужно ли отправлять в общий канал полный текст вопроса/ответа или краткую выжимку.
+4. Нужно ли пересылать вложения игроков в общий канал или только текстовые сводки.
+5. Разрешить ли игрокам читать все документы проекта, включая технические заметки деплоя.
+6. Что делать, если пользователь просит изменить код: отказать, создать предложение в своей папке или просить подтверждение Айдара.
+7. Нужны ли русские имена папок (`Иван`, `Сергей`, `Милана`) или ASCII-имена (`Ivan`, `Sergey`, `Milana`).
+8. Нужно ли хранить истории игроков в общей папке сервиса или внутри `Players/<name>/history/`.
+
+## Риски и ограничения
+
+- Нужно аккуратно разделить режим Айдара и режим игрока, чтобы игроки не могли случайно запустить изменение общего кода.
+- Нужно не смешать истории разных пользователей.
+- Нужно ограничить публикацию в общий канал, чтобы не утекали личные или слишком длинные ответы.
+- Нужна проверка Telegram-идентификации: username может меняться, поэтому желательно хранить и `user_id`.
+
+## Документы, которые обновить при реализации
+
+- `SHiNE-agent-bot-coder/AGENTS.md`
+- `SHiNE-agent-bot-coder/AGENT.md`
+- `SHiNE-agent-bot-coder/README.md`
+- `Dev_Docs/deploy/agent-bot-coder-local-systemd.md`, если появятся новые переменные окружения или настройки сервиса.
+
+## Минимальная проверка
+
+1. Айдар по-прежнему может ставить задачи из `@shine_writing`.
+2. Неизвестный пользователь не ставит задачу в очередь.
+3. Разрешённый игрок пишет личное текстовое сообщение и получает ответ.
+4. Разрешённый игрок отправляет voice, оно распознаётся и обрабатывается.
+5. История одного игрока не попадает в историю другого.
+6. `/new` сбрасывает только историю текущего игрока.
+7. Сводка вопрос/ответ появляется в общем канале.
+8. В режиме игрока агент не пишет за пределы `Players/<name>/` без отдельного подтверждения.

TODO/near/2026-05-25_1106_wallet_topup_solana_arweave.md

@@ -0,0 +1,71 @@
+# Пополнение Solana и Arweave через внешний сервис покупки
+
+- Горизонт:
+  `near`
+- Ориентир:
+  сегодня/завтра
+- Статус:
+  `proposal`
+
+## Кратко
+
+Нужно добавить удобное пополнение кошельков на экране регистрации/кошелька: для Solana и Arweave дать отдельные действия `Пополнить`, которые ведут на международный сервис покупки криптовалюты с карты и помогают пользователю скопировать адрес кошелька.
+
+## Пользовательский сценарий
+
+1. Пользователь видит адрес кошелька Solana или Arweave.
+2. Нажимает `Пополнить`.
+3. Открывается промежуточное окно с инструкцией:
+   - сейчас пользователь перейдёт на страницу покупки/пополнения;
+   - нужно указать или проверить адрес кошелька;
+   - после оплаты нужно закрыть внешнюю страницу и вернуться назад;
+   - Solana обычно приходит быстро, ориентир 10-15 секунд после подтверждения сети;
+   - Arweave может идти дольше, точное время нужно уточнить по выбранному сервису.
+4. В окне есть кнопки:
+   - `Скопировать адрес и перейти`;
+   - `Перейти без копирования`.
+5. Для Solana и Arweave используются разные окна/инструкции и, возможно, разные внешние ссылки.
+
+## Что нужно сделать
+
+1. Найти текущий экран, где показываются кошельки при регистрации и пополнении.
+2. Найти текущую ссылку покупки Arweave, если она уже есть в UI.
+3. Выбрать международный сервис покупки Solana с карты, не российский.
+4. Проверить, поддерживает ли сервис deep link с предзаполненным адресом кошелька.
+5. Если deep link невозможен, реализовать промежуточное окно с копированием адреса.
+6. Добавить отдельные действия для Solana и Arweave.
+7. Сделать текст инструкции коротким и понятным.
+8. Проверить, что адрес копируется в буфер обмена в браузере.
+9. Проверить мобильный сценарий и desktop-сценарий.
+
+## Вопросы перед реализацией
+
+1. Какой сервис покупки Solana использовать: тот же провайдер, что для Arweave, или другой международный on-ramp.
+2. Нужно ли разрешать покупку только SOL или также USDC/SPL-токены на Solana.
+3. Где именно показывать кнопку `Пополнить`: только регистрация, настройки кошелька или оба места.
+4. Нужно ли показывать предупреждение о комиссиях и стороннем сервисе.
+5. Нужно ли открывать внешнюю страницу в новой вкладке или в текущем окне.
+6. Нужно ли логировать факт нажатия `Пополнить` на сервере.
+7. Какой точный текст использовать для времени прихода Arweave.
+
+## Риски и ограничения
+
+- On-ramp-сервисы меняют ссылки и параметры, поэтому deep link нужно проверять перед реализацией.
+- Clipboard API может требовать HTTPS и пользовательский жест.
+- Нельзя обещать точное время поступления средств: лучше писать ориентир и зависимость от сети/провайдера.
+- Внешний сервис может быть недоступен в отдельных странах или для отдельных карт.
+
+## Документы, которые обновить при реализации
+
+- Документацию UI/кошельков, если такая есть.
+- `Dev_Docs/Pending_Features/` - добавить файл ручной проверки после реализации.
+- `Dev_Docs/API/`, только если появится новый серверный API или логирование.
+
+## Минимальная проверка
+
+1. На Solana-кошельке открывается правильное окно пополнения.
+2. Кнопка `Скопировать адрес и перейти` копирует Solana-адрес и открывает внешний сервис.
+3. Кнопка `Перейти без копирования` открывает внешний сервис без копирования.
+4. Аналогичный сценарий работает для Arweave.
+5. На мобильном экране текст и кнопки не перекрываются.
+6. Возврат назад в приложение не ломает состояние регистрации/кошелька.