docs: comprehensive architecture plan for acdream

The single most important document in the project. Defines:

Architecture: 6-layer stack (Platform → Renderer → Network → World →
Game Objects → Plugin API). The code is modern C#; the behavior
matches the retail client exactly.

GameEntity: the unified entity class that replaces the current
scattered state (WorldEntity + AnimatedEntity + guid dicts + player
controller). Every world object is a GameEntity with PhysicsBody +
AnimationSequencer + CellTracker + MotionInterpreter + AppearanceState.

Per-frame update order: Network → Streaming → Input → Entity tick
(motion → physics → collision → cell → animation) → Render → Plugin.

Execution plan (R1-R8):
  R1: GameEntity refactor (unify scattered state)
  R2: Thin GameWindow (extract to proper systems)
  R3: CellBSP + wall collision (indoor transitions)
  R4: Complete animation state machine
  R5: Lighting from decompiled AdjustPlanes
  R6: Server compliance (authoritative Z, keepalive)
  R7: Interaction (doors, NPCs, chat, inventory)
  R8: Plugin API completion (Lua macros)

Also updates CLAUDE.md to establish the architect role and reference
the architecture doc as the single source of truth.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -2,24 +2,35 @@
 
 ## Goal
 
-Build **acdream**, a modern open-source C# .NET 10 Asheron's Call client. The
-end state is a working client that:
+Build **acdream**, a modern open-source C# .NET 10 Asheron's Call client.
+A faithful port of the retail AC client's behavior to modern C# + Silk.NET,
+with a plugin API the original never had.
 
-- Loads the retail AC dat files and renders the world (terrain, static meshes,
-  dynamic entities, characters)
-- Connects to an ACE server and plays as a character
-- Exposes a **first-class plugin API** so players can write native scripts and
-  macros to automate gameplay — this is a core architectural requirement, not
-  a bolt-on
+**The code is modern. The behavior is retail.**
 
-The codebase is organized by phase. Current phase state lives in memory
-(`memory/project_phase_*_state.md`), current phase plans live in `docs/plans/`,
-and the long-term vision lives in `memory/project_acdream.md`.
+Every AC-specific algorithm is ported from the decompiled retail client
+(`docs/research/decompiled/`, 22,225 functions, 688K lines of C). The code
+around those algorithms is modern C# with clean architecture. The plugin API
+exposes game state through well-defined interfaces.
+
+**Architecture:** `docs/architecture/acdream-architecture.md` is the
+single source of truth for how the client is structured. All work must
+align with this document. When the architecture doc and reality diverge,
+update one or the other — never leave them out of sync.
+
+**Execution phases:** R1→R8 in the architecture doc. Each phase has clear
+goals, test criteria, and builds on the previous. Don't skip phases.
+
+The codebase is organized by layer (see architecture doc). Current phase
+state lives in memory (`memory/project_*.md`), plans in `docs/plans/`,
+research in `docs/research/`.
 
 ## How to operate
 
-**You are the lead engineer on this project at all times. Stop as little as
-possible.** Drive work autonomously and continuously through full phases and
+**You are the lead engineer AND architect on this project at all times.**
+You own the architecture (`docs/architecture/acdream-architecture.md`),
+the execution plan (phases R1–R8), the development workflow, and all
+technical decisions. Stop as little as possible. Drive work autonomously and continuously through full phases and
 across commit boundaries. Do not stop mid-phase for routine progress check-ins,
 permission asks on low-stakes design calls, or "should I continue?" confirmations.
 The user has repeatedly authorized direct-to-main commits, multi-commit sessions,