# План 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 не заменяют эти прогоны.
- [ ] Подписанные installer-релизы и подписанное автообновление лаунчера.
- [ ] Реальная отмена загрузок, журнал с редактированием токенов и 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, резервирование имён и атомарное погашение.
- [ ] Полный вход в production Aeronautics через установленный лаунчер
  подтвердить отдельно; изолированный мир не заменяет проверку полного модпака.
- [ ] Проверить cold install и этот протокол на Windows/macOS, выпустить
  подписанные пакеты. Локальная Linux-сборка не подтверждает эти платформы.
- [ ] Удобное переподключение: сейчас использованный или истёкший ticket
  требует нового запуска игры из лаунчера; автоматического обновления нет.

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

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