SHiNE-server/task/2.md

Задача 2 — Проверка API-доков по личным данным и сессиям

Что проверяем

1. В 03_Session_Management_API.md описан формат sessionId и правило «передавать как есть».
2. В 04_Add_Block_to_Blockchain_API.md описан набор ключей USER_PARAM для личных данных.
3. В 05_Technical_Requests_API.md зафиксировано, что отдельного RPC для direct tech message в конкретную сессию пока нет.

Как должна выглядеть рабочая логика

• Клиент сохраняет личные данные через UpsertUserParam по стандартным ключам.
• При повторном изменении поля клиент пишет новую запись с более поздним временем.
• Актуальное значение получается через ListUserParams (берётся самая новая запись по ключу).
• Для отправки техсообщений в конкретную сессию нужен отдельный RPC, которого пока нет.

Критерии приёмки

• Термины и пояснения в документации понятны без чтения кода.
• Примеры ключей единообразны (name, last_name, address_physical, address_web, phone).
• Ограничения MVP явно указаны (ACL/валидация/отдельный direct-session RPC).