docs: 업데이트된 문서 내용 반영 및 Redis 통합 설명 추가

AGENTS.md

@@ -18,8 +18,8 @@
 
 - `legacy/` contains the application source. This is the active codebase.
 - PHP entry points live under `legacy/` and `legacy/hwe/` (for example `legacy/index.php`, `legacy/hwe/index.php`).
-- `legacy/` is mostly a shell; `legacy/src/` is largely unused.
-- Core PHP domain logic lives under `legacy/hwe/sammo/` (PSR-4 `sammo\\` namespace).
+- `legacy/src/sammo/` contains core utility classes for the `sammo\\` namespace.
+- Core PHP domain logic lives under `legacy/hwe/sammo/` (also part of the `sammo\\` namespace).
 - Frontend TypeScript/Vue sources are in `legacy/hwe/ts/` with shared components in `legacy/hwe/ts/components/`.
 - Styles are split between `legacy/css/` and SCSS in `legacy/hwe/scss/`.
 - Tests: PHPUnit in `legacy/tests/`, TypeScript tests in `legacy/hwe/test-ts/`.
@@ -62,25 +62,25 @@
 These are placeholders to align teams; adjust once packages exist.
 
 - `pnpm install`: install all workspace dependencies.
-- `pnpm typecheck`: run TypeScript type checks in all packages.
-- `pnpm lint`: lint all packages.
-- `pnpm test`: run all unit tests (Vitest where configured).
-- `pnpm build`: build all packages/apps.
-- `pnpm dev`: run dev servers where applicable.
+- `pnpm typecheck`: run TypeScript type checks in all packages (via turbo).
+- `pnpm lint`: lint all packages (via turbo).
+- `pnpm test`: run all unit tests (via turbo).
+- `pnpm build`: build all packages/apps (via turbo).
+- `pnpm dev`: run dev servers where applicable (via turbo).
 - `pnpm --filter ./app/game-frontend dev`: run a single app by filter.
 - `pnpm --filter ./app/game-api dev`: run a single service by filter.
 - `pnpm --filter ./app/game-engine dev`: run a single service by filter.
 
 ## Development Checklist (AI)
 
-- After code changes, verify TypeScript type checks (prefer `pnpm -r build` or the package `tsc`).
+- After code changes, verify TypeScript type checks (prefer `pnpm build` or `pnpm typecheck`).
 - When changes require unit tests, run the relevant tests.
 
 ## Build Profiles (Proposal)
 
 - A build profile is a server+scenario pair; scenario selection is required even if a default exists.
 - Server builds should accept a profile (server variant) plus an explicit scenario file input.
-- Recommended pattern: a `tools/build-scripts` runner invoked by pnpm, e.g. `pnpm build:server --profile che --scenario default`.
+- Recommended pattern: `pnpm build:server --profile che --scenario default`.
 - Prefer environment variables for CI/CD (`PROFILE=che SCENARIO=default pnpm build:server`) and a small wrapper script for local usage.
 - Build output stays in `/dist/{profileName}` per profile to keep deployments predictable.
 - Profile selection can target different git branches or specific commits; server operators decide the compatibility baseline.

README.md

@@ -31,11 +31,11 @@
     - `pnpm lint`
     - `pnpm test`
     - `pnpm build`
-    - `pnpm typecheck`: 재귀적으로 `tsc --build` 실행
+    - `pnpm typecheck`: turbo를 통해 전체 패키지 타입 체크 실행
     - `pnpm dev`
 - 서버 빌드
-    - `pnpm build:server -- --profile <server> --scenario <scenario>`
-    - 예: `pnpm build:server -- --profile che --scenario default`
+    - `pnpm build:server --profile <server> --scenario <scenario>`
+    - 예: `pnpm build:server --profile che --scenario default`
 
 ## 빌드 프로파일(예정)
 

docs/architecture/overview.md

@@ -21,8 +21,8 @@ monorepo plan is prepared alongside it.
 ## Current Implementation Notes
 
 - `packages/infra` is live with Prisma/Postgres connectors used by game services.
-- `app/game-engine` implements an in-memory turn daemon with DB flush hooks.
-- `app/game-api` exposes tRPC endpoints for reserved turns, messages, and battle sims.
+- `app/game-engine` implements an in-memory turn daemon with DB flush hooks and Redis control transport.
+- `app/game-api` exposes tRPC endpoints for reserved turns, messages, and battle sims, communicating with the daemon via Redis.
 - Gateway/game frontends are still placeholders (not part of current runtime).
 
 ## Legacy Data Migration Policy

docs/architecture/rewrite-plan.md

@@ -19,6 +19,7 @@ Vue 3 frontends.
 
 - `packages/infra` is live and used by game-api/game-engine services.
 - `app/game-api` and `app/game-engine` have initial implementations (tRPC endpoints, turn daemon loop).
+- Redis transport for turn daemon control is implemented and wired.
 - Frontend apps remain placeholders while backend/runtime stabilizes.
 
 ## Runtime Stack (Planned)

docs/architecture/runtime.md

@@ -82,8 +82,8 @@ Gateway runs a lightweight cron loop (setInterval) that:
 ## Current Implementation Status
 
 - Turn daemon lifecycle + in-memory state live in `app/game-engine` with DB flush hooks.
-- Control queue is in-process only; Redis transport exists on API side but is not wired into the daemon.
-- API server already exposes turn-daemon commands (run/pause/resume/status) via tRPC.
+- Redis transport for daemon control is implemented and wired into the daemon.
+- API server already exposes turn-daemon commands (run/pause/resume/status) via tRPC, communicating via Redis Streams.
 - API server writes reserved turns and messages directly to the DB; daemon focuses on world state/logs.
 
 ## Turn Daemon and API Server Behavior (Outline)

docs/architecture/turn-daemon-lifecycle.md

@@ -12,9 +12,10 @@ from the API server.
 
 ## Current Implementation Status
 
-- The daemon loop handles scheduled runs plus in-process control queue commands
-  (run/pause/resume/shutdown). It does not drain API mutation requests between turns.
-- `getStatus` is supported by API transports but not yet handled by the daemon loop.
+- The daemon loop handles scheduled runs plus Redis-based control queue commands
+  (run/pause/resume/shutdown/getStatus).
+- API mutation requests (troopJoin, vacation, etc.) are drained and handled by the daemon loop between turns.
+- `getStatus` is fully supported and responds via Redis.
 - API server currently writes reserved turns and messages directly to the DB.
 
 ## Responsibilities