EMS

問題背景¶

Charging Group 的容量設計會先依 contractCapacity / allocatedPower 計算總 slots，再扣除同 Group 的 PUBLIC Connector 數量，剩餘容量才提供 PRIVATE Connector 排程。

目前在新增 Connector、變更 Connector 的 connectorArea，或調整 Connector 所屬 Charging Group 時，未於設定階段驗證變更後的公私樁配置是否仍符合容量限制。

若 PUBLIC Connector 數量超過總 slots，配置本身已超出契約容量；若 PUBLIC Connector 數量剛好等於總 slots、但 Group 內仍有 PRIVATE Connector，私人可用 slots 也會成為 0。

目前 ChargingOrchestrator.startCharge() 僅在 slots > 0 時進行 PRIVATE 排隊檢查，slots == 0 反而可能跳過容量檢查並直接 RemoteStart，造成容量配置與執行行為矛盾。

修正範圍¶

1. 在所有會改變 Charging Group 公私樁配置的 Connector 建立／更新操作中，先以變更後的資料計算 projected PUBLIC／PRIVATE Connector 數量與總 slots。
2. 下列任一條件成立時拒絕操作：
   • projected PUBLIC Connector 數量大於總 slots。
   • Group 仍有 projected PRIVATE Connector，但 total slots - projected PUBLIC count <= 0。
3. 驗證必須涵蓋新增 Connector、PUBLIC／PRIVATE 互換，以及 Connector 移入或移出 Charging Group。
4. 驗證與 Connector 寫入必須在同一交易中完成，避免併發更新造成超配。
5. 補上執行期防線：PRIVATE Connector 的可用 slots 為 0 時，不得跳過容量限制直接 RemoteStart。
6. 不納入 #1382 driverState／LIFF 顯示調整範圍，另案處理。

驗收條件¶

• 將 Connector 從 PRIVATE 改為 PUBLIC，若變更後公樁超過總 slots，API 拒絕且資料維持原值。
• Group 內仍有 PRIVATE Connector 時，若變更後公樁會用完全部總 slots，API 同樣拒絕。
• 建立 PUBLIC Connector、建立或移入 PRIVATE Connector，以及把 Connector 移至另一個 Group 時，套用相同 projected-state 驗證。
• 公樁數量等於總 slots 且 Group 內沒有任何私樁時，配置可以成立。
• PRIVATE 可用 slots 為 0 時，開始充電不得直接執行 RemoteStart。
• API 回傳明確、結構化的容量配置錯誤，且失敗操作不得留下部分更新。
• 補齊 Service/API 單元測試及對應 E2E regression case。