[REFACTOR] 實作側邊欄與儀表板多語系化，修復 UI 位移與樣式優化

docs/b010_technical_spec.md

@@ -24,7 +24,7 @@ B010 是 Cloud 向機台下達遠端指令（如：開鎖、重啟、改庫存
 ## 2. 執行面挑戰：高併發與效能 (Performance)
 
 ### 2.1 寫入瓶頸分析
-*   **數據規模**：10,000 台機台，每 5 秒一個心跳，全站 QPS 約 2,000。
+*   **數據規模**：10,000 台機台，每 10 秒一個心跳，全站 QPS 約 1,000。
 *   **DB 壓力**：直接同步寫入 MySQL `machines` 與 `machine_logs` 將導致磁碟 I/O 鎖定。
 
 ### 2.2 解決策略 (Redis 緩衝)
@@ -32,58 +32,34 @@ B010 是 Cloud 向機台下達遠端指令（如：開鎖、重啟、改庫存
     *   **最後在線時間**、**溫度**、**門禁狀態**、**頁面碼** 等動態數據優先存入 **Redis**。
     *   **批量更新 (Lazy Update)**：每 1~5 分鐘由後台任務將 Redis 數據批量寫回 MySQL `machines` 表。
 *   **日誌優化**：
-    *   正常的心跳資料不逐筆寫入 `machine_logs`。
-    *   僅在**狀態變更**（如：門被打開、溫度過高、軟體報錯）時，才觸發資料庫日誌記錄。
+    *   **正常心跳不寫入資料庫日誌**，僅在**狀態變更**（如：門被打開、溫度過高、軟體報錯）時，才觸發資料庫日誌記錄。
 
 ---
 
-## 3. 資料庫結構擴充 (Schema Gap)
-
-必須對原有的 `machines` 表進行欄位擴充，以承載 B010 的回傳值：
-
-| 新增欄位 | 類型 | 說明 |
-|----------|------|------|
-| `serial_no` | VARCHAR(50) UNIQUE | 機台序號 (API `machine`) |
-| `model` | VARCHAR(50) | 機台型號 (API `M_Stus`) |
-| `current_page` | TINYINT | 當前頁面代碼 (API `M_Stus2`) |
-| `door_status` | VARCHAR(10) | 門禁狀態 (`open`/`closed`) |
-| `api_token` | VARCHAR(100) | 獨立安全憑證 (取代共用 Key) |
-
----
-
-## 4. 安全性與驗證策略 (Security)
+## 5. 安全性與驗證策略 (Security)
 
 *   **API Key 遷移**：從目前全系統硬編碼的共用 Key，逐步遷移至每台機台專屬的 `api_token`。
+*   **驗證方式**：機台端需在 Header 帶入 `Authorization: Bearer <api_token>` 進行身份驗證。
 *   **實裝方式**：
     *   後台管理介面新增「核發機台 Token」功能。
     *   建立專屬 `IotAuthMiddleware`，驗證請求中的 Token 與 `machines` 表是否匹配。
 
 ---
 
-## 5. 離線與告警機制 (Heartbeat Logic)
+## 6. 離線與告警機制 (Heartbeat Logic)
 
-*   **在線判定**：心跳超時（建議超過 60 秒）即在 UI 將機台顯示為「離線」。
-*   **自動維護**：排程 Job 定期掃描 `machines.last_heartbeat_at`，對長期失聯的機台發出系統告警。
+*   **在線判定**：心跳超時超過 **30 秒** 即在 UI 將機台顯示為「離線」。
+*   **告警機制**：機台斷線時，系統需即時產出**警示或推播通知**給相關人員。
+*   **自動維護**：排程 Job 定期掃描 `machines.last_heartbeat_at`，處理長期失聯機台。
 
 ---
 
-## 6. 待確認事項 (To-be-confirmed)
+## 7. 業務邏輯細節 (Fine-grained Logic)
 
-### 6.1 指令下發與回應 (Command Flow)
-1.  **指令優先順序**：當後台同時有多個指令待執行 (如：改庫存 + 重啟) 時，應如何定義優先權？
-2.  **執行狀態回饋**：機台收到心跳指令後的執行結果確認，應採「被動判定」(機台下次心跳狀態正確則視為成功) 還是「主動回報」(機台另呼叫 API)？
+*   **指令成功判定**：採「**被動判定**」。機台收到指令後，若在其後的 B010 心跳中回報狀態正確（如：頁面碼已變更），即視為指令執行成功。
 
-### 6.2 效能與日誌策略 (Performance & Logs)
-3.  **Redis 更新頻率**：即時狀態從 Redis 批量同步至 MySQL 的建議時間間隔 (目前暫估 1~5 分鐘)。
-4.  **心跳日誌級別**：是否確認「正常心跳」不寫入資料庫日誌，僅記錄「異常/變更」事件？
+---
 
-### 6.3 在線/離線判定 (Presence)
-5.  **離線超時定義**：預計多久未收心跳判定為離線？(建議 30~60 秒)。
-6.  **斷線告警機制**：機台斷線時，是否需即時產出系統警示或推播給相關人員？
+## 8. 待確認事項 (已結案)
 
-### 6.4 安全性驗證 (Auth)
-7.  **Token 傳遞方式**：將 API Key 遷移至專屬 Token 時，機台端是否能配合在 Header (`Authorization: Bearer <token>`) 帶入，或必須保留在 JSON Payload 中？
-
-### 6.5 欄位細節 (Field Details)
-8.  **URL {workid} 定義**：URL 中的 `{workid}` 應對應為 `serial_no` (機台序號) 還是資料庫自增 `id`？
-9.  **M_Stus2 告警觸發**：20 多種頁面狀態碼中，哪些特定的錯誤代碼需要在管理後台觸發即時紅字警示？
+目前已根據 2026-03-12 的討論完成所有關鍵決策。