Добавить TODO с планами на будущее

TODO/2026-06-26_1800_graceful_shutdown_30s.md

@@ -0,0 +1,40 @@
+# Graceful shutdown на 30 секунд
+
+## Зачем
+
+Чтобы при `restart` или `stop` сервер получал небольшой запас времени на завершение опасных операций:
+
+- текущий `AddBlock`;
+- full resync цепочки;
+- очистку marker-file;
+- дописывание временных файлов.
+
+Это должно уменьшить число случаев, когда приходится потом добирать хвост recovery-логикой.
+
+## Что сделать
+
+1. На стороне `systemd` задать `TimeoutStopSec=30s`.
+2. В коде добавить корректную обработку shutdown-сигнала:
+   - перестать принимать новые блоки и sync-задачи;
+   - дождаться текущих операций;
+   - выйти в пределах таймаута.
+3. При необходимости закрывать текущие ресурсы аккуратно:
+   - сетевые соединения;
+   - фоновые executor-ы;
+   - временные marker-файлы.
+
+## Что уже есть
+
+- `BlockchainTmpRecoveryOnStartup` и `BlockchainResyncRecoveryOnStartup` уже умеют добирать незавершённые хвосты после старта.
+- `AddBlock` уже стал crash-safe через `tmp_bch` / `write_check` / `write_pending`.
+
+## Откуда продолжать
+
+- начать с `systemd`-юнита и базового shutdown-hook в сервере;
+- затем проверить, что текущие операции реально завершаются в отведённые 30 секунд.
+
+## Какие документы потом обновить
+
+- `Dev_Docs/deploy/`;
+- `Dev_Docs/Blockchain/sync-between-servers.md`, если изменится поведение остановки/восстановления.
+

TODO/2026-06-26_1805_server_to_server_ws_and_dm_sync.md

@@ -0,0 +1,41 @@
+# Постоянный server-to-server WS и DM sync
+
+## Зачем
+
+Сейчас синхронизация между серверами работает в основном как periodic sync и one-shot push. Для нормальной репликации ещё нужен постоянный межсерверный канал:
+
+- живое подключение к партнёру;
+- push новых блоков;
+- push DM;
+- ACK на доставку;
+- backoff/reconnect;
+- стартовый backfill.
+
+## Что сделать
+
+1. Поднять постоянное WebSocket-соединение между партнёрскими серверами.
+2. Сделать push новых блоков сразу после `AddBlock`.
+3. Сделать push DM-блоков между серверами.
+4. Добавить ACK и повторную отправку при сбое.
+5. Ввести стартовый обмен курсорами и добор хвоста.
+
+## Что уже есть
+
+- `ListBlockchainHeads`;
+- `GetBlockchainBlock`;
+- `GetSyncUserProfile`;
+- базовый periodic sync;
+- базовый backfill хвоста;
+- базовый full resync при divergence.
+
+## Откуда продолжать
+
+- от текущего `sync_servers` bootstrap и `PeriodicBlockchainSyncService`;
+- дальше выделить отдельный межсерверный transport layer.
+
+## Какие документы потом обновить
+
+- `Dev_Docs/Blockchain/sync-between-servers.md`;
+- `Dev_Docs/Personal_Messages/README.md`;
+- `Dev_Docs/API/`.
+

TODO/2026-06-26_1810_qr_device_sessions.md

@@ -0,0 +1,30 @@
+# Подключение других устройств по QR и типизированные сессии
+
+## Зачем
+
+QR-подключение других устройств сейчас есть как заготовка, но сценарий нужно довести до устойчивого состояния. Параллельно надо аккуратно оформить типизированные сессии homeserver-ов в PDA.
+
+## Что сделать
+
+1. Довести QR-сценарий до стабильного подключения нового устройства.
+2. Нормально описать и хранить устройство как отдельную типизированную сессию.
+3. Согласовать это с серверной и UI-логикой.
+4. Проверить, что подключение работает одинаково на новом и повторном устройстве.
+
+## Что уже есть
+
+- в планах есть `сессионные homeserver-ы в PDA`;
+- в планах есть `подключение других устройств через QR`;
+- базовая заготовка уже существует, но сценарий считается нестабильным.
+
+## Откуда продолжать
+
+- от текущих документов в `Dev_Docs/Future_Features/medium/`;
+- отдельно проверить, какие поля уже есть в PDA и UI.
+
+## Какие документы потом обновить
+
+- `Dev_Docs/Solana_Architecture/README.md`;
+- `Dev_Docs/Future_Features/medium/2026-06-03_подключение_других_устройств_через_qr.md`;
+- `Dev_Docs/Future_Features/medium/2026-06-02_сессионные_homeserver_в_pda.md`.
+

TODO/2026-06-26_1815_esp32_file_storage.md

@@ -0,0 +1,29 @@
+# ESP32 как личное файловое хранилище
+
+## Зачем
+
+Планируется использовать ESP32 как личное файловое хранилище SHiNE для переписок и вложений.
+
+## Что сделать
+
+1. Продумать формат хранения файлов на устройстве.
+2. Согласовать загрузку и чтение файлов между UI, сервером и устройством.
+3. Проверить, как устройство показывает статусы и ошибки.
+4. Свести это с существующим homeserver/UI-прототипом.
+
+## Что уже есть
+
+- в списке будущих фич уже есть отдельная задача по ESP32S3 file storage;
+- для UI homeserver уже есть отдельная документация и скетч должны держаться синхронно.
+
+## Откуда продолжать
+
+- от `Dev_Docs/Future_Features/medium/2026-05-26_0029_esp32s3_file_storage.md`;
+- от документации по ESP32 UI homeserver.
+
+## Какие документы потом обновить
+
+- `Dev_Docs/Future_Features/medium/2026-05-26_0029_esp32s3_file_storage.md`;
+- `Dev_Docs/Future_Features/README.md`;
+- документацию по ESP32 UI homeserver, если добавятся экраны или статусы.
+

TODO/README.md

@@ -0,0 +1,22 @@
+# TODO
+
+Папка для короткого списка ближайших и среднесрочных задач, которые уже обсуждались и пока отложены.
+
+## Как использовать
+
+- Один markdown-файл = одна задача.
+- В файле коротко фиксируем:
+  - зачем это нужно;
+  - что именно сделать;
+  - что уже есть в коде;
+  - откуда продолжать;
+  - какие документы потом надо обновить.
+- Это не активная разработка. Тут только план и контекст.
+
+## Текущие задачи
+
+- `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 как личное файловое хранилище для переписок и вложений.
+

VERSION.properties

@@ -1,2 +1,2 @@
-client.version=1.2.279
-server.version=1.2.259
+client.version=1.2.280
+server.version=1.2.260