---
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 Linear issue 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.