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

docs/b055_technical_spec.md

@@ -7,7 +7,7 @@
 ## 1. 業務流程與通訊機制
 
 ### 1.1 指令下發流程
-1.  **指令生成**：Cloud 後端（管理者或系統觸發）在 `remote_dispense_commands` 表中建立一筆狀態為 `0` (待執行) 的指令。
+1.  **指令生成**：Cloud 後端（管理者）在 `remote_commands` 表中建立一筆類型為 `dispense`、狀態為 `pending` 的指令。
 2.  **心跳通知**：在該機台的 B010 回應中，將 `status` 設為 `85` (reload B055)。
 3.  **機台撈取 (POST)**：機台呼叫 B055 POST API (`/api/app/machine/dispense/{workid}`) 取得詳細出貨參數（貨道 ID、指令 ID）。
 4.  **執行與回報 (PUT)**：機台嘗試出貨後，呼叫 B055 PUT API 回報出貨結果及剩餘庫存。
@@ -17,14 +17,16 @@
 
 ---
 
-## 2. 資料庫結構：`remote_dispense_commands`
+## 2. 指令資料定義：使用全域 `remote_commands`
 
-| 欄位 | 說明 | 備註 |
-|------|------|------|
-| `command_id` | 執行命令 ID | 用於追蹤單次指令 |
-| `slot_no` | 貨道 ID | 指派機台出貨的通道 |
-| `status` | 執行狀態 | 0:待執行, 1:成功, 2:失敗 |
-| `remaining_stock` | 剩餘庫存 | 由機台回報 |
+遠端出貨指令統一存放在 `remote_commands` 表中，B055 的特定參數將存放於 `payload` (JSON) 欄位。
+
+| 欄位 | B055 對應說明 | 備註 |
+|------|--------------|------|
+| `id` | 執行命令 ID | 用於追蹤單次指令 (POST 回傳) |
+| `payload->slot_no` | 貨道 ID | 指派機台出貨的通道 |
+| `status` | 執行狀態 | pending/sent/success/failed |
+| `ttl` | 指令效期 | 預設 60 秒 |
 
 ---
 
@@ -35,21 +37,31 @@
 
 ---
 
-## 4. 待確認事項 (To-be-confirmed)
+## 4. 欄位定義與對照
 
-### 4.1 業務情境 (Scenario)
-1.  **指令發起來源**：確認指令是由後台管理員手動測試發起，還是串接外部線上購買系統產出的取貨指令？
+| B055 欄位 | 資料庫對應 | 說明 |
+|----------|------------|------|
+| `command_id` | `remote_dispense_commands.id` | 指令唯一識別碼 |
+| `slot_no` | `machine_slots.slot_no` | 目標貨道編號 |
 
-### 4.2 失敗處理機制 (Failure Handling)
-2.  **自動退款/告警**：若機台 PUT 回報出貨失敗，雲端是否需要自動發起退款（針對線上訂單）或發送維修告警通知？
+---
 
-### 4.3 指令效期與防重 (TTL & Idempotency)
-3.  **指令效期**：如果指令發出後機台失聯，該指令應在多久後失效 (TTL)？
-4.  **防重複機制**：如何嚴格確保同一個 `command_id` 不會被重複執行兩次？
+## 5. 業務邏輯細節建議
 
-### 4.4 安全性與權限 (Security)
-5.  **指令簽名**：除了 `api_token`，發送出貨指令是否需要額外的加密簽名驗證以防偽造？
-6.  **權限限制**：是否限制僅特定高級管理員可發起此類高風險指令？
+### 5.1 指令效期 (TTL)
+*   **建議設定**：**60 秒 (1 分鐘)**。
+*   **理由**：由於遠端出貨指令由管理員手動發起（通常用於現場故障排除或客訴處理），若機台因網路問題超過一分鐘未拉取指令，該次操作的情境通常已失效，應自動失效以防止後續無預警出貨。
 
-### 4.5 欄位定義
-7.  **URL {workid}**：確認是否對標 `serial_no`。
+### 5.2 失敗處理
+*   **機制**：機台回報出貨失敗時，系統僅需記錄結果並在後台顯示異常狀態。
+*   **處理原則**：考量目前僅供管理員手動發起，**不需執行自動退款**，由管理員依據日誌進行後續手動處理即可。
+
+### 5.3 安全與權限
+*   **驗證機制**：維持 `api_token` 驗證，不需額外的加密簽名。
+*   **權限控制**：建議在 RBAC 權限系統中，限制僅「高級管理員」或「維修主管」具備發起遠端出貨的權限。
+
+---
+
+## 6. 待確認事項 (已結案)
+
+所有關鍵決策已於 2026-03-12 完成確認。