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

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