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

【發現情境】POC-14 授權額度更新（讀寫分離）真機驗證（2026-10-24，authorization-service 8092／limit-service 8098／posting 8087；FR SYS-2.1／ISS-2.4）。
架構要求：讀寫分離下以 event + Kafka，交易資料皆 1 秒內同步到 read DB（更新餘額及新增明細）。

【14-1 額度扣減：部分（授權成功，但讀模型無資料可驗餘額）】

• 實測：POST /authorizations 三筆（200,000／300,000／500,000 分＝2,000／3,000／5,000 元）→ 皆 201，
  authNo AUTH000072／073／074，各產生 holdId；但 decision 皆為 REFERRAL（測試卡無額度資料）。
• ⚠️ 未能取得「可用餘額 40,000 元」之實測值：讀模型投影查無資料（見 14-2）。

【14-2 明細查詢：部分／未驗證（投影查無資料）】

• 實測：GET /api/v1/limit-projections/accounts/{accountId}/instruments → 404 CC-PLT-4040，
  log 明載「查無該帳戶之額度投影資料（可能尚無佔用事件）…本查詢非權威，授權請走 limit-service」。
• 程式查證：讀模型機制確實存在——authorization-service 本地 limit_holds 投影（註載「已實作 #A-128，以 authorizationId 去重」）、
  AccountLimitChangedEvent（讀模型為本地投影）、亂序防護（已套用較新序號則略過，不覆寫較新狀態）、
  「該帳戶無資料則如實回 empty（不造假 asOf、不造假 0 筆清單）」。
• ⚠️ 但本次授權後投影仍無資料，無法驗證「餘額 40,000、明細依交易順序排序」；需查 Kafka 事件是否送出／消費（CR-待驗證）。

【14-3 補償機制、14-4 鏈路追蹤：未驗證】

• 14-3 需「Kafka 到 read DB 網路斷線」之演練（5 筆授權後恢復，驗證餘額 30,000 與順序）——本次未做。
• 14-4 需三段日誌（AP／Kafka／Listener）具同一追蹤識別碼——本次未取得。

【實測過程中的兩個重要環境/輸入發現（供後續參考）】

• authorizations 表有檢查約束 channel IN ('POS','EC','ATM','MOBILE','WEB','API')；
  送 X-Channel: POC 會觸發 ORA-02290 → 500 CC-PLT-5000（極易誤判為服務損壞）。改用 POS 後即 201。
• 讀模型投影為非權威，授權應走 limit-service；且投影「無資料時如實回 empty」是刻意設計，不是缺陷。

【交付】證據 docs/08-evidence/POC-14_*（3 份授權 201＋1 份投影 404）；本 POC 之詳細動畫頁待下次續做（本輪預算受限）。