정리중

AGENTS.md

@@ -3,6 +3,8 @@
 ## Project Goal (Rewrite)
 - This repository is transitioning from the legacy PHP codebase to a TypeScript-based monorepo using pnpm workspaces.
 - The legacy game remains the current active source under `legacy/` while the rewrite is prepared alongside it.
+- Legacy data under `legacy/` is for migration only; once DB migration is complete,
+  the runtime will no longer depend on legacy data.
 
 ## Project Structure & Module Organization
 - `legacy/` contains the application source. This is the active codebase.
@@ -32,6 +34,9 @@
 
 ## Planned Runtime & Tooling
 - Backend: Node.js + Fastify, with Prisma ORM.
+- Turn daemon: turn scheduler/resolver service for game ticks.
+- Turn daemon and API server communicate via Redis Stream or Redis pub/sub.
+- API server and frontend may use SSE for live updates.
 - API: tRPC + zod.
 - Frontend: Vue 3, Pinia, Vue Router, TailwindCSS, Vite.
 - Data: PostgreSQL; sessions backed by Redis.

docs/architecture/overview.md

@@ -11,6 +11,11 @@ monorepo plan is prepared alongside it.
 - Legacy frontend: Vue/TypeScript under `legacy/hwe/ts/`
 - Rewrite (planned): pnpm workspace monorepo under `packages/` and `app/`
 
+## Legacy Data Migration Policy
+
+- Data under `legacy/` is migration-only and not used by the rewrite at runtime.
+- After DB migration completes, legacy data is no longer required.
+
 ## Data and State
 
 - PHP engine owns authoritative gameplay state today

docs/architecture/rewrite-plan.md

@@ -23,6 +23,11 @@ Vue 3 frontends.
 - Data: PostgreSQL, Redis sessions
 - Testing: Vitest
 
+## Legacy Data Migration
+
+- Legacy data is for migration only; the rewrite runtime does not depend on it.
+- Once DB migration is complete, legacy data can be retired.
+
 ## Profiles (Planned)
 
 - `che`, `kwe`, `pwe`, `twe`, `nya`, `pya`

docs/architecture/runtime.md

@@ -20,6 +20,8 @@ deployments predictable.
 - Turn daemon responsibilities: scheduling, turn resolution, state persistence
 - API server responsibilities: query/command intake, validation, response shaping
 - Concurrency model between daemon and API server
+- Communication channel: Redis Stream or Redis pub/sub
+- Client updates: SSE between API server and frontend where appropriate
 
 ## Engine Runtime Flow (Draft)
 
@@ -38,13 +40,16 @@ deployments predictable.
 
 ### API Server Flow
 
-- The API server validates queries/commands and writes them to Redis Streams.
+- The API server validates queries/commands and writes them to Redis Streams
+  or Redis pub/sub.
 - After a request is processed, the API server returns the result to clients.
 - Read-only queries may access the DBMS directly.
+- The API server may use SSE to stream live updates to the frontend.
 
 ### Queue and Rate Limits
 
-- API server requests are delivered to the daemon via Redis Streams.
+- API server requests are delivered to the daemon via Redis Streams or
+  Redis pub/sub.
 - Redis Stream mutation requests are rate-limited per user.
   - Each user can have up to 30 pending mutation requests.
   - Additional requests are rejected once the limit is exceeded.