Bug #1396
是由 陳國瑋 於 5 天 前更新
## 問題背景
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。
若公樁數量等於或超過總 slots，`SlotCalculator.calculateSlots()` 會得到私人可用 slots 也會成為 0。
目前 = 0；而目前 `ChargingOrchestrator.startCharge()` 僅在 `slots > 0` 時進行 PRIVATE 排隊檢查，`slots == 0` 反而可能跳過容量檢查並直接 RemoteStart，造成容量配置與執行行為矛盾。
## 修正範圍
1. 在所有會改變 在所有會改變「某 Charging Group 公私樁配置的 的 PUBLIC Connector 建立／更新操作中，先以變更後的資料計算 projected PUBLIC／PRIVATE 數量」的 Connector 數量與總 slots。 建立／更新操作中，先計算變更後的配置結果。
2. 下列任一條件成立時拒絕操作：
- projected PUBLIC 當變更後 `PUBLIC Connector 數量大於總 slots。
- Group 仍有 projected PRIVATE Connector，但 `total slots - projected PUBLIC count <= 0`。 > total slots` 時，拒絕該操作並回傳明確、結構化的錯誤訊息。
3. 驗證必須涵蓋新增 Connector、PUBLIC／PRIVATE 互換，以及 驗證與 Connector 移入或移出 Charging Group。 寫入必須在同一交易中完成，避免驗證通過後被併發更新造成超配。
4. 驗證與 Connector 寫入必須在同一交易中完成，避免併發更新造成超配。
5. 補上執行期防線：PRIVATE Connector 的可用 slots 為 0 時，不得跳過容量限制直接 RemoteStart。
6. 5. 不納入 #1382 driverState／LIFF 顯示調整範圍，另案處理。
## 驗收條件
- 將 Connector 從 PRIVATE 改為 PUBLIC，若變更後公樁超過總 PUBLIC，若變更後公樁數超過 Group 總 slots，API 拒絕且資料維持原值。
- Group 內仍有 PRIVATE Connector 時，若變更後公樁會用完全部總 slots，API 同樣拒絕。
- 建立 PUBLIC Connector、建立或移入 PRIVATE Connector，以及把 Connector 移至另一個 或把 PUBLIC Connector 移入另一個 Group 時，套用相同 projected-state 驗證。 時，套用相同驗證。
- 公樁數量等於總 公樁數量未超過總 slots 且 Group 內沒有任何私樁時，配置可以成立。 時可正常儲存。
- PRIVATE 可用 slots 為 0 時，開始充電不得直接執行 RemoteStart。
- API 回傳明確、結構化的容量配置錯誤，且失敗操作不得留下部分更新。
- 補齊 Service/API 單元測試及對應 E2E regression case。
返回