shacraft-launcher/PLAN.md

План ShaCraft Launcher

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

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

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

• Сохранены изменения 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

• Новый native claim закрепляет свободный ник за аккаунтом без входа в игру. Старые имена резервируются backend и переносятся администратором.
• После установки Rust создаёт Ed25519 ключ через OS CSPRNG и запрашивает ticket на фиксированном ShaCraft API. Ник для запуска берётся из ticket; локальные настройки не могут его заменить.
• Ticket и PKCS#8 private key передаются только окружением дочерней Java; session сайта остаётся в native. В argv, argfile, settings, логах и IPC секретов нет. Account permit держится до spawn.
• Ошибки и результаты привязки показаны в диалоге; двойной клик не создаёт параллельных запросов, старого polling нет.
• Локально пройдены 64 Rust-теста (5 live-тестов пропущены), 22 UI-теста, TypeScript/Vite и сборка Linux x86-64 tauri:build -- --no-bundle. Шесть браузерных сценариев используют только замоканный Tauri IPC.
• Собраны неподписанные AppImage и deb версии 0.1.2 на Ubuntu 26.04; проверены извлечение AppImage и metadata deb. Работа на старых Ubuntu и установка пакетов на чистой машине этим не подтверждены.
• Выложены backend, подписанный клиентский мод и серверный мод Aeronautics; сервер перезапущен и healthy. Whitelist сохранён; LoginSystem заменён только на aoc. Пакеты Linux 0.1.2 опубликованы на сайте, AppImage запущен локально.
• Настоящий изолированный NeoForge: новый ticket допускает в мир, отсутствие мода/билета и повтор билета отклоняются. Старый LoginSystem на клиенте не мешает. Подключение дубликата без авторизации не выбивает уже играющего владельца.
• На публичном сервере подключение без мода отклонено до входа в мир; 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 доказательством неизменённости клиентского бинарника.