neon-sprawl-archived/.cursor/rules/architecture-authority.mdc

--- description: Server-authoritative simulation; client sends intents; transport-only networking; no client-trusted outcomes. alwaysApply: true --- # Architecture — authority & client boundaries (Neon Sprawl) Canonical background: [`docs/architecture/tech_stack.md`](docs/architecture/tech_stack.md). This rule is the **non-negotiable slice** for day-to-day implementation. ## Where truth lives - **Authoritative game state and rules** live on the **C# / ASP.NET Core** server (zones, combat resolution, inventory, economy, progression, anything audit-worthy). - The **Godot** client is responsible for **input, presentation, camera, UI, and local feel** (e.g. interpolation, cosmetic prediction only if explicitly designed)—not for deciding final outcomes of gameplay systems. ## Network shape - **WebSocket** or **TCP** is **transport only**. Do not put authoritative simulation in Godot’s **high-level multiplayer** templates or patterns that imply peers co-own game state. - Prefer a clear boundary: client emits **intents** (e.g. `MoveIntent`, `UseAbilityIntent`); server validates, simulates, persists as needed, and responds with **state deltas or snapshots**. Names are examples—follow whatever contracts exist in-repo. ## What the client must not “decide” - Do not treat the client as source of truth for **loot, trades, crafting results, currency, or anti-cheat-sensitive** behavior. Those paths belong on the server with validation and, where required, **database transactions** (see tech stack doc). ## Exceptions - **Prototype-only, client-local** behavior is allowed when a Jira story or plan explicitly scopes it (e.g. **no server yet**, “client-only milestone”) and docs/README call out that it is **temporary** until authoritative sync exists. Do not silently expand client-only shortcuts into permanent architecture. ## When unsure - Default to **server validates + owns outcome**; add a short note in the story plan or PR if you introduce a deliberate exception.