feat(phase1): rebrand to TTRPG Player and drop Git updates feed

Rename product to TTRPG Player (TTRPGPlayer / com.ttrpgplayer.app), use .ttrpg.zip for new saves while keeping .dnd.zip import, accept TTRPG- and DND- license keys on client, and remove sync-update-feed plus CI push to DndGamePlayerUpdates. Co-authored-by: Cursor <cursoragent@cursor.com>
2026-05-17 20:56:14 +08:00
parent 2c03921d23
commit 7c858ba633
27 changed files with 253 additions and 1328 deletions
@@ -1,519 +1,52 @@
-# Автообновление через Gitea (приватный код + публичный feed)
+# Автообновления TTRPG Player

-Исходники остаются в **закрытом** репозитории с игрой. Файлы обновлений (`latest.yml`, установщики) лежат в **отдельном публичном** репозитории — по HTTPS их скачивает `electron-updater`.
+## Текущее состояние (фаза 1)

-## Твой публичный репозиторий (уже есть)
+- Продукт переименован в **TTRPG Player** / **НРИ Плеер** (`productName`: `TTRPGPlayer`, `appId`: `com.ttrpgplayer.app`).
+- CI по тегу `v*` **только собирает** установщики в каталог `release/` (Win NSIS, Linux AppImage x64/arm64). Пуш в Git-репозиторий **`DndGamePlayerUpdates`** **отключён**; скрипт `scripts/sync-update-feed.mjs` удалён.
+- В `package.json` → `build.publish.url` стоит заглушка `https://updates.invalid.ttrpg/` до настройки реального хоста.
+- Секреты **`DND_UPDATE_FEED_URL`**, **`DND_UPDATES_SERVER`**, **`UPDATES_REPO`**, **`DND_UPDATES_PUSH_TOKEN`** в workflow **больше не используются** — их можно удалить из настроек репозитория.
+- Публичный репозиторий **`DndGamePlayerUpdates` на Gitea можно удалить** (история с бинарниками ~4 GiB больше не нужна).

- Клон: `https://git.mailib.ru/ifontosh/DndGamePlayerUpdates.git`
- Владелец/репо для секретов: **`ifontosh/DndGamePlayerUpdates`**
- Базовый URL feed (вшивается в сборку и должен совпадать с secret **`DND_UPDATE_FEED_URL`**):
+Клиент по-прежнему использует **electron-updater** (generic provider). Пока URL заглушка, проверка обновлений в установленной сборке завершится ошибкой сети — это ожидаемо до фазы 2.

-  **`https://git.mailib.ru/ifontosh/DndGamePlayerUpdates/raw/branch/updates/`**
+## Фаза 2 (план): статический VPS

-  Обрати внимание: слово **`branch`** в пути — это часть URL Gitea, не имя ветки. Имя ветки — в конце: **`updates`**.
+Цель: один HTTPS- origin без Git LFS и без роста репозитория.

-В `package.json` уже указан этот же `build.publish.url` (для локального `npm run pack` и метаданных electron-builder).
+1. VPS с **nginx** (или аналог), TLS (Let's Encrypt).
+2. Каталог, например `/var/www/ttrpg-updates/`, с **фиксированными именами** файлов (без версии в имени установщика) или с semver в `latest*.yml` и прямыми URL на те же имена.
+3. CI или ручной шаг: **rsync/scp** артефактов из `release/` на сервер после тега `v*`.
+4. В приватном репозитории кода — секрет **`TTRPG_UPDATE_FEED_URL`** (со слэшем в конце), подстановка в `electron-builder` при сборке релиза.
+5. Mac: ручная выкладка `.dmg` / `latest-mac.yml` на тот же origin (см. `docs/MANUAL_MAC_UPDATE_UPLOAD.md`).

---
+Детали CI для VPS будут добавлены отдельным PR после выбора хоста и схемы имён файлов.

-## Шаг 0 — репозиторий сейчас пустой (важно)
-
-На странице репо написано, что **контента нет**. Пока нет **ни одного коммита**, CI не сможет сделать `git clone`.
-
-Сделай так (любой способ):
-
-1. На сайте открой `ifontosh/DndGamePlayerUpdates` → кнопка вроде **«Инициализировать репозиторий»** / **«Добавить файл»** → создай файл `README.md` с парой строк и закоммить **в ветку по умолчанию** (часто `main`).
-2. Либо с компьютера:
+## Локальная сборка релиза

 ```bash
-git clone https://git.mailib.ru/ifontosh/DndGamePlayerUpdates.git
-cd DndGamePlayerUpdates
-echo "# DndGamePlayer updates feed" > README.md
-git add README.md
-git commit -m "init"
-git push origin main
+npm run pack          # Win (на Windows) или см. CI
+npm run pack:linux    # Linux AppImage
+npm run pack:mac      # macOS (на Mac)
+npm run release:info  # версия и пример тега vX.Y.Z
 ```

-(Если ветка по умолчанию у тебя `master` — подставь её вместо `main`.)
+Артефакты: `TTRPGPlayer-Setup-<version>.exe`, `TTRPGPlayer-<version>-<arch>.AppImage`, и т.д. (см. `package.json` → `build`).

-После этого репозиторий **не пустой** — workflow сможет клонировать и создать ветку **`updates`**.
+## Gitea Actions (act_runner)

---
+- Workflow: `.gitea/workflows/release.yml`
+- Триггер: push тега `v*`
+- Runner label: `ubuntu-22.04` (как в настройках раннера)

-## Шаг 1 — токен для записи в публичный репозиторий
+Если job падает на Wine/NSIS — см. комментарии в workflow (сборка Win на Linux без i386).

-Нужен **персональный токен** (PAT), с которым CI сможет **пушить** в `DndGamePlayerUpdates`.
+## Лицензия и обновления

-В Gitea на русском обычно так (названия могут чуть отличаться в твоей теме):
+Проверка обновлений доступна только при **активной лицензии** (как и раньше). Продуктовые ключи на клиенте: **`TTRPG-…`** и устаревшие **`DND-…`**; новые ключи выдаёт сервер лицензий (отдельный репозиторий `DndGamePlayerLicenseServer` — смена префикса на сервере вне этого PR).

-1. Вверху справа **аватар** → **Настройки** (или «Параметры»).
-2. Слева найди раздел вроде **«Приложения»** / **«Токены доступа»** / **«Токены»** (в англ. интерфейсе: **Settings → Applications → Generate New Token**).
-3. Создай новый токен:
-   - имя: например `dnd-release-ci`;
-   - права: достаточно доступа к репозиторию с **записью** (для пуша в `DndGamePlayerUpdates`). Если есть галочки — включи что-то вроде **«Запись в репозиторий»** / **write:repository** / полный доступ к репо.
-4. **Скопируй токен один раз** и сохрани в менеджере паролей — потом Gitea его не покажет.
+## Устаревшая схема (не использовать)

-Этот токен пойдёт в secret **`DND_UPDATES_PUSH_TOKEN`** (см. ниже). **Не вставляй токен в код и не коммить его.**
-
-> На **git.mailib.ru** имена секретов **не могут начинаться с `GITEA_`** (зарезервировано). Поэтому в workflow используются `DND_UPDATES_*`, а не `GITEA_*`.
-
---
-
-## Шаг 2 — секреты в приватном репозитории с кодом (`dnd_player`)
-
-Открой **приватный** репозиторий, где лежит исходник игры (не `DndGamePlayerUpdates`).
-
-Дальше (русский Gitea 1.26, ориентир по меню):
-
-1. Вкладка **«Настройки»** репозитория (вверху рядом с «Код», «Задачи» — иногда шестерёнка **«Настройки»**).
-2. Слева раздел **«Секреты»** / **«Действия»** → **«Секреты»** (в англ. UI: **Settings → Actions → Secrets**). Если видишь **«Переменные»** — секреты обычно рядом; нам нужны именно **секреты** (скрытые значения).
-
-Добавь **четыре** секрета (имя **точно** как в таблице — workflow их читает):
-
-| Имя секрета              | Что вписать в значение                                                                                   |
-| ------------------------ | -------------------------------------------------------------------------------------------------------- |
-| `DND_UPDATE_FEED_URL`    | `https://git.mailib.ru/ifontosh/DndGamePlayerUpdates/raw/branch/updates/` (обязательно **слэш в конце**) |
-| `DND_UPDATES_SERVER`     | `https://git.mailib.ru` (**без** слэша в конце)                                                          |
-| `UPDATES_REPO`           | `ifontosh/DndGamePlayerUpdates`                                                                          |
-| `DND_UPDATES_PUSH_TOKEN` | токен из шага 1 (одна длинная строка)                                                                    |
-
-Сохрани каждый секрет кнопкой вроде **«Сохранить»** / **«Добавить»**.
-
-Если раньше создавал секреты `GITEA_SERVER` / `GITEA_TOKEN` — их workflow **не читает**; удали или оставь, но **обязательно** заведи новые имена из таблицы.
-
---
-
-## Раннер act_runner — без этого «Всего: 0» и сборки не будет
-
-Gitea **не запускает** workflow на своём процессе: нужна **отдельная машина** (VPS, сервер или **WSL2 Ubuntu** на твоём ПК), на которой крутится **[act_runner](https://docs.gitea.com/usage/actions/act-runner)** и которая видит `git.mailib.ru` по сети.
-
-Пока в **«Настройки» → «Действия» → «Раннеры»** написано **«Всего: 0»**, workflow **висит в ожидании** — нечему выполнять шаги.
-
-### Важно: это не тот токен, что для пуша в `DndGamePlayerUpdates`
-
-| Токен                                               | Где взять                                                                  | Зачем                                                                         |
-| --------------------------------------------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
-| **Регистрация раннера** (короткая случайная строка) | **Настройки репо** → **Действия** → **Раннеры** → **Создать новый раннер** | Только для команды **`act_runner register`** (один раз на каталог с раннером) |
-| **`DND_UPDATES_PUSH_TOKEN`** (PAT)                  | **Аватар** → **Настройки пользователя** → токены доступа                   | Для CI: пуш в публичный репо обновлений (см. шаг 1 выше)                      |
-
-Если Gitea показала **только длинную строку** — это почти наверняка **токен регистрации раннера**. URL инстанса ты знаешь сам: **`https://git.mailib.ru`** (без пути к репозиторию).
-
-### Требования к машине под наш `release.yml`
-
-В workflow для job **`ubuntu-22.04`** идут **`sudo apt-get`** (пакеты **`nsis`**, **`wine64`**) на **Linux**. Multiarch **i386** намеренно не включается — на Debian с репозиториями только под amd64 (nginx, sury и т.п.) установка **wine32** часто падает с «unmet dependencies». После установки **`wine64`** в CI создаётся скрипт **`/usr/local/bin/wine`** с **`exec` по полному пути** к **`wine64`** (в job у act_runner иногда пустой/урезанный `PATH`, тогда имя `wine64` без пути не находится). electron-builder проверяет именно команду **`wine`** в `PATH`. Поэтому:
-
- Нужен **Linux x86_64** (идеально **Ubuntu 22.04**), либо **WSL2** с Ubuntu 22.04 на Windows.
- Запускать раннер на «голом» Windows с меткой `ubuntu-22.04` **бессмысленно** — шаги с `apt` не выполнятся.
-
-### Шаг A — получить токен регистрации в Gitea
-
-1. Открой репозиторий с кодом (**DndGamePlayer** или как он у тебя называется).
-2. **Настройки** → **Действия** → **Раннеры** → **Создать новый раннер**.
-3. Выбери тип **репозитория** (repository runner), ОС **Linux**.
-4. **Скопируй токен** (и при желании подсказку с URL инстанса, если она есть). Команду из мастера можно **не копировать**, если ниже удобнее готовая.
-
-### Шаг B — скачать act_runner (бинарник)
-
-Официальные сборки: **[релизы act_runner на gitea.com](https://gitea.com/gitea/act_runner/releases)**.
-
-1. Открой страницу релизов и посмотри **последний стабильный** тег, например **`v1.0.2`**.
-2. В списке файлов скачай **`gitea-runner-ВЕРСИЯ-linux-amd64`** — это один исполняемый файл **без** расширения `.zip` (не путай с `darwin` / `arm64`, если у тебя обычный ПК/сервер Intel/AMD).
-
-**Прямая ссылка (подставь свою версию из релиза):**
-
-`https://gitea.com/gitea/act_runner/releases/download/v1.0.2/gitea-runner-1.0.2-linux-amd64`
-
-В URL после `download/` идёт тег с **`v`**, в имени файла версия **без `v`**.
-
-**Скачать с Linux/WSL одной командой** (замени `1.0.2` на актуальную версию с сайта):
-
-```bash
-mkdir -p ~/gitea-act-runner && cd ~/gitea-act-runner
-VERSION="1.0.2"
-curl -fL -o act_runner "https://gitea.com/gitea/act_runner/releases/download/v${VERSION}/gitea-runner-${VERSION}-linux-amd64"
-chmod +x act_runner
-./act_runner --version
-```
-
-Если `curl` ругается на сертификат — обнови CA или скачай тот же файл через браузер и положи в папку, затем `chmod +x`.
-
-### Шаг C — регистрация (подставь свой токен)
-
-В каталоге, где лежит `act_runner`, выполни **одну** команду (токен — тот, что выдала Gitea при создании раннера):
-
-```bash
-cd ~/gitea-act-runner
-
-./act_runner register --no-interactive \
-  --instance "https://git.mailib.ru" \
-  --token "ВСТАВЬ_СЮДА_ТОКЕН_ИЗ_МАСТЕРА_GITEA" \
-  --name "dnd-release-runner" \
-  --labels "ubuntu-22.04:host"
-```
-
-Пояснения:
-
- **`--instance`** — корень твоего Gitea (**без** `/ifontosh/...`).
- **`--labels "ubuntu-22.04:host"`** — job в **`.gitea/workflows/release.yml`** имеет `runs-on: ubuntu-22.04`, а **`:host`** означает выполнение **на самой машине**, с настоящим `apt` и Wine (см. [документацию по меткам](https://docs.gitea.com/usage/actions/act-runner#labels)). Если при регистрации оставить **дефолтные** метки с **`docker://`**, шаги тоже могут сработать, но образ другой; для предсказуемости лучше **`ubuntu-22.04:host`** на чистой Ubuntu 22.04.
- После успешной регистрации в этой папке появится файл **`.runner`** — его не удаляй и не коммить.
-
-Если Gitea пишет ошибку регистрации — часто неверный **токен** (устарел после «сброса» в UI) или выбран не тот уровень (инстанс/организация/репозиторий). Создай раннера заново и возьми **новый** токен.
-
-### Шаг D — запуск вручную (для проверки)
-
-В той же папке:
-
-```bash
-./act_runner daemon
-```
-
-Окно терминала должно остаться **открытым**. Остановка — `Ctrl+C`. Когда убедишься, что в Gitea раннер **online**, лучше перейти на **systemd** (шаг ниже).
-
-### Шаг D1 — systemd: автозапуск после перезагрузки (подробно)
-
-Идея: **systemd** сам поднимает `act_runner daemon` при загрузке системы и перезапускает процесс при падении. Рабочая директория должна быть **та же**, где лежат **`act_runner`** и зарегистрированный файл **`.runner`** (обычно `~/gitea-act-runner`).
-
-#### 0) Подготовка
-
-1. Регистрация (**шаг C**) уже выполнена, в каталоге есть **`.runner`**.
-2. Узнай **точный путь** к каталогу (systemd не понимает `~`):
-
-```bash
-cd ~/gitea-act-runner && pwd
-```
-
-Запомни вывод, например **`/home/ivan/gitea-act-runner`**. Имя пользователя Linux:
-
-```bash
-whoami
-```
-
-Дальше в примерах: **`/home/ivan/gitea-act-runner`** и пользователь **`ivan`** — замени на свои.
-
-#### 1) Останови ручной запуск
-
-Если где-то в терминале уже крутится `./act_runner daemon` — заверши **Ctrl+C**, иначе два процесса будут мешать друг другу.
-
-#### 2) Создай unit-файл службы
-
-На **VPS / обычной Ubuntu** с правами root:
-
-```bash
-sudo nano /etc/systemd/system/gitea-act-runner.service
-```
-
-Вставь текст **целиком** (подставь свои `User`, `Group`, `WorkingDirectory`, `ExecStart`):
-
-```ini
-[Unit]
-Description=Gitea Actions act_runner
-Documentation=https://docs.gitea.com/usage/actions/act-runner
-After=network-online.target
-Wants=network-online.target
-
-[Service]
-Type=simple
-User=ivan
-Group=ivan
-WorkingDirectory=/home/ivan/gitea-act-runner
-ExecStart=/home/ivan/gitea-act-runner/act_runner daemon
-Restart=always
-RestartSec=10
-
-# Логи в journald (см. ниже как читать)
-StandardOutput=journal
-StandardError=journal
-
-[Install]
-WantedBy=multi-user.target
-```
-
-Сохрани файл: в **nano** — **Ctrl+O**, Enter, **Ctrl+X**.
-
-Пояснения:
-
- **`User` / `Group`** — под этим пользователем ты делал `register` и владеешь папкой (проверка: `ls -la ~/gitea-act-runner` — владелец должен совпадать).
- **`WorkingDirectory`** — каталог с **`.runner`**; без него раннер может не найти регистрацию.
- **`ExecStart`** — полный путь к бинарнику **`act_runner`** (тот, что скачал и сделал `chmod +x`).
- Блок **`After=network-online.target`** — старт после сети (удобно для `git`/`npm` в CI). Если вдруг зависнет старт из‑за сетевого таргета, можно временно заменить на **`After=network.target`**.
-
-Официальный пример с отдельным пользователем `act_runner` и `config.yaml`: [Start the runner with Systemd](https://docs.gitea.com/usage/actions/act-runner#start-the-runner-with-systemd) — у нас проще: один пользователь и без отдельного `config.yaml`, пока дефолты устраивают.
-
-#### 3) Включи и запусти службу
-
-```bash
-sudo systemctl daemon-reload
-sudo systemctl enable gitea-act-runner.service
-sudo systemctl start gitea-act-runner.service
-sudo systemctl status gitea-act-runner.service
-```
-
-В **`status`** должно быть **`active (running)`** зелёным. Если **`failed`** — смотри лог (шаг 5).
-
-Полезные команды:
-
-| Действие              | Команда                                                       |
-| --------------------- | ------------------------------------------------------------- |
-| Остановить            | `sudo systemctl stop gitea-act-runner`                        |
-| Запустить снова       | `sudo systemctl start gitea-act-runner`                       |
-| Перезапуск            | `sudo systemctl restart gitea-act-runner`                     |
-| Выключить автозапуск  | `sudo systemctl disable gitea-act-runner`                     |
-| Проверка после ребута | перезагрузи машину, затем `systemctl status gitea-act-runner` |
-
-#### 4) Проверка в Gitea
-
-Как в **шаге E**: раннер снова **online** (иногда 10–30 секунд после `start`).
-
-#### 5) Логи, если что-то не так
-
-```bash
-sudo journalctl -u gitea-act-runner -e --no-pager
-```
-
-В реальном времени:
-
-```bash
-sudo journalctl -u gitea-act-runner -f
-```
-
-Типичные ошибки: неверный **`User`** (нет прав на каталог), **`WorkingDirectory`** не тот (нет **`.runner`**), бинарник не исполняемый (`chmod +x`), или старый процесс `act_runner` ещё запущен вручную.
-
-#### WSL2 (Ubuntu в Windows)
-
-Если раннер стоит **внутри WSL2**:
-
-1. На современных WSL **systemd уже может быть включён**. Проверка: `systemctl status` — без ошибки «running in chroot».
-2. Если `systemctl` недоступен: в файле **`/etc/wsl.conf`** внутри дистрибутива добавь блок **`[boot]`** с **`systemd=true`**, затем из **PowerShell** Windows выполни **`wsl --shutdown`**, снова зайди в Ubuntu и повтори шаги 2–3. Подробнее: [документация Microsoft про systemd в WSL](https://learn.microsoft.com/en-us/windows/wsl/systemd).
-
-После **`wsl --shutdown`** раннер на WSL не работает, пока ты снова не откроешь WSL (это нормально для «домашнего» CI).
-
-### Шаг E — проверка в веб-интерфейсе
-
-Обнови **Настройки → Действия → Раннеры**: должен быть **1** раннер, статус **online**. У него в метках должно быть что-то вроде **`ubuntu-22.04`** (в связке с **host**).
-
-### Если у тебя только Windows
-
-Установи **WSL2** и дистрибутив **Ubuntu 22.04**, открой терминал Ubuntu и выполни шаги B–D **там** (это уже Linux). Файловую систему Windows из WSL видно как `/mnt/d/...`, но проще держать каталог раннера в домашнем каталоге Linux (`~/gitea-act-runner`).
-
-Официальная документация: [Gitea — Act Runner](https://docs.gitea.com/usage/actions/act-runner).
-
-Если раннер заводит **админ инстанса** — логика та же: раннер должен быть **online** и иметь метку, подходящую под **`runs-on`** в `release.yml` (сейчас **`ubuntu-22.04`**; при **`ubuntu-22.04:host`** в Gitea это сопоставляется с `runs-on: ubuntu-22.04`).
-
---
-
-## Шаг 3 — включить Actions (если ещё не включены)
-
-1. В том же **приватном** репозитории: **«Настройки»**.
-2. Раздел **«Действия»** / **«Actions»** — включи использование Actions для этого репозитория, если Gitea это спрашивает.
-3. Убедись, что в корне репозитория есть файл **`.gitea/workflows/release.yml`** (он уже в проекте `dnd_player`).
-
-Бегунки Gitea должны иметь доступ в интернет (для `npm ci`, `actions/checkout` и т.д.) — это настраивает админ сервера.
-
-### Метки `runs-on` (если раннер уже есть, но job не берётся)
-
- В списке раннеров посмотри **метки** у online-раннера.
- В **`.gitea/workflows/release.yml`** в `runs-on:` должна совпадать **именно метка `ubuntu-22.04`** (Gitea сопоставляет её и с **`ubuntu-22.04:host`**, и с **`ubuntu-22.04:docker://...`** — см. [Labels](https://docs.gitea.com/usage/actions/act-runner#labels) в документации act_runner).
- Если при регистрации указал только **`self-hosted`** — добавь **`ubuntu-22.04:host`** (или поменяй `runs-on` в workflow на твои метки и закоммить).
-
-Сборка **Windows (NSIS)** и **Linux (AppImage x64 + arm64)** в CI идёт **на одном** `ubuntu-22.04`: NSIS + `wine64` для Win, `qemu-user-static` для кросс-сборки arm64 AppImage на amd64 (см. `release.yml`). **macOS** в этом job не собирается (ручная выкладка или отдельный раннер — см. `docs/MANUAL_MAC_UPDATE_UPLOAD.md`).
-
---
-
-## Linux: AppImage и автообновление
-
- В ветке **`updates`** рядом с Windows лежат **`latest-linux.yml`** и файлы **`*.AppImage`** (x64 и arm64). Скрипт **`scripts/sync-update-feed.mjs`** делает **merge-копирование**: файлы других ОС в репозитории **не удаляются**, обновляются только имена, пришедшие из текущего CI-прогона.
- **Базовый дистрибутив для бинарников:** сборка на **Ubuntu 22.04 (glibc 2.35)** — совместимость с «максимумом» настольных дистрибутивов с glibc не старее целевого; **Alpine/musl** без отдельной сборки не гарантируется.
- **Запуск AppImage:** на части систем нужен **FUSE** (например `libfuse2` для старых форматов / документация дистрибутива). Подпись пакетов в первом варианте **не** используется (как договорённость по проекту).
- Правила **electron-updater** в приложении те же: упакованная сборка и **активная лицензия** (`installAutoUpdater.ts`).
- **Дифференциальное обновление** (запросы с несколькими HTTP `Range` по blockmap) на **Gitea raw** за nginx часто даёт **`400 Bad Request`** (`content-length: 18` — короткий текст ошибки); updater переходит на **полную** загрузку — обновление всё равно доходит. В коде по умолчанию **`disableDifferentialDownload: true`**, чтобы не делать лишний шаг (меньше шума в логе). Включить дифф снова: переменная **`DND_UPDATE_ENABLE_DIFFERENTIAL=1`** при запуске приложения — имеет смысл только если на сервере разрешили корректные Range / multi-range для raw.
- Сообщения вида **`duplicated in blockmap`** в консоли — предупреждение electron-updater, на работоспособность обычно не влияют.
-
---
-
-## Шаг 4 — выпуск версии
-
-1. В `package.json` версия должна совпасть с тегом (workflow при пуше тега делает `npm version` из имени тега — удобно).
-2. Закоммить все изменения в **приватный** репо, затем:
-
-```bash
-git tag v1.0.1
-git push origin main
-git push origin v1.0.1
-```
-
-(ветка может быть не `main` — подставь свою.)
-
-3. Открой в Gitea **«Действия»** у приватного репо — должен появиться запуск **Release**. Дождись успеха job **`release`** (после появления раннера, см. раздел выше).
-
-4. После успеха открой **публичный** `DndGamePlayerUpdates` → ветка **`updates`** — в корне должны появиться `latest.yml`, установщики и т.д.
-
---
-
-## Контрольный чеклист
-
-1. **`package.json` → `build.publish.url`** =  
-   `https://git.mailib.ru/ifontosh/DndGamePlayerUpdates/raw/branch/updates/`  
-   Совпадает с **`DND_UPDATE_FEED_URL`** (со слэшем в конце).
-2. В **DndGamePlayerUpdates** есть хотя бы один коммит (не пустой репо).
-3. В приватном репо заданы **все четыре** секрета из таблицы шага 2 (имена **не** начинаются с `GITEA_`).
-4. В репо с кодом есть **`.gitea/workflows/release.yml`**.
-5. Релиз: пуш тега `v*` → в Actions job **`release`**: сборка **Windows** + **Linux AppImage** и push feed; в публичном репо ветка **`updates`** содержит `latest.yml`, `latest-linux.yml`, установщики Windows и **`.AppImage`** для Linux (нужен online-раннер `ubuntu-22.04`, см. раздел про act_runner). Скрипт sync **не затирает** артефакты других платформ при обновлении.
-6. В приложении: обновления только **`app.isPackaged`** и при **активной лицензии** (см. `app/main/update/installAutoUpdater.ts`).
-
---
-
-## Если `git push` в `updates` падает: `remote end hung up` / таймаут
-
-Один коммит с **Windows + два AppImage** может быть **сотни МБ** — HTTPS-push иногда рвётся из‑за лимита буфера Git или таймаута **nginx / reverse proxy** перед Gitea. Отдельно встречается **`HTTP 500`** от Gitea/прокси на большом pack (например один `*-win.zip` ~200 MiB) — это уже **ошибка сервера** при приёме тела запроса; повторы push иногда помогают, но при стабильном 500 нужно править лимиты/таймауты на стороне Gitea и reverse proxy.
-
-**В репозитории с кодом** скрипт `scripts/sync-update-feed.mjs` уже выставляет в клоне feed-репо:
-
- `http.postBuffer` **2 GiB**;
- отключение «медленной передачи» (`http.lowSpeedLimit` / `http.lowSpeedTime`);
- повторы **`git push`**: переменная **`DND_GIT_PUSH_RETRIES`** (по умолчанию **5**, максимум **10**), пауза **`DND_GIT_PUSH_RETRY_SLEEP_SEC`** (по умолчанию **30** с, максимум **120**). В workflow для шага sync задано **`DND_GIT_PUSH_RETRIES=8`** и **`DND_GIT_PUSH_RETRY_SLEEP_SEC=35`**.
-
-Если ошибка сохраняется — на **сервере** (nginx и т.п.) проверьте, например:
-
- `client_max_body_size` — не меньше размера push (или `0` для безлимита, если политика безопасности позволяет);
- `proxy_read_timeout` / `proxy_send_timeout` — **несколько минут** и больше для больших загрузок;
- лимиты самого **Gitea** (`[repository.upload]`, `APP_MAX_FILE_SIZE` в зависимости от версии) — в документации вашей сборки Gitea.
-
---
-
-## Линейная история в `UPDATES_REPO` (например DndGamePlayerUpdates)
-
-Переписывается **только** публичный репозиторий из секрета **`UPDATES_REPO`**, ветка **`updates`**. Репозиторий с исходниками игры (**DndGamePlayer**) и его теги **не меняются**.
-
-В workflow задано **`DND_UPDATES_SQUASH_HISTORY=1`**: после merge и подкладки артефактов скрипт делает **`git checkout --orphan`** и собирает историю **только текущего релиза**. Чтобы не отправлять один огромный pack (~700+ MiB) и не ловить `curl 55 Broken pipe`, загрузка идёт через **временную** ветку **`updates-upload-*`**: сначала small files, затем каждый большой файл отдельным push (порог **`DND_FEED_LARGE_FILE_BYTES`**, по умолчанию 64 MiB). Эта ветка **не заменяет** публичный feed: URL для клиентов по-прежнему **`…/raw/branch/updates/`**. `updates-upload-*` — только черновик на время job; в конце ветка **`updates`** передвигается на готовый коммит (`--force-with-lease` или первый push), временная ветка **удаляется** с remote.
-
-На **сервере Gitea** старые объекты коммитов остаются «висячими», пока не отработает **сборка мусора** репозитория (настройки сервера / ручной `git gc` в bare-репо). Для пользователей приложения важны только URL **`latest*.yml`** и установщиков — они не меняются по смыслу.
-
-Не запускайте **два релиза**, которые одновременно пушат feed, — возможна гонка и отказ **`--force-with-lease`**.
-
-Перед подкладкой артефактов скрипт **удаляет** из корня ветки файлы вида **`DNDGamePlayer-<чужая версия>-*`** / **`DNDGamePlayer-Setup-<чужая версия>.exe`** (и связанные `.blockmap`), чтобы после `merge` не копились старые установщики (1.0.6 рядом с 1.0.14). Версия текущего релиза берётся из **`GIT_COMMIT_TAG`** (`v1.0.14` → `1.0.14`). Файлы **`latest*.yml`** перезаписываются копированием. Если в **`ARTIFACT_MAC`** нет ни одного файла сборки, **`.dmg` / `.pkg`** не удаляются — сохраняется вручную залитый mac в feed. Отключить очистку: **`DND_FEED_PRUNE_OLD_VERSIONS=0`**.
-
---
-
-## Размер репозитория `DndGamePlayerUpdates` (почему ~4 GiB и как держать меньше)
-
-### Почему место не возвращается само
-
-При **`DND_UPDATES_SQUASH_HISTORY=1`** и **`git push --force-with-lease`** на ветке **`updates`** в истории остаётся по сути **один актуальный коммит**, но на **диске сервера** Git до **сборки мусора** продолжает хранить **недостижимые** объекты: старые коммиты, прерванные push, временные ветки **`updates-upload-*`**, старые pack-файлы. Пока не выполнен **`git gc --prune`**, размер каталога **`.git`** на Gitea может быть **сильно больше**, чем «один релиз файлов» в веб-интерфейсе.
-
-### Сразу освободить место (один раз на сервере)
-
-На машине Gitea найдите **bare**-репозиторий (типичный путь: `…/gitea-repositories/<владелец>/dndgameplayerupdates.git`), от имени пользователя с правами на каталог:
-
-```bash
-cd /path/to/DndGamePlayerUpdates.git
-git gc --prune=now
-```
-
-При очень большом накоплении мусора иногда используют **`--aggressive`** (дольше и тяжелее для CPU); чаще достаточно команды **без** него. После GC размер на диске должен приблизиться к сумме **текущих** файлов в последнем коммите.
-
-В веб-интерфейсе Gitea смотрите раздел **администрирования** / **обслуживание** / **garbage collection** (названия зависят от версии): там может быть глобальный GC по всем репозиториям.
-
-### Чтобы после каждого релиза снова не раздувалось
-
-В **`app.ini`** Gitea включите **периодический GC репозиториев** (секция и ключи зависят от версии; ориентир — задача **`git_gc_repos`** в документации [config cheat sheet](https://docs.gitea.com/administration/config-cheat-sheet)), например раз в **24 ч** или чаще, если релизы частые.
-
-Уже включено в вашем пайплайне по смыслу: **squash** + **prune** старых имён установщиков — это уменьшает **набор файлов** в новом коммите; **физическое** освобождение на диске — задача **GC на сервере**.
-
-### Можно ли «всегда не больше 1,5 GiB»
-
-**Жёстко задать потолок Git не умеет.** Реальный минимум на диске ≈ размер **текущих** артефактов в ветке (два AppImage + NSIS + zip + blockmap + mac и т.д.) плюс служебные pack’и. Если один релиз по сумме бинарников уже **> 1,5 GiB**, репозиторий физически не уместится в лимит без **урезания артефактов** (например не выкладывать **`win.zip`**, если он не нужен updater’у) или без **выноса больших файлов из Git**.
-
-Надёжный способ держать репо **маленьким постоянно**: в **`DndGamePlayerUpdates`** хранить только **`latest*.yml`** (и при необходимости подписи), а **`.exe` / `.AppImage` / `.zip`** выкладывать в **Gitea Releases**, **объектное хранилище** или **статический хост**, а в yml подставлять **прямые URL** туда. Тогда потребуется доработка **CI** и, при смене хоста, **`build.publish.url`** / секреты — это отдельная схема доставки, не только `git gc`.
-
---
-
-## Если push отклонён: `(fetch first)` / `rejected`
-
-Пока job собирает артефакты, в **`updates`** мог успеть попасть **другой** коммит (второй релиз, ручная выкладка). Скрипт `sync-update-feed.mjs` перед push (в режиме **без** squash) делает **`git fetch` + `git merge origin/updates`** (и после клона — то же в начале), плюс shallow **глубина** (`DND_UPDATES_CLONE_DEPTH`: по умолчанию **40**, при **`DND_UPDATES_SQUASH_HISTORY=1`** в скрипте по умолчанию **8**). В режиме **squash** перед финальным push merge **не** выполняется — уже смерженное дерево отправляется через временную ветку и затем публикуется force-with-lease. Не запускайте **два релиза одного и того же репо одновременно** по двум тегам — возможны конфликты merge.
-
---
-
-## ENOSPC / «no space left on device» при sync
-
-Частая причина: **дублирование** артефактов (`release/` → `_linux`/`_win` → временный клон в **`/tmp`**) на раннере с маленьким root. Сейчас CI **не копирует** в `_win`/`_linux`: `ARTIFACT_WIN` и `ARTIFACT_LINUX` указывают на **`release/`**, а временный клон feed создаётся под **`DND_FEED_TMP_ROOT`** (в workflow — `${{ github.workspace }}/.dnd-feed-tmp`). Скрипт по возможности делает **`rename`** файлов в клон (без второй полной копии на том же диске).
-
-Если ошибка остаётся — на машине раннера нужно **освободить место** или увеличить диск / вынести workspace на больший том.
-
-Перед `git clone` скрипт проверяет **свободное место на томе**, где лежит `DND_FEED_TMP_ROOT` (оценка: артефакты × 2.5 + ~1 GiB запас, минимум ~2 GiB). Если проверка мешает (редкий ложный срабатывание), можно задать **`DND_FEED_SKIP_DISK_CHECK=1`** (лучше всё же поправить диск).
-
-Несколько **неудачных** `git fetch` подряд (обрыв TLS) могли раньше забивать диск частично распакованными pack-файлами; между попытками вызывается **`git gc --prune=now`**.
-
---
-
-## Сбой fetch: `GnuTLS recv error` / `early EOF`
-
-Сеть или TLS к серверу Gitea. Скрипт делает **несколько повторов** `git fetch` (`DND_GIT_FETCH_RETRIES`, по умолчанию **6**), между попытками — **`git gc --prune=now`**, для clone/fetch задано **`http.version=HTTP/1.1`** (иногда стабильнее за прокси). Если ветки **`updates` на сервере ещё нет**, merge **намеренно** пропускается (первый push feed); при **любой другой** ошибке fetch job **завершится ошибкой** — не будет «тихого» продолжения с последующим `ENOSPC` на `git add`.
-
-При стабильных обрывах проверьте прокси/MTU/антивирус на раннере и лимиты прокси к Gitea.
-
---
-
-## Поведение приложения
-
- Проверка только в **собранной** установке (`app.isPackaged`).
- Только если **лицензия активна**.
- Первый запрос примерно через **12 с** после старта; при смене лицензии — снова (не чаще **30 с**).
- Для отладки можно задать переменную окружения **`DND_UPDATE_FEED_URL`** при запуске приложения (Windows / Linux / macOS) — переопределит feed.
-
-Подпись кода в CI отключена: `CSC_IDENTITY_AUTO_DISCOVERY=false` (в т.ч. Linux AppImage без репозитория подписи).
-
---
-
-## Локальная отладка feed
-
-Запуск установленного приложения с другим URL (без пересборки): задать **`DND_UPDATE_FEED_URL`** в ярлыке или системных переменных окружения.
-
---
-
-## Как сделать так, чтобы ассистент в Cursor мог «выпустить релиз»
-
-У ассистента **нет своего аккаунта** на `git.mailib.ru`. Релиз = **появление тега `v*`** на нужном коммите в **приватном** репозитории с кодом → Gitea Actions собирает и пушит feed. Ниже два рабочих варианта.
-
-### Вариант A — Gitea MCP (удобно из чата)
-
-У тебя уже подключён MCP **user-gitea-mailib** с инструментом **`create_tag`**: по API создаётся тег на сервере (аналог `git tag` + `git push` тега).
-
-**Что сделать один раз:**
-
-1. В Cursor MCP для Gitea должен быть **включён и залогинен** под учёткой, у которой есть право **создавать теги** в приватном репо с `dnd_player`.
-2. Знать **`owner`** и **`repo`** этого репозитория (как в URL: `https://git.mailib.ru/OWNER/REPO`).
-
-**Как просить в чате:**  
-«Создай тег `v1.0.2` в репозитории `OWNER/REPO` с целевой веткой `main`» (или укажи SHA коммита). Перед этим **весь код релиза уже должен быть запушен** в эту ветку — тег вешается на последний коммит (или на явный `target`).
-
-После создания тега зайди в **Действия** репозитория и проверь workflow **Release**.
-
-_(Отдельно: `create_release` в MCP создаёт **запись релиза** на Gitea; сборку у тебя запускает именно **тег** и `release.yml`.)_
-
-### Вариант B — команды `git` в терминале Cursor
-
-Ассистент может выполнить у тебя локально:
-
-```bash
-git fetch origin
-git tag v1.0.2 origin/main   # или другая ветка / коммит
-git push origin v1.0.2
-```
-
-**Что сделать один раз:**
-
-1. Чтобы `git push` **не спрашивал пароль** каждый раз: настроить **учётные данные** (Windows: диспетчер учётных данных / `git credential-manager`; либо **SSH-ключ** и remote `git@git.mailib.ru:...`).
-2. Убедиться, что из того же окружения, где работает Cursor, `git push` в приватный репо уже проходил успешно.
-
-Тогда в чате можно написать: «Поставь тег `v1.0.2` на `origin/main` и запушь тег» — ассистент выполнит команды в `dnd_player`.
-
-### Ограничения
-
- Ассистент **не видит** твои пароли и не обходит Gitea: всё упирается в **MCP-токен** или **твои локальные git credentials**.
- Если MCP отключён и git без настроенного доступа — релиз тегом придётся пушить **тебе** вручную (как в шаге 4 выше).
-
---
-
-## Про коммит и пуш кода (не тег)
-
-Закоммитить и запушить **изменения в файлах** ассистент может через те же механизмы: либо ты делаешь `git push` после правок, либо настроенный **git** / отдельный скрипт. Без доступа к remote ассистент только правит файлы в рабочей копии.
+Раньше артефакты пушились в публичный Git **`DndGamePlayerUpdates`**, ветка `updates`, URL вида  
+`https://git.mailib.ru/.../DndGamePlayerUpdates/raw/branch/updates/`.  
+Эта схема приводила к раздуванию репозитория, конфликтам merge, ENOSPC на раннере и HTTP 500 при `git push`. Она **снята с поддержки**.
@@ -1,159 +1,38 @@
-# Ручная выкладка macOS-обновлений в публичный feed
+# Ручная выкладка macOS-обновлений (TTRPG Player)

-Инструкция для случая, когда **сборка делается на вашем Mac вручную**, а файлы для `electron-updater` нужно **вручную** положить в публичный репозиторий обновлений.
+До настройки VPS (фаза 2) mac-сборка выполняется **локально на Mac**. Артефакты нужно будет положить на тот же HTTPS-origin, что и Win/Linux (`build.publish.url`).

-Общая схема проекта: приватный репозиторий с кодом, публичный **`DndGamePlayerUpdates`**, ветка **`updates`**, URL feed как в `package.json`:
-
-`https://git.mailib.ru/ifontosh/DndGamePlayerUpdates/raw/branch/updates/`
-
---
-
-## 1. Что собрать на Mac
-
-В каталоге проекта `dnd_player`:
+## Сборка на Mac

 ```bash
-cd /путь/к/dnd_player
 npm ci
 npm run build
+npm run pack:mac
 ```

-Сборка установщиков только под macOS (без публикации в сеть, только файлы в `release/`):
+В `release/` появятся, например:
+
+- `TTRPGPlayer-<version>-x64.dmg` (и arm64 при универсальной сборке)
+- `latest-mac.yml` (если включена публикация generic при сборке)
+
+Для локальной проверки updater можно временно указать URL:

 ```bash
 npx electron-builder --mac --publish never \
  --config.publish.provider=generic \
-  --config.publish.url="https://git.mailib.ru/ifontosh/DndGamePlayerUpdates/raw/branch/updates/"
+  --config.publish.url="https://YOUR-UPDATE-HOST/"
 ```

-**Важно:** значение `--config.publish.url=...` должно совпадать с `package.json` → `build.publish.url` (**со слэшем в конце**). Так внутри приложения и в `latest-mac.yml` будет корректный базовый URL для скачивания.
+(подставьте реальный origin со слэшем в конце)

-После сборки откройте папку **`release/`** в корне проекта. Там должны быть, среди прочего:
+## Фаза 2: выкладка на статический хост

- **`latest-mac.yml`** — обязателен для `electron-updater` на Mac;
- **`.dmg`** и/или **`.zip`** — то, на что ссылается `latest-mac.yml`;
- при необходимости **`.blockmap`** (если electron-builder их создал) — заливайте с теми же именами, что указаны в `latest-mac.yml`.
+1. Скопировать на сервер обновлений:
+   - `latest-mac.yml`
+   - `.dmg` / `.zip` с именами, на которые ссылается yml
+2. Проверить в браузере: `https://YOUR-UPDATE-HOST/latest-mac.yml`
+3. В установленном приложении: **Настройки → Проверить обновления** (нужна активная лицензия).

-Имена файлов зависят от версии и архитектур (в конфиге dmg и zip для **x64** и **arm64**). На Apple Silicon без дополнительных шагов часто получается только **arm64**; для отдельного Intel-сборщика нужна своя машина или параметры arch — ориентируйтесь на фактический список файлов в `release/`.
+## Устаревшая схема (Git feed)

---
-
-## 2. Куда заливать
-
-Файлы должны оказаться в **публичном** репозитории:
-
-| Параметр     | Значение                                                                  |
-| ------------ | ------------------------------------------------------------------------- |
-| Репозиторий  | `ifontosh/DndGamePlayerUpdates` (подставьте свой owner/repo, если другой) |
-| Ветка        | `updates`                                                                 |
-| Расположение | **корень ветки** (не подпапка)                                            |
-
-Проверка: в браузере должен открываться, например:
-
-`https://git.mailib.ru/ifontosh/DndGamePlayerUpdates/raw/branch/updates/latest-mac.yml`
-
-Файлы Windows (`latest.yml`, `.exe`, …), которые кладёт CI, должны **остаться** в том же корне. Вы **добавляете или обновляете** только macOS-артефакты и **`latest-mac.yml`**, не удаляя артефакты Windows (если не делаете осознанную зачистку старых версий).
-
---
-
-## 3. Способ A — через `git` (удобно для больших dmg)
-
-### 3.1. Клон и ветка `updates`
-
-```bash
-cd ~/где-удобно
-git clone https://git.mailib.ru/ifontosh/DndGamePlayerUpdates.git
-cd DndGamePlayerUpdates
-git fetch origin
-git checkout updates
-```
-
-Если ветки `updates` ещё нет:
-
-```bash
-git checkout main
-git pull
-git checkout -b updates
-git push -u origin updates
-```
-
-Дальше для каждой выкладки работайте в ветке **`updates`**.
-
-### 3.2. Актуализировать локальную копию
-
-```bash
-git checkout updates
-git pull origin updates
-```
-
-### 3.3. Скопировать файлы из `release/` в корень клона
-
-```bash
-cp /путь/к/dnd_player/release/latest-mac.yml .
-cp /путь/к/dnd_player/release/*.dmg .
-cp /путь/к/dnd_player/release/*.zip .
-# blockmap, если есть:
-cp /путь/к/dnd_player/release/*.blockmap . 2>/dev/null || true
-```
-
-Проверка, что Windows-файлы на месте:
-
-```bash
-ls -la
-```
-
-### 3.4. Коммит и push
-
-```bash
-git add latest-mac.yml *.dmg *.zip
-git add *.blockmap 2>/dev/null || true
-git status
-git commit -m "mac: DNDGamePlayer vX.Y.Z (ручная выкладка)"
-git push origin updates
-```
-
-Для HTTPS обычно используют **персональный токен (PAT)** Gitea вместо пароля, либо настроенный **SSH** (`git@git.mailib.ru:ifontosh/DndGamePlayerUpdates.git`).
-
-### 3.5. Проверка
-
- Откройте `latest-mac.yml` по raw-URL (см. выше).
- Откройте в браузере прямую ссылку на один из `.dmg` из этого YAML — не должно быть 404.
-
---
-
-## 4. Способ B — через веб-интерфейс Gitea
-
-Подходит для редких правок; для больших **dmg** удобнее git.
-
-1. Репозиторий `DndGamePlayerUpdates` → ветка **`updates`**.
-2. Загрузить или изменить **`latest-mac.yml`** и бинарники (**имена как в `release/`**).
-3. Не удалять при этом файлы Windows в корне, если они нужны для PC-обновлений.
-
---
-
-## 5. Версии и Windows
-
- В **`latest-mac.yml`** и в именах файлов должна быть та **версия приложения**, которую вы отдаёте пользователям Mac (как в `package.json` на момент сборки).
- **`latest.yml`** (Windows) и **`latest-mac.yml`** (Mac) — разные файлы; версии на платформах могут совпадать или нет. Каждая ОС читает свой YAML.
-
---
-
-## 6. Подпись кода (кратко)
-
-Без **Developer ID** и при необходимости **нотаризации** macOS может ограничивать запуск после скачивания. На процедуру «залить файлы в репо» это не влияет, но влияет на UX после автообновления. Для продакшена имеет смысл позже настроить `CSC_LINK`, `CSC_KEY_PASSWORD` и нотаризацию по [документации electron-builder](https://www.electron.build/).
-
---
-
-## 7. Чеклист
-
-1. Локально собрали Mac с `--publish never` и верным `publish.url`.
-2. В `release/` есть **`latest-mac.yml`** и все объекты, на которые он ссылается.
-3. В ветке **`updates`** в корне репозитория обновили/добавили эти файлы, не снеся Windows-артефакты без необходимости.
-4. Проверили raw-URL **`latest-mac.yml`** и ссылку на dmg.
-5. В **упакованном** приложении с **активной лицензией** сработает существующий `electron-updater` (задержка первой проверки и cooldown — см. `app/main/update/installAutoUpdater.ts`).
-
---
-
-## Связанные документы
-
- Общая схема Gitea, секреты, раннер: [GITEA_AUTO_UPDATE.md](./GITEA_AUTO_UPDATE.md).
+Раньше файлы коммитили в репозиторий **`DndGamePlayerUpdates`**, ветка `updates`. Этот способ **больше не используется** — репозиторий можно удалить на Gitea.
@@ -1,4 +1,4 @@
-# Спецификация лицензирования DNDGamePlayer (этап D1)
+# Спецификация лицензирования TTRPG Player (этап D1)

 Документ фиксирует модель **D1**: онлайн-активация, срок, число устройств, отзыв, и как это согласуется с клиентом и сервером лицензий.

@@ -6,7 +6,7 @@

 ## Модель

-1. **Продуктовый ключ** — секрет покупателя, известен только ему и серверу. Обменивается на **лицензионный токен** через `POST /v1/activate` (онлайн-активация). В поле «Указать ключ» приложение принимает **продуктовый ключ** `DND-…` (клиент сам вызывает `POST /v1/activate` с `deviceId`) или уже готовый **токен** (две части base64url через одну точку).
+1. **Продуктовый ключ** — секрет покупателя, известен только ему и серверу. Обменивается на **лицензионный токен** через `POST /v1/activate` (онлайн-активация). В поле «Указать ключ» приложение принимает **продуктовый ключ** `TTRPG-…` или устаревший `DND-…` (клиент сам вызывает `POST /v1/activate` с `deviceId`) или уже готовый **токен** (две части base64url через одну точку). Новые ключи на сервере — только `TTRPG-…` (см. репозиторий лицензий).
 2. **Лицензионный токен** — публичная полезная нагрузка (`sub`, `pid`, `iat`, `exp`, `did`) + подпись **Ed25519**. Клиент хранит только токен и **публичный** ключ (вшит в приложение); подделать валидный токен без приватного ключа сервера невозможно.
 3. **Срок** — поле `exp` (unix секунды). Клиент отклоняет истёкший токен без сети.
 4. **Устройства** — поле `did` в токене: при активации сервер привязывает токен к `deviceId` клиента и ведёт учёт списка устройств на `sub` в `data.json` (`maxDevices`).
@@ -29,7 +29,7 @@
 Пример запуска AppImage:

 ```bash
-DND_LICENSE_INSECURE_FILE_STORAGE=1 ./DNDGamePlayer-1.0.12-x64.AppImage --no-sandbox --appimage-extract-and-run
+DND_LICENSE_INSECURE_FILE_STORAGE=1 ./TTRPGPlayer-1.0.12-x64.AppImage --no-sandbox --appimage-extract-and-run
 ```

 ## Юридическое (D9)