WAIT — Single-maintainer risk — review before adopting

• Last commit today
• 8 active contributors
• MIT licensed
• CI configured
• ⚠ Single-maintainer risk — top contributor 92% of recent commits
• ⚠ No test directory detected

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Starward is an open-source third-party launcher for HoYoverse games (Genshin Impact, Honkai: Star Rail, Zenless Zone Zero) built in C# with WinUI 3, designed to replace the official HoYoPlay launcher. It provides game launching, account switching, game time tracking, screenshot management, and gacha record export—addressing limitations of the official launcher. Single-solution monorepo structure: src/Starward.Core/ contains reusable game logic (Gacha clients for Genshin/StarRail, audio language enums), while the main WinUI 3 app likely lives in src/ root. Gacha subsystem is modular with interfaces (IGachaType, GachaLogClient) and game-specific implementations (Genshin/StarRail folders). Localization centralized via Crowdin config.

Windows PC gamers using HoYoverse titles who want better launcher features (gacha history tracking, account management, playtime stats), and contributors interested in game launcher architecture, WinUI 3 desktop apps, or miHoYo API integration.

Actively developed and production-ready. The project has structured CI/CD pipelines (build.yml, publish_preview.yml workflows), organized localization via Crowdin (6+ languages), and a clear release process. Codebase is ~2.3MB C# (main language), with stable Windows 10+ OS targeting. Not abandoned—multiple publish workflows and localization coverage indicate ongoing maintenance.

Single-maintainer risk (Scighost organization). Reverse-engineering dependency on miHoYo/HoYoverse APIs (GachaLogClient, game info endpoints) creates fragility—API changes break gacha export. No visible test suite in file list suggests regression risk. Windows-only (no cross-platform support) limits contributor base.

Active release cycle with preview → stable promotion (convert_preview_to_stable.yml). Multiple publish workflows suggest staged rollout strategy. Localization is ongoing (Crowdin badge framework in README). No specific PR/issue data visible, but build infrastructure is actively maintained.

git clone https://github.com/Scighost/Starward.git
cd Starward
# Build using PowerShell script
.\build.ps1
# Or open Starward.slnx in Visual Studio 2022 and build from IDE

Daily commands:

# Visual Studio 2022 (Windows only)
# 1. Open Starward.slnx
# 2. Right-click solution → Build Solution (Ctrl+Shift+B)
# 3. Set Starward project as startup, press F5

# Or via PowerShell
.\build.ps1
# Output: bin/Release/ or bin/Debug/ containing Starward.exe

• src/Starward.Core/GameBiz.cs — Core game business identifier enum that routes all game-specific logic (Genshin, Star Rail, ZZZ, BH3) throughout the codebase
• src/Starward.Core/Gacha/GachaLogClient.cs — Base gacha log client abstraction that all game-specific gacha implementations inherit from; critical for extensibility
• src/Starward.Core/GameRecord/GameRecordClient.cs — Primary API client for fetching user game records across all supported games; central to the launcher's data aggregation
• src/Starward.Core/GameNotice/GameNoticeClient.cs — Game notice/alert notification system client that broadcasts in-game announcements to users
• build.ps1 — PowerShell build script that orchestrates the entire compilation and release pipeline for the launcher
• Starward.slnx — Solution file that defines all project dependencies and build order; entry point for IDE integration
• .github/workflows/build.yml — Main CI/CD workflow that builds, tests, and packages the launcher for distribution

Add Support for a New Game's Gacha System

1. Create a new game folder under src/Starward.Core/Gacha/NewGame/ (e.g., src/Starward.Core/Gacha/NewGame/) (src/Starward.Core/Gacha/NewGame/NewGameGachaClient.cs)
2. Implement NewGameGachaClient inheriting from GachaLogClient and override FetchGachaLogAsync() with game-specific API calls (src/Starward.Core/Gacha/NewGame/NewGameGachaClient.cs)
3. Create NewGameGachaType enum implementing IGachaType to define gacha pool types (standard, limited, weapon, etc.) (src/Starward.Core/Gacha/NewGame/NewGameGachaType.cs)
4. Add NewGameGachaItem and NewGameGachaInfo models matching the game's API response structure (src/Starward.Core/Gacha/NewGame/NewGameGachaItem.cs)
5. Update src/Starward.Core/GameBiz.cs to add NewGame enum value in the GameBiz enum (src/Starward.Core/GameBiz.cs)
6. Add JSON source-gen context in GachaLogJsonContext.cs to register NewGameGachaItem for deserialization (src/Starward.Core/Gacha/GachaLogJsonContext.cs)

Add a New Game Record Feature (e.g., Daily Notes)

1. Create folder src/Starward.Core/GameRecord/NewGame/DailyNote/ with NewGameDailyNote.cs model (src/Starward.Core/GameRecord/NewGame/DailyNote/NewGameDailyNote.cs)
2. Add properties to NewGameDailyNote matching the API response (resin, tasks, expeditions, etc.) (src/Starward.Core/GameRecord/NewGame/DailyNote/NewGameDailyNote.cs)
3. Implement the async fetch method in GameRecordClient.cs with game-specific URL and authentication logic (src/Starward.Core/GameRecord/GameRecordClient.cs)
4. Register NewGameDailyNote in GameRecordJsonContext.cs for JSON source-gen deserialization (src/Starward.Core/GameRecord/GameRecordJsonContext.cs)

Add Support for a New Language

1. Create translation file in the crowdin project via Crowdin interface (or add to crowdin.yml for automated sync) (crowdin.yml)
2. Define the new language code in src/Starward.Core/AudioLanguage.cs enum if adding a game audio language (src/Starward.Core/AudioLanguage.cs)
3. Add translated markdown documentation files like docs/README.new-LANG.md following existing language files pattern (docs/README.zh-CN.md)
4. Submit translations via Crowdin or create pull request with .resx files; CI will validate locale codes (.github/workflows/build.yml)

• .NET (C#) with MAUI/WinUI3 — Native Windows performance, modern async/await concurrency model, and integrated TypedClient patterns for HoYoverse API integration
• System.Text.Json with source generators — Zero-allocation deserialization for large gacha/record responses; AOT-friendly compile-time JSON contract generation
• WebView2 runtime — Embedded Chromium for rendering in-game web content, login flows, and

1. WebView2 + WebP runtime dependencies: App won't launch without both installed (noted in README); ensure test environments have these. 2. miHoYo API fragility: Gacha log endpoints are undocumented and subject to change—AuthKey tokens expire, breaking export until user manually copies new URL. 3. Windows-only: PowerShell build scripts (build.ps1) and WinUI 3 lock this to Windows; cross-platform testing impossible. 4. Crowdin integration: Translations fetched from Crowdin during build—network dependency for localized builds. 5. No visible test suite: High risk for regressions when modifying gacha parsing logic.

• AuthKey token cycling — Starward's gacha export depends on user-provided AuthKey tokens from miHoYo that expire hourly; understanding token lifecycle and refresh logic is critical for debugging export failures
• Game-specific API versioning — Genshin and Star Rail use different gacha endpoint formats, query parameters, and response schemas; multi-game support requires abstraction (IGachaType) to handle these differences
• WebView2 interop — Starward uses Chromium-based WebView2 for rendering UI—understanding WinRT marshaling and JavaScript bridge is essential for modifying the launcher UI
• JSON source generation (System.Text.Json) — GachaLogJsonContext.cs uses C# 10+ source generators for zero-allocation JSON deserialization of gacha responses—critical for performance when parsing large history files
• Reverse-engineering undocumented APIs — Entire gacha feature relies on reverse-engineered miHoYo endpoints (no official docs)—teaches debugging techniques for closed APIs and fragility management
• WinUI 3 localization with Crowdin — Starward supports 6+ languages via Crowdin CI/CD integration—understanding resource files and language fallback is needed for adding translations or new UI strings
• Third-party launcher architecture — Starward replaces an official launcher (HoYoPlay)—understanding game detection, installation path management, and launcher protocol registration is foundational

• Scighost/ysondp — Likely a companion project—Scighost's other work in HoYoverse ecosystem (name suggests Genshin file parsing)
• jmjt90/Genshin-Launcher — Alternative third-party Genshin launcher—demonstrates same reverse-engineering approach for comparison
• tamilpp/Genshin-Gacha-Analyzer — Gacha history analyzer—would integrate with Starward's export data for visualization/analysis downstream
• HoYoLAB/api-docs — Official HoYoLAB API documentation—provides context for authenticated endpoints Starward reverse-engineers
• microsoft/WinUI-Gallery — WinUI 3 component showcase—reference for UI patterns and best practices used in Starward's interface

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for Gacha log parsing across all game types

The Gacha module (src/Starward.Core/Gacha/) has multiple game-specific implementations (Genshin, StarRail, ZZZ) with JSON deserialization logic (GachaLogJsonContext.cs, GachaItemIdJsonConverter.cs) but no visible test files. Testing edge cases in gacha data parsing is critical since this feature handles user data exports and could have breaking changes across game updates.

• [ ] Create src/Starward.Core.Tests/Gacha/ directory structure
• [ ] Add unit tests for GachaItemIdJsonConverter.cs with various item ID formats
• [ ] Add tests for each game's GachaLogClient (Genshin, StarRail, ZZZ) with mock API responses
• [ ] Test GachaLogQuery.cs for proper URL parameter encoding and pagination
• [ ] Add tests for GachaLogResult.cs deserialization with malformed/missing fields

Add GameRecord API tests and documentation for all supported games

The GameRecord module (src/Starward.Core/GameRecord/) shows only BH3 DailyNote implementation in the file list, but the project claims to support 'all PC games of HoYoverse'. There's a significant documentation gap—docs/UrlProtocol.md exists but no docs/GameRecord.md explaining the API structure, supported games, or test coverage for game-specific record clients.

• [ ] Create docs/GameRecord.md documenting all supported game record types and their endpoints
• [ ] Create integration test suite in src/Starward.Core.Tests/GameRecord/ for each game (BH3, Genshin, StarRail, ZZZ)
• [ ] Add mock test data for daily note responses from each game
• [ ] Document any differences in API response structures between games
• [ ] Add tests for GameRecord client error handling and rate limiting

Implement CI workflow for automated cross-platform binary publishing

The workflows directory has multiple publish workflows (publish_preview.yml, publish_preview_2.yml, publish_preview_3.yml) suggesting manual intervention or incomplete automation. The build.ps1 script exists but integration with GitHub Actions for automated Windows builds and release artifacts appears fragmented. A unified, documented CI/CD pipeline would reduce maintenance burden.

• [ ] Consolidate publish_preview*.yml workflows into a single reusable build.yml workflow
• [ ] Add build matrix for multiple Windows versions (Win10, Win11) in the build workflow
• [ ] Configure automatic changelog generation from git tags/commits into release notes
• [ ] Add artifact signing steps (if applicable for HoYoverse security requirements)
• [ ] Document the build/release process in docs/ with examples of triggering builds

• Add unit tests for GachaLogJsonContext.cs: Currently no visible test files for JSON deserialization of gacha responses. Create xUnit tests covering edge cases (missing fields, malformed AuthKeys, expired tokens) to prevent regression when miHoYo changes API responses.
• Document API reverse-engineering in docs/: Add docs/GachaApiReference.md explaining how Genshin/StarRail AuthKey tokens work, what GachaLogQuery parameters do, and how to debug API changes. Currently undocumented—would help maintainers and contributors.
• Support Honkai: Star Rail Beyond Gacha: Code exists (GenshinBeyondGachaClient.cs) but unclear if fully integrated. Audit whether StarRailGachaClient needs equivalent Beyond gacha support, add if missing, and test end-to-end.

• Medium · Gacha Log Client - Potential Authentication Token Exposure — src/Starward.Core/Gacha/GachaLogClient.cs. The GachaLogClient.cs handles authentication tokens for gacha history queries. Without reviewing the actual implementation, there's a risk that authentication tokens could be logged, stored insecurely, or transmitted without proper validation. Gacha log URLs typically contain sensitive authentication parameters. Fix: Implement secure token storage using Windows Data Protection API (DPAPI), ensure tokens are never logged, validate SSL/TLS certificates, and implement token rotation mechanisms. Avoid storing tokens in plaintext or in user-accessible locations.
• Medium · Game Record Client - Sensitive User Data Handling — src/Starward.Core/GameRecord/GameRecordClient.cs and related files. The GameRecordClient processes user game statistics and personal account information. The codebase structure suggests handling of user roles, accounts, and device fingerprints (DeviceFpResult.cs). Improper handling could lead to privacy violations or account compromise. Fix: Implement data minimization principles, encrypt sensitive user data at rest, use secure communication channels (HTTPS with certificate pinning), implement proper access controls, and add audit logging for sensitive data access.
• Medium · JSON Deserialization - Potential Deserialization Attacks — src/Starward.Core/Gacha/GachaLogJsonContext.cs, src/Starward.Core/GameRecord/GameRecordJsonContext.cs, src/Starward.Core/GameNotice/GameNoticeJsonContext.cs. Multiple JsonContext files (GachaLogJsonContext.cs, GameRecordJsonContext.cs, GameNoticeJsonContext.cs) indicate extensive JSON deserialization from external sources (game APIs). Without proper validation, this could lead to object injection attacks or unexpected behavior. Fix: Use strongly-typed JSON deserialization, implement schema validation, use SerializationBinder restrictions if using BinaryFormatter (avoid if possible), validate all deserialized data, and implement input sanitization.
• Medium · API Client Communications - Missing Security Headers Validation — src/Starward.Core/Gacha/ and src/Starward.Core/GameRecord/. Multiple API clients interact with miHoYo services (GenshinGachaClient, StarRailGachaClient, etc.). Without visible security header validation, there's risk of MITM attacks, server spoofing, or SSL stripping. Fix: Implement certificate pinning for API communications, validate security headers (HSTS, X-Content-Type-Options), implement proper error handling for certificate validation failures, and use TLS 1.2 minimum.
• Low · Game Account Switching - Potential Account Enumeration — src/Starward.Core/GameRecord/GameRecordUser.cs, src/Starward.Core/GameRecord/GameRecordRole.cs. The launcher supports switching game accounts. If the account enumeration or validation is not properly implemented, attackers might enumerate valid accounts or bypass account restrictions. Fix: Implement rate limiting on account queries, use secure account identifiers (avoid sequential IDs), implement proper authorization checks, add audit logging for account access attempts.
• Low · Third-Party Content Handling - XSS Risk in Game Notices — src/Starward.Core/GameNotice/GameNoticeClient.cs, src/Starward.Core/GameNotice/AlertAnn.cs. GameNoticeClient processes game announcements and notices that may contain HTML/JavaScript. If not properly sanitized before display, this could lead to stored XSS attacks. Fix: Implement HTML sanitization library (e.g., HtmlSanitizer), validate content type, implement Content Security Policy, use WebView2 with restricted permissions, avoid dangerouslySetInnerHTML patterns.
• Low · Dependency Management - Version Pinning Not Visible — Project files (*.csproj, *.sln). The dependency file content is not provided in the analysis. Without seeing specific versions, there's potential for vulnerable transitive dependencies to be included without explicit tracking. Fix: Use explicit version pinning in project files, regularly audit dependencies using tools like OWASP Dependency-Check or NuGet vulnerability scanner, implement Software Bill of Materials (SBOM), keep dependencies updated.
• undefined · undefined — undefined. undefined Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Scighost/Starward shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Scighost/Starward repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Scighost/Starward.

What it runs against: a local clone of Scighost/Starward — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Scighost/Starward | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Scighost/Starward. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Scighost/Starward.git
#   cd Starward
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Scighost/Starward and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Scighost/Starward(\\.git)?\\b" \\
  && ok "origin remote is Scighost/Starward" \\
  || miss "origin remote is not Scighost/Starward (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "src/Starward.Core/GameBiz.cs" \\
  && ok "src/Starward.Core/GameBiz.cs" \\
  || miss "missing critical file: src/Starward.Core/GameBiz.cs"
test -f "src/Starward.Core/Gacha/GachaLogClient.cs" \\
  && ok "src/Starward.Core/Gacha/GachaLogClient.cs" \\
  || miss "missing critical file: src/Starward.Core/Gacha/GachaLogClient.cs"
test -f "src/Starward.Core/GameRecord/GameRecordClient.cs" \\
  && ok "src/Starward.Core/GameRecord/GameRecordClient.cs" \\
  || miss "missing critical file: src/Starward.Core/GameRecord/GameRecordClient.cs"
test -f "src/Starward.Core/GameNotice/GameNoticeClient.cs" \\
  && ok "src/Starward.Core/GameNotice/GameNoticeClient.cs" \\
  || miss "missing critical file: src/Starward.Core/GameNotice/GameNoticeClient.cs"
test -f "build.ps1" \\
  && ok "build.ps1" \\
  || miss "missing critical file: build.ps1"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Scighost/Starward"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.