07-04-2026

Сделал вкладку параметры пользователя РАБОТАЮЩЕЙ Добавил - Локальный запуск - техническое задание 1 (доработать ui что бы RFYFKS работали)
2026-04-07 14:43:08 +03:00 · 2026-04-07 14:43:08 +03:00 · 0c7d8fac02
commit 0c7d8fac02
parent 0b7ad79032
6 changed files with 247 additions and 234 deletions
--- a/TASKS/01-07.04.26-каналы-api/01-ТЗ-каналы.md
+++ b/TASKS/01-07.04.26-каналы-api/01-ТЗ-каналы.md
@ -0,0 +1,220 @@
+# Задача 01: Доработка вкладки «Каналы» (UI + API)
+
+## Кратко и по делу
+Нужно довести вторую вкладку «Каналы» до полностью рабочего состояния на реальных данных сервера.
+
+Что должно работать:
+- список каналов;
+- вход в канал и чтение сообщений;
+- вход в тред сообщения (история/ветка);
+- ответ на сообщение;
+- лайк/снятие лайка;
+- подписка на пользователя;
+- подписка на канал;
+- видимое имя канала в формате `имя_пользователя/имя_канала`.
+
+Запись любых новых сущностей делается через `AddBlock` с подписью на клиенте.
+Чтение делается через 3 API:
+- `ListSubscriptionsFeed`
+- `GetChannelMessages`
+- `GetMessageThread`
+
+Техническая особенность (оставляем как есть):
+- на экране каналов индикатор непрочитанного = общее число сообщений канала.
+
+---
+
+## Подробное ТЗ
+
+### 1. Цель
+Сделать рабочий каналовый сценарий «от списка до треда», где чтение строится на RPC API, а запись действий пользователя — только через `AddBlock`.
+
+### 2. Что уже есть в проекте
+
+#### 2.1 UI (частично)
+- Есть страницы:
+  - `channels-list`
+  - `channel-view`
+  - `add-channel-view`
+- Есть запросы чтения в клиенте:
+  - `authService.listSubscriptionsFeed(...)`
+  - `authService.getChannelMessages(...)`
+  - `authService.getMessageThread(...)`
+- Есть fallback на mock-данные при ошибках сервера.
+
+#### 2.2 API/сервер (уже реализованы)
+- `ListSubscriptionsFeed`
+- `GetChannelMessages`
+- `GetMessageThread`
+- `AddBlock`
+
+#### 2.3 Тесты
+- Есть интеграционный тест API каналов: `IT_06_ChannelsApi`.
+- Есть тесты генерации блоков каналов/связей: `IT_03_AddBlock_NoAuth`.
+- Формат `AddBlock` и его сборка/подпись описаны в `AddBlockSender`.
+
+### 3. Проблемы текущей реализации (что надо закрыть)
+- Кнопки «подписаться на человека/канал» в списке каналов сейчас UI-only (модалка без реальной записи через `AddBlock`).
+- `add-channel-view` пока не создает канал на сервере через `AddBlock` (`CreateChannelBody`), только делает `navigate`.
+- `channel-view` добавляет пост локально (в память), а не отправляет блок `TEXT_POST` через `AddBlock`.
+- Нет полноценного экрана треда сообщения с реальными `GetMessageThread` и действиями `ответить/лайк/убрать лайк` через блоки.
+- Нет гарантированного отображения канала в требуемом формате `ownerLogin/channelName`.
+
+### 4. Функциональные требования
+
+#### 4.1 Список каналов
+На вкладке «Каналы» отображать 3 группы:
+- Мои каналы
+- Каналы пользователей, на кого я подписан
+- Каналы, на которые я подписан
+
+Источник данных: `ListSubscriptionsFeed`.
+
+Каждый канал показывать в формате:
+- `ownerLogin/channelName`
+
+#### 4.2 Открытие канала
+При входе в канал:
+- загрузить сообщения через `GetChannelMessages`;
+- показать список сообщений в хронологическом порядке (по текущему параметру `sort`);
+- оставить техническую особенность непрочитанных как есть.
+
+#### 4.3 Открытие треда сообщения
+При клике на сообщение:
+- загрузить тред через `GetMessageThread`;
+- показать `ancestors`, `focus`, `descendants`;
+- из треда должны быть доступны действия:
+  - «Ответить»
+  - «Лайк»
+  - «Убрать лайк»
+
+Запись действий — только `AddBlock`.
+
+#### 4.4 Создание канала
+В `add-channel-view` кнопка «Создать» должна:
+- отправлять `AddBlock` с телом `CreateChannelBody`;
+- после успеха возвращать к списку каналов и обновлять его.
+
+#### 4.5 Подписки
+- Подписка на пользователя: `AddBlock` с `ConnectionBody` подтип `CONNECTION_FOLLOW`, target = HEADER пользователя.
+- Подписка на канал: `AddBlock` с `ConnectionBody` подтип `CONNECTION_FOLLOW`, target = root блока канала (`CreateChannelBody` или HEADER для канала `0`).
+
+### 5. API (форматы)
+
+## 5.1 ListSubscriptionsFeed (чтение)
+Request:
+```json
+{
+  "op": "ListSubscriptionsFeed",
+  "requestId": "...",
+  "payload": {
+    "login": "A1",
+    "limit": 200
+  }
+}
+```
+
+Response (смысловые поля):
+- `ownedChannels[]`
+- `followedUsersChannels[]`
+- `followedChannels[]`
+
+---
+
+## 5.2 GetChannelMessages (чтение)
+Request:
+```json
+{
+  "op": "GetChannelMessages",
+  "requestId": "...",
+  "payload": {
+    "channel": {
+      "ownerBlockchainName": "A1-001",
+      "channelRootBlockNumber": 0,
+      "channelRootBlockHash": ""
+    },
+    "limit": 200,
+    "sort": "asc"
+  }
+}
+```
+
+Response (смысловые поля):
+- `channel`
+- `messages[]`
+
+---
+
+## 5.3 GetMessageThread (чтение)
+Request:
+```json
+{
+  "op": "GetMessageThread",
+  "requestId": "...",
+  "payload": {
+    "message": {
+      "blockchainName": "A1-001",
+      "blockNumber": 15,
+      "blockHash": "..."
+    },
+    "depthUp": 20,
+    "depthDown": 2,
+    "limitChildrenPerNode": 50
+  }
+}
+```
+
+Response (смысловые поля):
+- `ancestors[]`
+- `focus`
+- `descendants[]`
+
+---
+
+## 5.4 AddBlock (запись)
+Любое изменение (создать канал, пост, reply, реакция, подписка) записывается через:
+```json
+{
+  "op": "AddBlock",
+  "requestId": "...",
+  "payload": {
+    "blockchainName": "A1-001",
+    "blockNumber": 6,
+    "prevBlockHash": "<64-hex>",
+    "blockBytesB64": "<base64 full block>"
+  }
+}
+```
+
+Важно:
+- `blockBytesB64` формируется на клиенте.
+- Подпись блока формируется на клиенте приватным blockchain key пользователя.
+- Перед добавлением блока клиент берет актуальный курсор цепочки с сервера.
+
+### 6. Типы блоков для каналов и связей (через AddBlock)
+- Создание канала: `CreateChannelBody`
+- Пост/ответ: `TextBody` (`TEXT_POST`, `TEXT_REPLY`)
+- Реакции: `ReactionBody` (лайк/снятие лайка)
+- Подписки: `ConnectionBody` (`CONNECTION_FOLLOW`)
+
+### 7. Критерии приемки
+- Список каналов отображается с реальными данными API.
+- Формат названия канала в UI: `ownerLogin/channelName`.
+- Создание канала реально пишет блок и канал появляется после обновления.
+- Отправка поста/ответа/реакций реально пишет блок и видна после перечитки API.
+- Подписка на пользователя/канал реально пишет блок и отражается в выдаче.
+- Переход в тред сообщения показывает реальные `ancestors/focus/descendants`.
+- Непрочитанные в списке каналов = общее число сообщений (временное правило).
+
+### 8. Локальный запуск (уже сделано)
+Команда:
+```bash
+./gradlew startLocal
+```
+
+Что делает:
+- чистит логи;
+- билдит сервер;
+- запускает локальный WS сервер;
+- запускает локальный HTTP сервер клиента;
+- открывает браузер по URL с параметром `localWsPort`.
--- a/TASKS/01-07.04.26-каналы-api/01-кратко-для-внешних.md
+++ b/TASKS/01-07.04.26-каналы-api/01-кратко-для-внешних.md
@ -0,0 +1,25 @@
+# Краткое описание задачи
+
+Нужно сделать полностью рабочую вкладку «Каналы» в SHiNE.
+
+Пользователь должен:
+- видеть список каналов;
+- открывать канал и читать сообщения;
+- открывать тред сообщения;
+- отвечать, ставить и убирать лайк;
+- подписываться на пользователей и каналы.
+
+Чтение данных идет через 3 API:
+- `ListSubscriptionsFeed`
+- `GetChannelMessages`
+- `GetMessageThread`
+
+Все действия записи делаются только через `AddBlock` с подписью на клиенте.
+
+Формат имени канала в интерфейсе:
+- `имя_пользователя/имя_канала`
+
+Локальный запуск проекта:
+```bash
+./gradlew startLocal
+```
--- a/TASKS/CHAT_PWA_HANDOFF.md
+++ b/TASKS/CHAT_PWA_HANDOFF.md
@ -1,203 +0,0 @@
-# Анонс для исполнителя (кратко)
-
-Ниже описан текущий статус ветки по функциям:
- PWA + FCM уведомления
- личные сообщения (вторая слева вкладка, "Личные сообщения")
- связи / близкие друзья (центральная вкладка)
- server-push события (в том числе закрытие сессии)
-
-## Что нужно проверить и довести до рабочего состояния
-1. **PWA/FCM**: регистрация service worker, получение FCM token, отправка token на сервер, получение foreground/background уведомлений.
-2. **Личные сообщения**: отправка первого сообщения любому пользователю, входящие по WS, ACK, fallback в FCM, дедупликация на клиенте.
-3. **Связи / близкие друзья**: поиск пользователя, добавление в близкие, обновление графа связей сразу после добавления.
-4. **SessionRevoked**: если сессию закрыли с другого устройства, клиент должен корректно завершить локальную сессию и показать понятное состояние.
-
-## Главная цель handoff
-Сделать так, чтобы все описанные сценарии стабильно работали end-to-end без ручных "подпинок".
-
---
-
-# Подробное ТЗ и технические детали
-
-## 1) Архитектура протокола и общие принципы
-
-### 1.1 Формат обмена
-Используется JSON-over-WebSocket.
- Для запрос-ответ: `op + requestId + payload`
- Для server-push событий: те же поля, но `event=true`, `requestId` используется как eventId.
-
-### 1.2 ID сообщений/событий
-ID генерируются в формате:
- `prefix-yyyyMMdd-HHmmss-SSS-random10`
-
-Реализация: `NetIdGenerator`.
-
-### 1.3 Роли каналов доставки
- **WS** — приоритетная доставка в активные сессии.
- **FCM** — fallback, если ACK по WS не получен или WS-сессия отсутствует.
-
---
-
-## 2) PWA + FCM
-
-## 2.1 Что уже добавлено
-### Клиент
- `shine-UI/manifest.webmanifest`
- `shine-UI/firebase-messaging-sw.js`
- `shine-UI/js/services/pwa-push-service.js`
- `shine-UI/index.html` содержит placeholders:
-  - `window.__SHINE_FIREBASE_CONFIG__`
-  - `window.__SHINE_FIREBASE_VAPID_KEY__`
-
-### Сервер
- API `UpsertPushToken`
- Таблица `user_push_tokens`
- Серверный FCM sender (legacy HTTP): `FcmPushSender`
- Конфиг: `fcm.server.key` в `application.properties`
-
-## 2.2 Как должно работать (целевое поведение)
-1. Клиент после авторизации регистрирует SW.
-2. Просит permission на notifications.
-3. Получает FCM token.
-4. Если token новый/изменился — отправляет `UpsertPushToken`.
-5. Сервер сохраняет token за конкретной сессией.
-
-## 2.3 Что проверить/доделать
- Синхронизация Firebase config между `index.html` и `firebase-messaging-sw.js`.
- Работа iOS Safari (PWA через Home Screen).
- Поведение при смене token.
- Надёжность `FcmPushSender` (таймауты, логирование ошибок ответа).
-
---
-
-## 3) Вторая слева вкладка: Личные сообщения / Чаты
-
-## 3.1 Продуктовая логика (как должно быть)
-1. Открытие списка диалогов на вкладке "Личные сообщения".
-2. Кнопка `+` открывает поиск пользователя по префиксу логина (`SearchUsers`).
-3. **Первое сообщение можно отправить любому пользователю**, даже если он не контакт.
-4. Если пользователь не в контактах — в чате показывается действие "Добавить в контакты".
-5. Входящее сообщение может прийти:
-   - напрямую по WS (`IncomingDirectMessage`)
-   - через FCM (fallback)
-6. На клиенте дедупликация должна быть по `messageId`.
-
-## 3.2 Что уже сделано технически
-### Сервер
- `SendDirectMessage`
- `AckIncomingMessage`
- `direct_messages` таблица + DAO
- доставка по активным WS-сессиям + ожидание ACK + fallback в FCM
-
-### Клиент
- `authService.sendDirectMessage(...)`
- `authService.ackIncomingMessage(...)`
- WS client поддерживает server events (`onEvent`)
- В `app.js` обработка `IncomingDirectMessage`
- В `state.js` добавлены `incomingDedup`, `addIncomingMessage`
-
-## 3.3 Что глючит/что проверить
- Стабильность отображения новых чатов, если сообщение пришло от неизвестного пользователя.
- Согласованность списка диалогов и фактических сообщений.
- Поведение при быстрых дубликатах WS + FCM.
- Поведение при сетевых обрывах/повторном коннекте.
-
---
-
-## 4) Центральная вкладка: Связи / Близкие друзья
-
-## 4.1 Целевое поведение
-1. Экран "Связи" загружает граф друзей (`GetUserConnectionsGraph`).
-2. Кнопка "Добавить близкого друга" открывает модалку:
-   - поле логина/префикса
-   - кнопка "Поиск"
-   - кнопка "Назад"
-3. Поиск идёт через `SearchUsers`.
-4. По клику на найденного — подтверждение "Добавить? Да/Нет".
-5. При "Да" вызывается `AddCloseFriend`, после успеха:
-   - закрыть модалку
-   - вернуться на экран связей
-   - обновить граф.
-
-## 4.2 Что уже сделано
- UI-flow модалки реализован на `network-view.js`.
- API `AddCloseFriend` добавлен на сервере.
- `ConnectionsStateDAO.upsertRelation(...)` добавлен для upsert связи FRIEND.
-
-## 4.3 Что проверить/доделать
- Валидация edge-cases (добавление самого себя, несуществующий логин).
- Корректность отрисовки графа после добавления.
- Согласованность данных с будущей "настоящей" записью в blockchain (сейчас MVP upsert в `connections_state`).
-
---
-
-## 5) SessionRevoked и мультисессии
-
-## 5.1 Целевое поведение
-Если с другой сессии закрыли текущую сессию:
-1. сервер шлёт событие `SessionRevoked`
-2. клиент чистит локальную авторизацию
-3. клиент возвращается в состояние неавторизованного входа.
-
-## 5.2 Что проверить
- Что событие приходит до закрытия socket.
- Что UX не "зависает" на промежуточном экране.
-
---
-
-## 6) API-операции (быстрый список)
-
-### Уже используемые/добавленные в ветке
- `SearchUsers`
- `ListContacts`
- `GetUserConnectionsGraph`
- `AddCloseFriend`
- `UpsertPushToken`
- `SendDirectMessage`
- `AckIncomingMessage`
- `CloseActiveSession` (с server event `SessionRevoked`)
-
---
-
-## 7) Минимальный чек-лист тестирования для нового исполнителя
-
-1. Авторизация пользователя A и B в разных браузерах/устройствах.
-2. A отправляет первое сообщение B (без контактов) — должно уйти.
-3. B получает по WS, отправляется ACK, fallback FCM не должен дублировать.
-4. Выключить WS у B и проверить fallback FCM.
-5. Вкладка "Связи": добавить близкого друга через поиск, проверить обновление графа.
-6. Закрыть сессию B с другого устройства и проверить `SessionRevoked` UX.
-7. Перезапуск клиента: проверка повторной регистрации push-токена только при изменении.
-
---
-
-## 8) Важное ограничение текущей реализации
-
-Некоторые части реализованы как MVP и требуют стабилизации:
- местами UI/состояние могут рассинхронизироваться;
- fallback WS->FCM может требовать донастройки таймингов и ретраев;
- `AddCloseFriend` сейчас пишет прямое состояние связи (upsert), а не полный blockchain-поток создания блоков.
-
-Это ожидаемо для handoff: задача следующего исполнителя — довести до production-стабильности.
-
---
-
-## 9) Тестовые логины для быстрой проверки
-
-Для проверки работы системы можно использовать специальные тестовые аккаунты
-после выполнения теста `Seed_TestDataPopulation` (он создаёт их через API):
-
- `A1`
- `A2`
- `A3`
- `A4`
- `A5`
- `A6`
- `A7`
- `A8`
- `A9`
- `A10`
-
-Общий пароль для этих аккаунтов:
-
- `1`
--- a/build.gradle
+++ b/build.gradle
@ -203,6 +203,7 @@ tasks.register('startLocal', Exec) {
    description = "Builds server, starts local WS server and local HTTP UI for end-to-end local testing"

    dependsOn shadowJar
+    dependsOn cleanServerLogs

    workingDir = rootDir
    def wsPort = System.getProperty("localWsPort", "7070")
--- a/shine-server-net-protocol/src/main/java/server/logic/ws_protocol/JSON/handlers/blockchain/Net_AddBlock_Handler.java
+++ b/shine-server-net-protocol/src/main/java/server/logic/ws_protocol/JSON/handlers/blockchain/Net_AddBlock_Handler.java
@ -309,6 +309,7 @@ public final class Net_AddBlock_Handler implements JsonMessageHandler {

            // Нормализация: -1 не пишем в БД (для совместимости со старым TextBody)
            if (prevLineNumber != null && prevLineNumber == -1) {
+                lineCode = null;
                prevLineNumber = null;
                prevLineHash32 = null;
                thisLineNumber = null;
--- a/task/2.md
+++ b/task/2.md
@ -1,31 +0,0 @@
-# Задача 2 — Проверка работы личных данных и статусов профиля (правая вкладка)
-
-## Что реализовано
- На правой вкладке `Профиль` отображаются реальные пользовательские параметры, загружаемые через `ListUserParams`.
- Поля профиля:
-  - `first_name` (чтение с обратной совместимостью с `name`)
-  - `last_name`
-  - `address_physical`
-  - `address_web`
-  - `phone`
- Кнопка `Обновить` открывает форму редактирования и сохраняет изменения в пользовательские параметры блокчейна.
- Добавлены рабочие переключатели:
-  - `official`
-  - `shine`
- Для `official`/`shine` используется подтверждение перед записью, с предупреждением, что изменение идёт через блокчейн-параметры и требует подписи ключом пользователя.
- Если `official`/`shine` отсутствуют в параметрах, они считаются `no` по умолчанию.
-
-## Что проверить вручную
-1. Авторизоваться и открыть правую вкладку `Профиль`.
-2. Убедиться, что поля профиля читаются из `ListUserParams`, а не из заглушек.
-3. Нажать `Обновить`, изменить `first_name/last_name/address_physical/address_web/phone`, нажать `Сохранить`.
-4. Убедиться, что после сохранения данные перечитались и обновились на экране.
-5. Нажать `Официальный`, подтвердить изменение и проверить смену `no -> yes` (или `yes -> no`).
-6. Нажать `Сияющий`, подтвердить изменение и проверить смену `no -> yes` (или `yes -> no`).
-7. Обновить страницу и убедиться, что состояния `official/shine` и личные поля сохраняются.
-8. Проверить кейс отсутствия `official/shine` в истории: UI должен показывать `no`.
-
-## Ожидаемый результат
- Правая вкладка профиля работает с реальными данными пользователя.
- `official` и `shine` работают как настоящие параметры (yes/no), а не заглушки.
- После каждой записи UI делает повторный `ListUserParams` и показывает актуальное состояние.