Очистить репозиторий перед переносом продукта

2026-07-20 18:46:56 +04:00
parent cf33f9a3bd
commit 81493ac4be
665 changed files with 231 additions and 1124 deletions
@@ -106,7 +106,9 @@ ESP32/**/*.a
 deploy/backup/archive/**
 !deploy/backup/archive/.gitkeep

-# Локальная дев-обвязка Claude (дев-сервер shine-UI, сессии, планы) — не коммитим
+# Локальная дев-обвязка AI-агентов (сессии, планы, настройки) — не коммитим
+.agents/
+.codex/
 .claude/
 # Рабочие бэкапы/превью-ассеты UI — не для репозитория
 *.bak.png
@@ -55,7 +55,6 @@
  - `far/` - дальнее будущее без понятного срока.
 - Если пользователь спрашивает, какие есть планы или что можно продолжить, нужно смотреть эти три папки и отвечать кратким списком по горизонтам.
 - Файлы из `TODO/` не начинать реализовывать без явной команды пользователя.
- После реализации фичи, требующей ручной проверки, нужно добавить отдельный файл в `docs/Pending_Features/`.

 ## Центр задач и предложений
 - Сервис хранит простые задачи и предложения в `data/task_center/items.json`.
@@ -0,0 +1,86 @@
+# Third-party notices
+
+This file lists third-party components and assets used by SHiNE. It is a practical attribution file for repository publication; individual dependency artifacts may include additional license text in their own packages.
+
+## Twemoji
+
+SHiNE UI uses Twemoji graphics for emoji rendering in the chat emoji picker and emoji-only messages.
+
+- Source: https://github.com/twitter/twemoji
+- Graphics license: Creative Commons Attribution 4.0 International (CC BY 4.0)
+- Code license: MIT
+- License text: https://creativecommons.org/licenses/by/4.0/
+
+Attribution:
+
+Emoji graphics by Twemoji, licensed under CC BY 4.0.
+
+Changes in SHiNE:
+
+- Emoji are stored and sent as normal Unicode text.
+- Twemoji SVG graphics are used only as a visual rendering layer in the web UI.
+- The UI loads Twemoji SVG assets from the pinned `twitter/twemoji@14.0.2` package via jsDelivr.
+
+## QR Code Generator
+
+SHiNE UI includes `shine-UI/js/vendor-qrcode-generator.js`.
+
+- Project: QR Code Generator for JavaScript
+- Copyright: Kazuhiko Arase
+- License: MIT
+- Source: http://www.d-project.com/
+
+## SHiNE project-owned visual assets
+
+SHiNE logos, icons and generated visual assets in `shine-UI/assets/` and `shine-UI/img/` are project-owned assets, unless a specific file says otherwise.
+
+## Solana JavaScript libraries
+
+SHiNE UI and Solana tooling use Solana JavaScript libraries, including `@solana/web3.js`.
+
+- Package: `@solana/web3.js`
+- License: MIT
+- Source: https://github.com/solana-foundation/solana-web3.js
+
+Some Solana JavaScript dependency trees include additional packages under permissive licenses such as MIT, Apache-2.0, BSD, ISC, 0BSD and CC0-1.0.
+
+Known stricter dependency:
+
+- Package: `rpc-websockets`
+- License: LGPL-3.0-only
+- Used transitively through Solana JavaScript dependencies in `shine-solana/shine` and `SHiNE-browser-plugin-wallet`.
+
+## Noble cryptography libraries
+
+SHiNE browser wallet/vendor bundles include Noble cryptography code.
+
+- Packages: `@noble/curves`, `@noble/hashes`
+- License: MIT
+- Source: https://github.com/paulmillr/noble-curves and https://github.com/paulmillr/noble-hashes
+
+## Java server dependencies
+
+The SHiNE Java server uses third-party dependencies from Maven Central, including:
+
+- Eclipse Jetty (`org.eclipse.jetty:*`) - EPL-2.0 / Apache-2.0 family licensing
+- Bouncy Castle (`org.bouncycastle:bcprov-jdk18on`) - Bouncy Castle permissive license
+- Jackson (`com.fasterxml.jackson.core:jackson-databind`) - Apache-2.0
+- Logback (`ch.qos.logback:logback-classic`) - EPL-1.0 / LGPL-2.1
+- SLF4J (`org.slf4j:slf4j-api`) - MIT
+- SQLite JDBC (`org.xerial:sqlite-jdbc`) - Apache-2.0
+- Web Push Java library (`nl.martijndwars:web-push`) - Apache-2.0
+- JUnit (`org.junit:*`) - EPL-2.0
+
+## Gradle Wrapper
+
+The repository includes Gradle wrapper scripts.
+
+- License: Apache License 2.0
+- Source: https://gradle.org/
+
+## Espressif code snippets
+
+The ESP32 prototype area includes Espressif audio codec helper files with SPDX/license headers.
+
+- Files include `ESPRESSIF MIT License` and `SPDX-License-Identifier: Apache-2.0` notices.
+- Original copyright notices are preserved in the source files.
@@ -1,64 +0,0 @@
-# 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 + сервер работают.
@@ -1,41 +0,0 @@
-# TODO: Будущие доработки
-
-## 1) Полный переход на `ReceiveOutcomingMessage`
- Сейчас в UI используется `ReceiveOutcomingMessage` с fallback на `SendMessagePair`.
- Fallback нужен только временно для совместимости со старыми серверами.
- После обновления всех серверов:
- убрать вызов `SendMessagePair` из UI,
- убрать регистрацию `SendMessagePair` на сервере (оставить только `ReceiveOutcomingMessage`).
-
-## 2) Реальная мультисерверная доставка
- Сейчас фактически предполагается 1 сервер на пользователя.
- Нужно реализовать штатную мультисерверную схему:
- пересылка исходящих сообщений между серверами пользователя A,
- пересылка входящих сообщений между серверами пользователя B,
- дедупликация на уровне БД для затухания дублей.
-
-## 3) Надёжная доставка при перезапуске сервера
- Сейчас возможен сценарий: запись уже сохранена в БД, но сервер не успел переслать дальше из-за перезапуска.
- Нужно добавить механизм «store + guaranteed forward»:
- очередь/аутбокс для межсерверной пересылки,
- фоновый ретрай до подтверждения отправки,
- корректная остановка (graceful shutdown) с дожатием критичных задач.
-
-## 4) Политика идемпотентности
- Сохранить принцип: пара (`incoming`, `outgoing`) пишется одной транзакцией, либо обе, либо ни одной.
- Не допускать частичного состояния, при котором в БД есть только один блок пары.
-
-## 5) Наблюдаемость и аналитика
- Добавить метрики по доставке:
- количество дублей,
- количество успешных вставок пар,
- доля доставок в WS/push,
- количество ретраев межсерверной пересылки.
-
-## 6) Ограничение текущих звонков (важно)
- Сейчас звонки работают только в рамках одного сигнального сервера (или единого контура, где обе стороны уже подключены).
- Сценарий «пользователь A на своих серверах, пользователь B на других серверах» пока не поддержан.
- TODO на будущее:
- временная межсерверная авторизация/сессия для старта звонка,
- отправка сигнальных сообщений между разными серверами пользователей,
- аккуратное завершение временной сессии после установления/завершения звонка.
@@ -1,41 +0,0 @@
-# TODO: Звонки и межсерверность
-
-## Текущее ограничение
- Текущая реализация звонков фактически работает в одном сигнальном контуре (один сервер/единый кластер, где обе стороны уже присутствуют).
- Если пользователь A подключён к серверу A, а пользователь B к серверу B (и между ними нет общего сигнального слоя), `CallInviteBroadcast`/`CallSignalToSession` не смогут полноценно провести звонок между ними.
-
-## Почему так сейчас
- Сигналинг звонка привязан к активным сессиям и событиям на конкретном сервере.
- Выбор целевой сессии (`sessionId`) и обмен `OFFER/ANSWER/ICE` происходит в рамках текущего сигнального контура.
- Push решает только «разбудить/уведомить», но не заменяет межсерверный сигнальный канал.
-
-## Что можно сделать дальше
- Добавить временное межсерверное подключение именно для старта и ведения звонка:
- инициатор получает short-lived access на сервер callee (или через доверенный межсерверный gateway),
- в рамках короткой сессии отправляет invite/signal для конкретного `callId`,
- после завершения звонка временная сессия закрывается автоматически.
-
-## Что нужно доработать для этого
-1. Межсерверная доверенная модель:
- подпись/верификация межсерверных вызовов,
- allowlist доверенных серверов и ротация ключей.
-
-2. Короткоживущая «call-only» авторизация:
- отдельный тип токена/сессии с TTL (например 1–3 минуты),
- минимальные права только на `CallInviteBroadcast/CallSignalToSession`.
-
-3. Маршрутизация сессий пользователя между серверами:
- где находится активная сессия callee,
- как доставлять `stop_call` и terminal-сигналы на все устройства callee.
-
-4. Идемпотентность и дедупликация:
- защита от повторов межсерверных сигналов по `callId + eventId`,
- корректная обработка out-of-order событий.
-
-5. Наблюдаемость:
- метрики межсерверной доставки сигналов,
- диагностика по стадиям звонка и причинам срыва.
-
-## Временный рабочий подход (до межсерверности)
- Держать звонки в одном сигнальном контуре.
- Использовать WebPush как fallback-уведомление (`incoming_call`/`stop_call`) для офлайн-сессий.
@@ -1,2 +1,2 @@
-client.version=1.2.331
-server.version=1.2.303
+client.version=1.2.332
+server.version=1.2.304
@@ -1,246 +0,0 @@
-#!/usr/bin/env bash
-
-set -euo pipefail
-
-GITHUB_USER="ai5590"
-TOKEN_VAR_NAME="GIT_AI5590_CLASSIC_API_KEY"
-
-print_line() {
-  echo "------------------------------------------------------------"
-}
-
-abort() {
-  echo
-  echo "Ошибка: $1" >&2
-  exit 1
-}
-
-require_command() {
-  command -v "$1" >/dev/null 2>&1 || abort "Не найдена команда '$1'. Установи её и запусти скрипт снова."
-}
-
-get_token() {
-  if [[ -z "${GIT_AI5590_CLASSIC_API_KEY:-}" ]]; then
-    abort "Не задана переменная окружения ${TOKEN_VAR_NAME}.
-Перед запуском выполни:
-export ${TOKEN_VAR_NAME}=\"ТВОЙ_GITHUB_TOKEN\""
-  fi
-}
-
-show_intro() {
-  print_line
-  echo "Этот скрипт создаст новый репозиторий в GitHub в аккаунте '${GITHUB_USER}',"
-  echo "затем инициализирует git в текущей папке (если нужно),"
-  echo "добавит файлы, кроме самого этого скрипта, создаст первый commit и отправит проект в GitHub."
-  echo
-  echo "Скрипт работает с содержимым ТЕКУЩЕЙ папки:"
-  echo "  $(pwd)"
-  echo
-  echo "Для авторизации используется переменная окружения:"
-  echo "  ${TOKEN_VAR_NAME}"
-  print_line
-  echo
-}
-
-ask_repo_name() {
-  local repo_name
-  read -r -p "Введите имя нового репозитория в GitHub: " repo_name
-  repo_name="$(echo "$repo_name" | xargs)"
-
-  [[ -n "$repo_name" ]] || abort "Имя репозитория не может быть пустым."
-
-  if [[ ! "$repo_name" =~ ^[A-Za-z0-9._-]+$ ]]; then
-    abort "Имя репозитория содержит недопустимые символы.
-Разрешены: буквы, цифры, точка, дефис, подчёркивание."
-  fi
-
-  REPO_NAME="$repo_name"
-}
-
-ask_visibility() {
-  local answer
-  echo
-  read -r -p "Сделать репозиторий публичным? [y/N]: " answer
-  answer="${answer:-N}"
-
-  case "$answer" in
-    y|Y|yes|YES|да|Да|ДА)
-      REPO_PRIVATE="false"
-      REPO_VISIBILITY_TEXT="public"
-      ;;
-    *)
-      REPO_PRIVATE="true"
-      REPO_VISIBILITY_TEXT="private"
-      ;;
-  esac
-}
-
-ask_confirmation() {
-  echo
-  print_line
-  echo "Будет выполнено:"
-  echo "1. Создание GitHub-репозитория '${GITHUB_USER}/${REPO_NAME}' (${REPO_VISIBILITY_TEXT})"
-  echo "2. Подготовка git в текущей папке"
-  echo "3. Commit файлов из текущей папки, кроме самого этого скрипта"
-  echo "4. Push в ветку main"
-  print_line
-  echo
-  read -r -p "Продолжить? [y/N]: " confirm
-  confirm="${confirm:-N}"
-
-  case "$confirm" in
-    y|Y|yes|YES|да|Да|ДА) ;;
-    *) echo "Отменено пользователем."; exit 0 ;;
-  esac
-}
-
-check_not_inside_wrong_git_repo() {
-  if git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
-    local top
-    top="$(git rev-parse --show-toplevel)"
-    if [[ "$top" != "$(pwd)" ]]; then
-      abort "Ты запустил скрипт внутри уже существующего git-репозитория, но не в его корне.
-Корень репозитория:
-  $top
-
-Либо перейди в корень этого репозитория, либо запусти скрипт в папке, которая не вложена в другой git-репозиторий."
-    fi
-  fi
-}
-
-create_github_repo() {
-  echo
-  echo "Создаю репозиторий в GitHub..."
-
-  local http_code
-  local response_body_file
-
-  response_body_file="$(mktemp)"
-
-  http_code="$(
-    curl -sS \
-      -o "$response_body_file" \
-      -w "%{http_code}" \
-      -X POST "https://api.github.com/user/repos" \
-      -H "Accept: application/vnd.github+json" \
-      -H "Authorization: Bearer ${GIT_AI5590_CLASSIC_API_KEY}" \
-      -H "X-GitHub-Api-Version: 2022-11-28" \
-      -d "$(cat <<JSON
-{
-  "name": "${REPO_NAME}",
-  "private": ${REPO_PRIVATE},
-  "auto_init": false
-}
-JSON
-)"
-  )"
-
-  if [[ "$http_code" != "201" ]]; then
-    echo
-    echo "GitHub API вернул ошибку. HTTP code: $http_code"
-    echo "Ответ сервера:"
-    cat "$response_body_file"
-    rm -f "$response_body_file"
-    abort "Не удалось создать репозиторий '${GITHUB_USER}/${REPO_NAME}'."
-  fi
-
-  rm -f "$response_body_file"
-  echo "Репозиторий успешно создан: https://github.com/${GITHUB_USER}/${REPO_NAME}"
-}
-
-get_script_paths() {
-  SCRIPT_PATH="$(realpath "${BASH_SOURCE[0]}")"
-  PROJECT_PATH="$(pwd -P)"
-
-  SCRIPT_INSIDE_PROJECT="false"
-  SCRIPT_RELATIVE_PATH=""
-
-  case "$SCRIPT_PATH" in
-    "$PROJECT_PATH"/*)
-      SCRIPT_INSIDE_PROJECT="true"
-      SCRIPT_RELATIVE_PATH="${SCRIPT_PATH#$PROJECT_PATH/}"
-      ;;
-    *)
-      SCRIPT_INSIDE_PROJECT="false"
-      ;;
-  esac
-}
-
-prepare_git_repo() {
-  echo
-  echo "Подготавливаю git в текущей папке..."
-
-  if git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
-    echo "Git уже инициализирован."
-  else
-    git init
-    echo "Git инициализирован."
-  fi
-
-  get_script_paths
-
-  if [[ "$SCRIPT_INSIDE_PROJECT" == "true" ]]; then
-    echo "Скрипт находится внутри проекта и будет исключён из commit:"
-    echo "  $SCRIPT_RELATIVE_PATH"
-    git add . ":!$SCRIPT_RELATIVE_PATH"
-  else
-    git add .
-  fi
-
-  if git diff --cached --quiet; then
-    echo "В staged нет изменений. Возможно, файлы уже были закоммичены ранее."
-  else
-    git commit -m "Initial commit"
-    echo "Создан commit: Initial commit"
-  fi
-
-  git branch -M main
-
-  local remote_url="https://${GITHUB_USER}:${GIT_AI5590_CLASSIC_API_KEY}@github.com/${GITHUB_USER}/${REPO_NAME}.git"
-
-  if git remote get-url origin >/dev/null 2>&1; then
-    echo "Remote 'origin' уже существует. Обновляю URL..."
-    git remote set-url origin "$remote_url"
-  else
-    git remote add origin "$remote_url"
-  fi
-}
-
-push_to_github() {
-  echo
-  echo "Отправляю проект в GitHub..."
-
-  git push -u origin main
-
-  echo
-  echo "Готово."
-  echo "Репозиторий: https://github.com/${GITHUB_USER}/${REPO_NAME}"
-}
-
-cleanup_remote_url() {
-  echo
-  echo "Убираю токен из remote URL, чтобы он не светился в git config..."
-
-  local safe_url="https://github.com/${GITHUB_USER}/${REPO_NAME}.git"
-  git remote set-url origin "$safe_url"
-
-  echo "Теперь origin = ${safe_url}"
-}
-
-main() {
-  require_command git
-  require_command curl
-  require_command realpath
-  get_token
-  check_not_inside_wrong_git_repo
-  show_intro
-  ask_repo_name
-  ask_visibility
-  ask_confirmation
-  create_github_repo
-  prepare_git_repo
-  push_to_github
-  cleanup_remote_url
-}
-
-main "$@"
@@ -1,17 +0,0 @@
-# SHiNE TURN Server
-
-This directory stores TURN setup scripts and operational instructions.
-
-## Purpose
- Install and configure coturn for SHiNE calls.
- Keep repeatable setup scripts for new TURN nodes.
- Keep TURN-related config templates.
-
-## Current production model
- Multiple TURN servers are supported by backend config section:
-  - `call.ice.turn.servers.1.*`
-  - `call.ice.turn.servers.2.*`
-  - ...
- Each server can use:
-  - REST auth (`sharedSecret`) for temporary credentials, or
-  - static `username`/`password` (fallback).
@@ -1,9 +0,0 @@
-# Third-party notices
-
-## Telegram Animated Emojis
-
-Animated emoji previews in SHiNE use the public catalog from Tarikul-Islam-Anik.
-
-Source: https://github.com/Tarikul-Islam-Anik/Telegram-Animated-Emojis
-
-The repository README states that the media files are sourced from Emojipedia and that rights to the Telegram media belong to Telegram.org. Review those rights before public distribution.
--- a/Show More
+++ b/Show More