shacraft-launcher/PLAN.md

# План ShaCraft Launcher

## Сделано: рефакторинг 2026-09-09

- [x] React components/hooks/typed IPC/state reducers вместо единого main.tsx.
- [x] Строгий TypeScript, тесты async lifecycle и последовательных сохранений.
- [x] Rust commands по ответственности; signed-only синхронизация профиля.
- [x] Общие atomic files, process-local operation guards, portable path checks.
- [x] Проверка подписи, размера envelope и profile ID; bounded provider redirects.
- [x] Push/PR проверки и ручная матрица сборки с артефактами.

## Следующие задачи

- [x] Сохранены изменения 0.1.1 из GitHub: обязательный ShaCraft-аккаунт,
  подтверждённый ник, реальный онлайн и исправления Windows-install pipeline.
- [ ] Microsoft (отдельное будущее решение): собственный client ID + API
  approval и живой OAuth-тест. Текущий запуск использует ShaCraft identity.
- [ ] Cold install / repair / update / game exit на чистых Windows/Linux/macOS.
  Unit tests и web preview не заменяют эти прогоны.
- [ ] Windows Authenticode / macOS signing-notarization и проверка установщиков.
- [ ] Реальная отмена загрузок, журнал с редактированием токенов и retry UX.
- [ ] Выбор каталога профиля и безопасный reset только managed-файлов.
- [ ] Keychain-хранилище refresh token; cross-process exclusion при необходимости.
- [ ] Динамический каталог и новости; реальный Aeronautics онлайн уже
  загружается через фиксированный display-only API. Не имитировать данные.

## Вход по одноразовому разрешению: внедрение 2026-09-10

- [x] Новый native claim закрепляет свободный ник за аккаунтом без входа в игру.
  Старые имена резервируются backend и переносятся администратором.
- [x] После установки Rust создаёт Ed25519 ключ через OS CSPRNG и запрашивает
  ticket на фиксированном ShaCraft API. Ник для запуска берётся из ticket;
  локальные настройки не могут его заменить.
- [x] Ticket и PKCS#8 private key передаются только окружением дочерней Java;
  session сайта остаётся в native. В argv, argfile, settings, логах и IPC
  секретов нет. Account permit держится до spawn.
- [x] Ошибки и результаты привязки показаны в диалоге; двойной клик не создаёт
  параллельных запросов, старого polling нет.
- [x] Локально пройдены 64 Rust-теста (5 live-тестов пропущены), 22 UI-теста,
  TypeScript/Vite и сборка Linux x86-64 `tauri:build -- --no-bundle`.
  Шесть браузерных сценариев используют только замоканный Tauri IPC.
- [x] Собраны неподписанные AppImage и deb версии 0.1.2 на Ubuntu 26.04;
  проверены извлечение AppImage и metadata deb. Работа на старых Ubuntu и
  установка пакетов на чистой машине этим не подтверждены.
- [x] Выложены backend, подписанный клиентский мод и серверный мод Aeronautics;
  сервер перезапущен и healthy. Whitelist сохранён; LoginSystem заменён только
  на `aoc`. Пакеты Linux 0.1.2 опубликованы на сайте, AppImage запущен локально.
- [x] Настоящий изолированный NeoForge: новый ticket допускает в мир, отсутствие
  мода/билета и повтор билета отклоняются. Старый LoginSystem на клиенте не мешает.
  Подключение дубликата без авторизации не выбивает уже играющего владельца.
- [x] На публичном сервере подключение без мода отклонено до входа в мир;
  HTTPS verifier из контейнера, подпись manifest и SHA-256 мода проверены.
  Backend Docker: 404 tests + 48 subtests, включая истечение, отзыв session,
  чужую identity, whitelist, резервирование имён и атомарное погашение.
- [x] Полный вход в production Aeronautics через установленный лаунчер
  подтверждён пользователем 2026-09-10: «Присоединился!». Это пользовательское
  подтверждение, а не автоматизированный cold-install тест.
- [ ] Проверить cold install и этот протокол на Windows/macOS, выпустить
  подписанные пакеты. Локальная Linux-сборка не подтверждает эти платформы.
- [ ] Удобное переподключение: сейчас использованный или истёкший ticket
  требует нового запуска игры из лаунчера; автоматического обновления нет.

## Самообновление лаунчера 0.1.3: реализация 2026-09-10

- [x] Отдельный канал обновления приложения на фиксированном HTTPS endpoint.
  Выделенный публичный ключ проверяет подпись metadata и пакета; версия,
  заметки и URL связаны подписью. Redirect, downgrade и произвольные пути
  из webview запрещены; размеры metadata и загрузки ограничены.
- [x] Vendored Tauri updater 2.11.0 принимает уже проверенный JSON через
  `check_metadata` без второго HTTP-запроса. На Linux AppImage заменяется
  атомарно через временный файл в том же каталоге с проверкой подписи и fsync.
- [x] Проверка при старте без автоматической установки; доступны уведомление
  о новой версии, ручная проверка, заметки, прогресс, ошибки, повторная попытка
  и явный перезапуск. Сбой проверки не блокирует установленный лаунчер.
- [x] Native guards исключают обновление во время игры и конфликтующих
  операций. На время установки и до перезапуска заблокированы запуск игры,
  ремонт сборки и изменения аккаунта. Для deb и development binary показано
  сообщение об установке вручную; версия 0.1.2 требует первого ручного обновления.
- [x] Пройдены 76 Rust-тестов, 28 UI-тестов и 11 тестов publisher;
  TypeScript/Vite успешно собраны. Девять браузерных сценариев с mock Tauri IPC
  проверяют обновление, ошибки, повтор, блокировки и восстановление состояния;
  внешняя сеть и реальные аккаунты в этих сценариях не используются.
- [x] Живой native-прогон скачал 0.1.3 с production HTTPS: повреждение
  отклонено без изменения старого файла, подлинный пакет атомарно заменил
  временную копию 0.1.2. Исходный AppImage сохранён, хеши проверены.
- [x] Опубликованы Linux 0.1.3 и подписанный stable feed; HTTPS 200,
  `Cache-Control: no-store`, подписи и хеши проверены. Ссылка на сайте обновлена.
  AppImage установлен в `~/Applications`, добавлен ярлык и проверен запуск.
- [ ] Полный GUI-цикл «Обновить → Перезапустить» проверить на следующем
  релизе; текущий прогон проверяет native-установку и запуск пакета отдельно.
- [ ] Проверить установку и самообновление Windows/macOS перед публикацией
  пакетов этих платформ; Authenticode/notarization остаются отдельными задачами.

## Обновление DEB 0.1.4: 2026-09-10

- [x] Отдельный подписанный deb entry, определение установленного формата
  и сохранение AppImage-совместимости для клиентов 0.1.3.
- [x] Одно системное подтверждение через pkexec. Root helper до запуска GUI
  повторно проверяет подписи и точные Package/Version/Architecture, получает
  только bounded bytes через stdin и устанавливает пакет из root-only staging.
  Пароль не попадает в лаунчер; отмена не открывает запасные окна авторизации.
- [x] Dpkg отказывается от downgrade и сохраняет системную блокировку пакетов.
  Ошибки частичной установки не маскируются; автоматических повторов нет.
  Read-only inspection имеет ограничение вывода и времени для группы процессов;
  работающий dpkg не прерывается таймаутом посреди изменения пакета.
- [x] 32 UI-теста, TypeScript/Vite и 12 браузерных сценариев с mock IPC;
  18 publisher-тестов с настоящими minisign и deb, включая переход feed 0.1.3.
- [x] 84 native-теста прошли. Реальный root-helper в изолированном Ubuntu 26.04
  прошёл 10 сценариев: установка подписанного 0.1.4, повреждения, неверные
  права/временный каталог, занятый dpkg, повтор и защита от downgrade.
  Dpkg подтвердил версию, тестовый маркер профиля сохранён. GUI-подтверждение
  PolicyKit этим контейнерным прогоном не проверялось; отмена покрыта UI/unit.
- [x] Опубликованы подписанные AppImage/deb 0.1.4, проверены байты feed и deb,
  обе кнопки сайта и системная инструкция. Backend: 404 tests + 48 subtests,
  Ruff clean. Minecraft не перезапускался, данные аккаунтов не менялись.
  Deb 0.1.3 и ниже требуют первого ручного обновления до 0.1.4.

## Связанные серверные риски

Серверный план находится в `/root/shacraft/PLAN.md`. Для admission обязательны
атомарная одноразовая проверка ticket, привязка к текущим session/аккаунту/нику,
проверка до входа в мир и сохранение whitelist как серверного ограничения.
Старые игровые имена нельзя отдавать первому зарегистрировавшемуся; их
резервирование и назначение аккаунтам — отдельный этап миграции. Старый
NoGravity challenge-поток должен быть закрыт при включённом admission, чтобы
он не обходил резервирование имени. Остальные серверные задачи включают
enforcement реферальных правил и очередь повторов whitelist. Не менять
протокол незаметно в клиентском рефакторинге и не считать ticket доказательством
неизменённости клиентского бинарника.