docs: AGENTS.md, README.md, and architecture documents 업데이트하여 서버+시나리오 프로파일 개념 정립

docs/architecture/overview.md

@@ -28,6 +28,8 @@ monorepo plan is prepared alongside it.
 - PHP engine owns authoritative gameplay state today
 - Scenario and unit pack data are loaded from `legacy/hwe/scenario/`
 - Deterministic RNG is required for gameplay outcomes
+- Build/runtime profiles are server+scenario pairs; scenario selection is required
+  because it drives unit sets and DB settings.
 
 ## Legacy Docs
 

docs/architecture/postgres-schema.md

@@ -11,7 +11,9 @@ fields. Use this as the starting point for Prisma models and migrations.
 - Keep JSONB values as objects (not arrays or scalars).
 - Use partial or expression indexes when a JSONB key becomes a hot filter.
 - If multiple server profiles live in one database, add `server_id` to every
-  table and index it; otherwise, use one database per profile.
+  table and index it; otherwise, use one database per profile. Scenario
+  selection is still required at build/runtime, but does not change the DB
+  partitioning baseline.
 
 ## Meta Policy (Reset)
 

docs/architecture/rewrite-plan.md

@@ -10,8 +10,8 @@ Vue 3 frontends.
 - `/app/gateway-frontend`: gateway UI
 - `/app/gateway-api`: gateway service
 - `/app/game-frontend`: game UI
-- `/app/game-api`: game backend per server profile
-- `/app/game-engine`: turn daemon per server profile
+- `/app/game-api`: game backend per server+scenario profile
+- `/app/game-engine`: turn daemon per server+scenario profile
 - `/tools/build-scripts`: build and deployment scripts
 
 ## Runtime Stack (Planned)
@@ -43,4 +43,5 @@ The shared constraint contract (daemon vs API precheck split) is documented in
 
 ## Profiles (Planned)
 
-- `che`, `kwe`, `pwe`, `twe`, `nya`, `pya`
+- Profiles are server+scenario pairs; scenario selection is required for build/runtime.
+- Server IDs: `che`, `kwe`, `pwe`, `twe`, `nya`, `pya`

docs/architecture/runtime.md

@@ -1,13 +1,14 @@
 # Runtime and Build Profiles
 
-Build outputs should be emitted to `/dist/{serverName}` per profile to keep
-deployments predictable.
+Build outputs should be emitted to `/dist/{profileName}` per profile to keep
+deployments predictable. Profiles are server+scenario pairs, and scenario
+selection is required because it drives unit sets and DB settings.
 
 ## Suggested Build Pattern
 
 - Wrapper script under `tools/build-scripts`
-- `pnpm build:server --profile che`
-- CI-friendly: `PROFILE=che pnpm build:server`
+- `pnpm build:server --profile che --scenario default`
+- CI-friendly: `PROFILE=che SCENARIO=default pnpm build:server`
 
 ## Deterministic RNG Policy
 
@@ -44,7 +45,7 @@ replay while pub/sub keeps live updates simple and low-latency.
 
 ### Operational Notes
 
-- Stream keys should be namespaced per server profile.
+- Stream keys should be namespaced per server+scenario profile.
 - Use bounded stream length (`MAXLEN`) to cap storage.
 - API server should guard against duplicate processing by `requestId`.
 - When the daemon is busy, API queues new mutations to stream and responds
@@ -70,10 +71,10 @@ also supports local ID/password login for users who cannot use Kakao.
 
 - Gateway handles login and owns primary sessions in Redis.
 - Game servers may run different branches; treat Gateway as a central SSO
-  authority that issues session tokens for each server profile.
+  authority that issues session tokens for each server+scenario profile.
 - API servers validate tokens against Redis and accept sessions issued by
   Gateway without re-authentication.
-- Session tokens should be scoped by server profile to avoid cross-server leaks.
+- Session tokens should be scoped by server+scenario profile to avoid cross-server leaks.
 
 ### Operational Notes
 

docs/architecture/turn-daemon-lifecycle.md

@@ -6,7 +6,7 @@ from the API server.
 
 ## Assumptions
 
-- One daemon process per server profile.
+- One daemon process per server+scenario profile.
 - API server is the only ingress for user/admin requests.
 - The daemon is the only component that mutates gameplay state.
 
@@ -111,7 +111,7 @@ Admin controls should toggle `paused`, trigger manual run, and request catch-up.
 
 ```json
 {
-    "profile": "che",
+    "profile": "che:default",
     "state": "idle",
     "running": false,
     "paused": false,