Append Jan 11 2026 session - Live Status & Agent Integration, Redis caching, DEV vs GAME semantics

SESSION_LOG.md

@@ -151,3 +151,54 @@ Status: **Dev container SSH working internally; bastion public access blocked at
 ### Outcome
 Portal is no longer Pterodactyl-shaped.
 It now supports mixed workloads cleanly.
+
+---
+
+## 2026-01-11 — Live Status & Agent Integration
+
+### Summary
+Finalized live server status architecture between:
+- ZPack API
+- zlh-agent
+- Redis
+- Portal UI
+
+This session resolved incorrect / misleading server states and clarified the
+separation between **host health**, **agent availability**, and **service runtime**.
+
+### Key Decisions
+
+#### 1. Status Sources Are Explicit
+- **Agent `/health`**
+  - Authoritative for *host / container availability*
+  - Used for DEV containers and host presence
+- **Agent `/status`**
+  - Authoritative for *game server runtime only*
+  - Idle ≠ Offline (idle means server stopped but host up)
+
+#### 2. DEV vs GAME Semantics
+- **DEV containers**
+  - No runtime process to track
+  - Status = `running` if host online
+- **GAME containers**
+  - Runtime state controlled by agent
+  - Status reflects actual game process
+
+#### 3. Redis Is the Live State Cache
+- Agent poller runs every 5s
+- Redis TTL = 15s
+- UI reads Redis, not agents directly
+- Eventual consistency is acceptable
+
+#### 4. No Push Model (Yet)
+- Agent does not push status
+- API polls agents
+- WebSocket / push deferred until console phase
+
+### Result
+- Portal now reflects correct, real-world state
+- "Offline / Idle / Running" distinctions are accurate
+- Architecture aligns with Pterodactyl-style behavior
+
+### Next Focus
+- Console (read-only output first)