EMS

問題描述¶

目前刪除 Charge Group 時，API 應先確認是否仍有 Connector 的 chargeGroup 指向該 Group。若直接刪除仍被使用的 Group，可能留下失效關聯，並使私人樁的手動排隊、離峰排程與容量計算出現不一致。

本議題由 #1382 driverState／離峰充電需求釐清過程發現，但屬於獨立的 Charge Group 資料完整性問題，不納入 #1382 範圍。

預期行為¶

1. 收到刪除 Charge Group request 時，先查詢是否仍有任何 Connector 屬於該 Group。
2. 若仍有 Connector：
   • 拒絕刪除，Group 資料保持不變。
   • 回傳明確的 domain error，例如 CHARGE_GROUP_IN_USE。
   • 回覆訊息應讓管理者知道必須先移除或重新指派 Connector；可附帶使用中的 Connector 數量。
3. 若沒有 Connector 使用該 Group，才允許刪除。
4. 不得透過 cascade、設為 null 或其他隱含方式，讓使用中的 Connector 靜默失去 Charge Group。
5. API 驗證與刪除應具備一致性，避免檢查後到刪除前被新增 Connector 關聯的競態。

驗收條件¶

• Given Charge Group 仍被至少一支 Connector 使用，When 呼叫刪除 API，Then 刪除失敗並回 CHARGE_GROUP_IN_USE，Group 與 Connector 關聯均維持原狀。
• Given Charge Group 沒有任何 Connector 使用，When 呼叫刪除 API，Then 刪除成功。
• 補上 service/API regression tests，涵蓋「使用中拒絕」與「未使用可刪除」。
• 更新 EMS E2E catalog，新增或更新 Charge Group 刪除資料完整性案例。

非本議題範圍¶

• #1382 的 driverState、LIFF、離峰 switch 與 WebSocket 行為。
• Connector 更換或移除 Charge Group 時的離峰模式處理規則；如需調整另行確認。