🏷️ GAMES-Reborn Naming Conventions

To maintain absolute enterprise consistency across the organization, all repositories, branches, and codebases MUST follow this strict naming pattern.

📦 Repository Patterns

We use a rigid prefix system so developers immediately know the scope of a repository.

• core-[service]: Foundational platform microservices that all games rely on.
  • Examples: core-auth, core-shared, core-tools
• game-[title]: Isolated game-specific server implementations and reverse-engineering logic.
  • Examples: game-mu3, game-lineagew, game-aion2
• web-[component]: Frontend, CMS, and user-facing panels.
  • Examples: web-platform, web-admin
• infra-[component]: DevOps, IaC, and DRM tooling.
  • Examples: infra-setup, infra-drm

(Note: We will gradually rename our current repos, e.g. gr-universal-auth -> core-auth, to perfectly match this standard).

🌿 Branching Patterns (GitFlow)

Never push directly to main unless it's a critical hotfix.

• main: Always production-ready, compiled, and stable.
• eat/[name]: For new functionality (e.g., eat/stripe-webhooks).
• ix/[name]: For patches (e.g., ix/memory-leak).
• docs/[name]: For documentation updates.

🦀 Code Level (Rust Standard)

Since the backend is standardized on Rust, we strictly enforce Rust idioms:

• Crates/Packages: snake_case (e.g., games_reborn_auth)

• Structs/Enums: PascalCase (e.g., PlayerAccount, GameServerConfig)

• Functions/Variables: snake_case (e.g., erify_token(), max_players)

• Constants: SCREAMING_SNAKE_CASE (e.g., MAX_CONNECTIONS)

• info-[target]: Dedicated documentation and knowledge-base repositories for large-scale projects (e.g., info-game-mu3, info-network). Keeps source code repos clean from massive binary doc assets.