From cf93c28aff4ec6af1643e78e865620961627e623 Mon Sep 17 00:00:00 2001 From: Hide_D Date: Mon, 5 Jan 2026 16:20:20 +0000 Subject: [PATCH] =?UTF-8?q?docs:=20=EC=97=85=EB=8D=B0=EC=9D=B4=ED=8A=B8?= =?UTF-8?q?=EB=90=9C=20=EB=AC=B8=EC=84=9C=20=EB=82=B4=EC=9A=A9=20=EB=B0=98?= =?UTF-8?q?=EC=98=81=20=EB=B0=8F=20Redis=20=ED=86=B5=ED=95=A9=20=EC=84=A4?= =?UTF-8?q?=EB=AA=85=20=EC=B6=94=EA=B0=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- AGENTS.md | 18 +++++++++--------- README.md | 6 +++--- docs/architecture/overview.md | 4 ++-- docs/architecture/rewrite-plan.md | 1 + docs/architecture/runtime.md | 4 ++-- docs/architecture/turn-daemon-lifecycle.md | 7 ++++--- 6 files changed, 21 insertions(+), 19 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index ebb51ca..9fb8b84 100644 --- a/AGENTS.md +++ b/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. diff --git a/README.md b/README.md index b4c2aa2..700a532 100644 --- a/README.md +++ b/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 --scenario ` - - 예: `pnpm build:server -- --profile che --scenario default` + - `pnpm build:server --profile --scenario ` + - 예: `pnpm build:server --profile che --scenario default` ## 빌드 프로파일(예정) diff --git a/docs/architecture/overview.md b/docs/architecture/overview.md index 2642589..a9422a9 100644 --- a/docs/architecture/overview.md +++ b/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 diff --git a/docs/architecture/rewrite-plan.md b/docs/architecture/rewrite-plan.md index cbbb49d..b5a3f64 100644 --- a/docs/architecture/rewrite-plan.md +++ b/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) diff --git a/docs/architecture/runtime.md b/docs/architecture/runtime.md index f0a622c..8fcf9c5 100644 --- a/docs/architecture/runtime.md +++ b/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) diff --git a/docs/architecture/turn-daemon-lifecycle.md b/docs/architecture/turn-daemon-lifecycle.md index 4122562..683ab1a 100644 --- a/docs/architecture/turn-daemon-lifecycle.md +++ b/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