added documentation and decompiled client

PLANS.md

@@ -0,0 +1,64 @@
+ Proposed Direction
+
+  - Single core language: Go for all server runtime (gateway + lobby + game logic).
+  - Web/UI: TypeScript (Next.js or simple React/Vite) only.
+  - Goal: Keep binary protocol compatibility via a Gateway while the Core Monolith evolves.
+
+  ———
+
+  Architecture (Monolith First)
+
+  [Game Client] ⇄ [Go Gateway] ⇄ [Go Core Monolith]
+                                       ├─ Lobby module
+                                       ├─ Matchmaking module
+                                       ├─ Game loop module
+                                       └─ Data access layer
+
+  - Gateway: speaks binary protocol; maps opcodes to internal RPC/handlers.
+  - Core Monolith: simple Go service with clear module boundaries; no network protocol details here.
+  - Data: Postgres + Redis (optional) behind a DAL.
+
+  ———
+
+  Phase 0: Baseline Observability (immediate)
+
+  - Add request/session IDs at the lobby entrypoint.
+  - Add JSON logs (opcode, account, session, latency).
+  - Add packet capture/replay harness (proxy or gateway shim).
+
+  This sets up parity testing for any rewrite.
+
+  ———
+
+  Phase 1: Go Gateway (binary protocol fidelity)
+
+  - Implement binary parsing and encoding in Go.
+  - Map each opcode to a handler interface.
+  - For now, proxy handlers to legacy C servers (so clients keep working).
+
+  This becomes the compatibility anchor.
+
+  ———
+
+  Phase 2: Go Core Monolith (first rewrite)
+
+  - Implement core modules in Go and progressively cut traffic over.
+  - Start with lobby/auth/deck APIs (lower risk).
+  - Add game loop later with deterministic state checks.
+
+  ———
+
+  Phase 3: Data Migration
+
+  - Introduce Postgres schemas.
+  - Mirror writes (old → new), then flip reads.
+  - Eventually remove Couchbase.
+
+  ———
+
+  Why this fits your preferences
+
+  - Only Go + TS.
+  - Monolith first with future separation if needed.
+  - Fully off C while maintaining client compatibility.
+