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

開始 CR-030 程式面 A/B 批真機驗證：#7 補 metrics 實作（原為假綠）、#8/#9/#12/#15 真機驗證。

CR-030 程式面 A/B 兩批已完成並經真機驗證（2026-10-19），結案。

【驗證範圍】#7／#8／#9／#12／#15 五項（文件面 12 項裁定已於 v1.0 執行）。【結果】五項全數通過。

• #7：原為「文件說做了、程式沒做」之假綠（metrics 從未實作），本輪補 AuthorizationMetricsPort／AuthorizationMetrics／AuthorizeUseCase 呼叫 ＋ 2 條斷言測試。真機：鎖卡授權 DECLINED（respCode 51）、未佔額度，prometheus 出現 cardcore_authorization_declined_total{reason=CARD_STATUS} 1.0。★ 並查 jar(16:05) 後於原始碼(15:52)、HELP 文案為新版 → 確認運行實例確為補後程式（防假綠）。
• #8：REFERRAL 授權 holdAmount=50000（額度確實被佔用），OUTBOX payload decision=REFERRAL。
• #9：繳款 PAY20261019000008 沖正後 usedAmount 0→50000、availableAmount 9662200→9612200（恰減沖正金額）。★ 並實查 publisher／subscriber topic 兩端對齊（cc.payment.payment.reversed），事件真的會被消費。
• #12：cc_card.OUTBOX 同一 aggregateId 跨事件型別 sequenceNo 嚴格遞增（card.issued 1790853218695 → card.token.bound 1790853228817）。
• #15：修正後新 topic 於 Kafka 確實存在（cc.product.parameter.changed／cc.clearing.batch.matched／cc.dispute.case.opened／cc.posting.transaction.posted｜.reversed）。

【殘留 2 項，已如實記載於 CR-030 §3.1.4 與證據 N4 §5，不構成不通過】
(1) #15 修正前之舊 topic 仍並存於 Kafka，待清理；現階段零消費者（CR-029 盤點）故無孤兒消費風險。
(2) #12 sequenceNo 實為 epoch millis，同毫秒碰撞會被消費端以「seq <= MAX」判為亂序而靜默丟棄——即裁定明載之已知限制，正解為「聚合層級持久化序號」，列後續強化項（非本批）。

【證據】docs/08-evidence/N4_CR030_事件流治理驗證_20261019.md；CR-030 升至 v1.1（補 §3.1 驗證矩陣）。

【後續揭露 #A-354，2026-10-19】#9 真機驗證之測試資料收尾——經米粿裁定採「保留」處置：種子帳號 018f2a3b-0000-0000-0000-000000000001 留有驗證用繳款 PAY20261019000008（externalRef=CR030-VERIFY-9，status=REVERSED，amount=50000），副作用 usedAmount 0→50000（沖正重新佔用之正確業務行為，非程式錯誤；須清理的是繳款本身為驗證而造）。已於 ops/local/init/oracle/05-dev-limit-seed.sql 帳戶 001 之 INSERT 前明列：日後重跑任何以該帳號為基準之驗證（含 #9）不得以 used_amount=0 判讀；需乾淨基線時重跑該檔即歸零。證據 docs/08-evidence/N4_CR030_事件流治理驗證_20261019.md §8。※ 該帳號在 SQL 以 HEXTORAW 形式（無連字號大寫）表示，以連字號 UUID 之 grep 找不到——已記於種子檔註解避免再踩。