BEAM 信用卡核心現代化（cardcore）

【發現情境】POC-02 點數 真機驗證（2026-10-24，rewards-service:8091＋campaign-service；rewards 169 測 0 失敗）。
通過：2-3 一般回饋（購貨給點/退貨扣回）、2-7 三層查詢、2-8 兌換、2-9 兌換紀錄、2-11 到期（單測）。以下為待處理缺口／差異：

【2-12 先到期先用 — 差異（需 PMO 裁示）】

• 我方 PointsConsumption 僅扣 CUR／AV1（依到期日早到晚），AV2 視為「凍結點數」不可扣；pointsBefore=CUR+AV1（不含 AV2）。
• 實測：兌換扣 AV1(2000→1500)、AV2 不變。
• BRD-004 2-12 預期：同時有 CUR/AV1/AV2 → 優先扣較早到期（＝AV2）。設計 vs 規格衝突。

【2-10 兌換標的處理 — 未實作（需裁示＋實作）】

• 需求：商品連結商品系統、電子券送簡訊平台、哩程產外部檔傳 FTP、抵用金產請款檔。
• 現況：RedeemRequest.targets 僅以 JSON 原樣保存，未見任一外部傳輸整合。

【2-3 sourceTransactionId 語意＋錯誤訊息（可用性／可觀測性）】

• sourceTransactionId 實以 Requests.uuid() 以 UUID 解析（AccrualService:172）；名稱像交易號卻限 UUID，易誤用（本次實測即因此回 400）。
• 且 ValidationException(CC-RWD-4000) 之具體訊息（如「欄位格式錯誤（須為 UUID）」）被吞成通用「請求驗證錯誤」（details 空）——排查困難。建議：handler 改採 exception 訊息，或於 DefaultMessage 保留具體原因。

【2-1 回饋規則 CRUD 不完整】

• 僅 POST /reward-rules（define）；BRD 要求之修改／刪除／查詢端點未見。

【2-2／2-4／2-5／2-6 跨服務邊界】

• 商店群組／不回饋(mcc 排除)／門檻(滿額型)／加倍 由 campaign-service 承載；rewards 只算點數。端到端未單獨 e2e，需 PMO 確認歸屬與驗收方式。

【交付】docs/09-demo/poc-02-points/（overview＋2-1~2-12 詳細動畫）；證據 docs/08-evidence/POC-02_*；poc-flows/POC-02 已標「已驗證（部分）」。