CR-027　事件流（W-2）推廣盤點與排序建議

1. 現況（已完成）

🔧 補充：limit.hold.created.v1（第 4 列）亦已於 #A-128 完成消費端（auth 本地 limit_holds 投影）→ 全鏈路。

2. 兩份「權威清單」不一致（本 CR 之核心）

盤點發現專案內有兩份事件清單，且不一致：

⚠️ 兩份皆自稱權威（SAD-004 為「事件治理」章、SAD-002 為「微服務劃分」章），
惟內容不同：SAD-002 有 party.*／card.card.issued／card.token.bound／posting.balance.changed
等，SAD-004 §5.2 皆無；反之 SAD-004 §5.2 有 dispute.case.opened.v1，SAD-002 §3.9~3.17 則以摘要形式列出。
本 CR 不擅自擇一（見 §5 待裁定 #5）。

3. 生產端就緒度（可線性推進，風險低）

結論：生產端 13 服務皆可做——掛點明確、SDD-006 §4.2 之 payload 已定義、模式已驗證 3 次。
成本主要在每個服務要各建一次 outbox 表 ＋ relay（V?_outbox.sql ＋ 6 個類別），屬複製型工作。

4. 消費端就緒度（真正的難點）

判準：消費端是否已有「該被餵養的表」。沒有的話，貿然建表＝無中生有（CSP-001 §8 B2／假綠風險）。

結論：消費端僅 2～3 條可立即做；其餘需先立讀模型規格（＝先決定「這張表是什麼」），
否則就是為打通而造表——正是客戶硬性要求禁止的「塞框架／mock data」精神。

5. ★ 待裁定（十六項）——動工前必須先定

✅ 本節 12 項已全數裁定（2026-10-01，CR-030）

BEAM PMO 2026-10-01 指示：「以 Best Practice（Payment Industry 20 年金融科技／架構師）直接將這些問題解決」。
→ 已立 CR-030《事件流治理：CR-027 §5 十二項待裁定之架構裁定》，以 4 條業界通則（P1～P4）
為方法論，逐項裁定並載明「理由／業界依據／影響面／可逆性」。本節下表保留為決策歷程。

#	爭點	裁定	執行狀態
5	事件清單權威	(c) SAD-004 §5.2 為唯一權威；SAD-002 §3 降為指標	✅ 文件
6	q_* 語意	廢除 7 個自投影；改立「跨服務投影清單」	✅ 文件
7	declined.v1	不納入事件流；改以 metrics 涵蓋	✅ 文件 ＋ 程式
8	REFERRAL 缺漏	★ approved.v1 語意＝「已佔用額度」；補 decision；發射條件改 holdsLimit()	✅ 程式（真缺陷）
9	UNMATCHED／REVERSED	★ 補發射 ＋ limit 重新佔用（超額風險之真缺陷）	✅ 程式（真缺陷）
10	posted.v1 缺 currency	確認為可選（已執行）＋ 提升為通則（凡涉金額必帶）	✅ 文件（追認）
11	approved.v1 擴充 2 欄	追認（cardNoMasked 為遮罩，符合 PCI）	✅ 文件（追認）
12	sequenceNo 交錯	明訂不變式「同聚合之所有事件型別共用同一序號來源」；修正 card	✅ 文件 ＋ 程式
13	card.status-changed payload	追認以實作為準	✅ 文件（追認）
14	limit.hold.created 補 currency	追認	✅ 文件（追認）
15	主題命名不一致	(a) 對齊文件慣例；修正 product／clearing／dispute／posting	✅ 文件 ＋ 程式
16	事件 vs 同步呼叫	(b)「同步為主、事件為輔」；事件不重做同步已做之寫入	✅ 文件 ＋ 連帶收斂批次 C 範圍

另 4 項留待外部輸入（CR-030 §4.2，不得由開發臆造）：業務文案（通知模板）／
卡組織規範（拒付時限）／聯絡資訊端點／累點規則。

以下為決策歷程原文（保留供追溯）：

✅ #1～#4（hold 事件群）已化解（2026-10-01，CR-028）——無需 BEAM PMO 裁定：
經取三項客觀證據（authorization.hold.* 全庫程式碼零引用／其 payload 與 limit.hold.created.v1
逐欄相同／hold 之權威在 CC_LIM.LIMIT_HOLDS），確認為「同一事實兩個生產者」：
(#1) 廢除 authorization.hold.*，hold 事件一律由 limit 發布；
(#2／#3) authorization-service 同時訂閱 limit.hold.created.v1 與 limit.hold.released.v1；
(#4) limit.hold.created.v1 補 authorizationId 為可選欄位（不升版）。
程式碼零影響；已執行 6 份文件之同步修訂（詳 CR-028 §4）。
→ 批次 B 之規格障礙已解除（藍圖見 CR-028 §6）。

下列原表保留作為決策歷程（爭點與選項），現況以本 blockquote 為準。

★ 附註（#A-131 根因更正，2026-10-01）：#A-131 原記「clearing 之端到端受阻於服務間 ACL」，
經複查更正——本機 ops/local/sso.env 為 CARDCORE_SECURITY_ENABLED=true（SSO 開啟），
故未帶權杖即回 401 CC-PLT-4010（未認證）；ACL 之拒絕碼為 403 CC-PLT-4030，二者不同。
以合法使用者權杖（demo.csr／client cardcore-services，azp 非 cc-* → 不受服務間 ACL 管制）
重跑即 201、outbox 落列、主題建立。→ 非阻塞，clearing 已於本批完成驗證。

| 16 | ★ 事件 vs 同步呼叫之重複（CR-029 批次 C 盤點發現，2026-10-01） | 三條消費邊所描述的行為已由既有同步呼叫完成：① authorization.approved.v1 → limit（佔用額度）vs AuthorizeUseCase 同步呼叫 limit 佔用；② payment.payment.posted.v1 → posting（繳款入帳）vs payment 同步呼叫 posting 入帳；③ posting.transaction.posted.v1 → statement（帳務事件）vs statement 結帳時同步查詢 posting。兩者並存必然重複套用（重複佔用／重複入帳／兩套真相） | (a) 事件為唯一路徑——移除同步呼叫（授權需即時佔用，不建議）
(b) 同步為主、事件為輔——事件僅供投影／通知，不重做同步已做之寫入；SAD-004 §5.2 之「用途」欄須改寫
(c) 逐案裁定 | (b)——① 授權／繳款之即時性使同步不可去；② 事件驅動之價值在跨服務投影與通知，重做寫入無增益且引入重複風險；③ (b) 下批次 C 始可大規模推進（C-1／C-2 即採此）。此為批次 C 之最大前提，請優先裁定（詳 CR-029 §6／§8.1） |

6. 建議排序（依「可驗證性」而非「事件編號」）

批次 A｜無爭議、可立即做（不依賴 §5 任何裁定）

批次 A 三項全數完成（A-1 #A-124／A-2 #A-125／A-3 #A-126，2026-10-01）。
實作中共發現 4 項契約缺口（§5 #9～#12），已一併登錄。
下一步：批次 B（hold 群）動工前必須先裁定 §5 #1～#4。

批次 B｜✅ 已完成（2026-10-01，#A-128）

limit.hold.created.v1／limit.hold.released.v1 → auth 本地 limit_holds 投影
（V2 已載明之第三個「無餵養者」讀模型）。
真機：正常路徑 → 本地 8 → 9（id＝權威 holdId）；stand-in 去重負樣本 → 本地仍 1 列。
★ 併修正 JdbcLimitPort.availableLimit 之超額風險缺陷。

批次 A-4｜生產端補齊（續）——BEAM PMO 2026-10-01 指示「先補批次 A 剩下的生產端」

範圍：批次 A-3 只補了「已接 outbox 之服務」（card／limit）。本批補其餘服務之生產端。

掃描結果（2026-10-01 實測）：

待補事件清單（依 SAD-002 §3）：

批次 A-4 進度小結（2026-10-01）：payload 已定義者（8 項）全數完成——
posting×2（#A-134）／statement（#A-135）／rewards×2（#A-136）／clearing（#A-131＋補驗）／
dispute（#A-133）／merchant（#A-137）／notification（#A-138）；
另加 product（#A-130）＝ 9 項事件／7 服務。
餘 12 項皆為「payload 未定義」（需先立契約）＋ dispute.case.closed.v1（待裁定）。

每個服務之工作量（複製型）：V?_outbox.sql ＋ OutboxPort ＋ <X>EventFactory ＋
JdbcOutboxRepository ＋ {KafkaEventPublisher, OutboxRelayConfig, OutboxRelayScheduler} ＋
掛點（同交易寫 outbox）＋ @EnableScheduling ＋ application.yml 值序列化改 StringSerializer ＋ 單測 ＋ 真機。

⚠️ 順序建議：先做 payload 已定義者（免立規格）；limit.special-limit.set.v1 最後做
——它缺的不只是事件，是整個 SPECIAL 調整功能（SCS-002 §10 #2），屬功能開發而非事件推廣。

⚠️ 與 §7「不建議一次補完生產端」之張力（誠實揭露）：§7 之顧慮是「有人發、沒人收」。
BEAM PMO 2026-10-01 裁定「先補生產端，再批次 C」——本 CR 依此執行，但每一批仍須真機驗證
（outbox 落列 ＋ relay 發布 ＋ 主題建立），並在規格如實標記「目前無消費者」，避免誤認為已全鏈路。

批次 C｜消費端 → ★ 已立計劃（CR-029）

2026-10-01 更新：本批之盤點與分批計畫已獨立為 CR-029
（《事件流（W-2）批次 C：消費端盤點與讀模型設計建議》）——原因：本批之障礙不是技術，
而是**「目標讀模型／行為尚未被規格定義」**，需逐條判定而非照單全做。

CR-029 之結論（摘要）：

• SAD-004 §5.2 之 22 條消費邊 ＋ SAD-002 §3 獨有 3 條，逐條判定「語意來源／目標模型／payload／同步冗餘」。
• SAD-003 §4.1 之 7 個 q_* 全部是「自投影」（來源事件與存放服務同一）→ 不在批次 C 之範圍（屬 §5 #6）。
• 僅 2 條可立即動工（C-1／C-2：payment.posted／statement.issued → notification）
  ——其語意來源為既有種子模板（PAYMENT_RECEIVED／STATEMENT_ISSUED），非臆造。
• ★ 揭露架構性問題：3 條消費邊所描述的行為已由既有同步呼叫完成
  （auth→limit 佔用／payment→posting 入帳／statement→posting 查詢）→ 並存即重複套用，
  須先裁定「事件是唯一路徑，抑或同步為主、事件僅供投影／通知」。
• 其餘分為 C-3（payload 缺口）／C-4（冗餘同步路徑）／C-5（語意未定義）／
  C-6（無模板）／C-7（範圍大）／C-8（待生產端）／C-9（清單權威未定）。

已完成（#A-141）：C-1／C-2——payment.payment.posted.v1 → notification（PAYMENT_RECEIVED）、
statement.statement.issued.v1 → notification（STATEMENT_ISSUED）；真機驗證通過。
★ 前置契約變更：兩事件 payload 原缺 currency 而模板需要 → 依 SAD-004 §5.3 補為可選（不升版）。

已完成（#A-143）：C-5 之首項——party 之卡片狀態投影（card.card.status-changed.v1 → CC_PARTY.card_status_caches；
讀取端點 GET /api/v1/accounts/{accountId}/cards）。★ 架構上之唯一解：card-service 之 ACL 只允許 cc-authorization-service
→ party 無法同步取得卡片狀態 → 事件投影是唯一途徑。真機驗證 8 項通過（含兩負樣本）。
詳 CR-031（v1.1）／SCS-004 §7.5。⚠️ C-5 其餘條目仍待逐條立讀模型規格。

裁定暫緩（#A-143）：C-7（參數快取）——實測 9 個可呼叫 product 之服務全部沒有參數快取，
且參數化自載「已登記為後續項」→ 無快取可失效 ＝ 建監聽器即假綠。設計已立（CR-031 §3），
參數化一落地即 drop-in。★ 併更正 SAD-004 §5.2：該事件之消費者「全體」實為「可呼叫 product 之 9 服務」（ACL 所限）。

原載之範圍（保留供對照）：posting.transaction.posted.v1（statement／rewards／limit 之跨服務投影）、
statement.statement.issued.v1（payment）、installment.plan.created.v1（limit）、
clearing.batch.matched.v1、dispute.case.opened.v1、rewards.points.*、product.parameter.changed.v1。

批次 D｜暫緩

notification.sent.v1（發送通道為真阻塞，GOV-006 §3.D）；report.job.completed.v1／migration.job.completed.v1（無消費者）。

7. 明確不建議做的事（避免假綠）

1. 不要為了「打通」而新建沒有語意來源的表——例如為 dispute.case.opened.v1 在 posting 造一張表。先有規格、才有表（GOV-003 條件 9）。
2. 不要實作 SAD-003 §4.1 的 q_* 自投影（除非 #6 裁定為跨服務投影）——會與權威表並存成兩套真相。
3. 不要一次補完 13 個生產端再回頭做消費端——那會產出 13 個「有人發、沒人收」的事件（Kafka 主題堆積、無人驗證）。建議生產＋消費成對交付（如批次 A-1）。
4. 不要動 REFERRAL 的行為（§5 #8）——待裁定。

8. 請求裁定事項（給 BEAM PMO）

1. §5 #1～#4（hold 事件群）：請擇一；建議 #1(a)＋#2(a)＋#3(併)＋#4(b)。
2. §5 #5（事件清單權威）：建議 (c) 合併為單一清單。
3. §5 #6（q_* 語意）：建議改寫為跨服務投影，否則廢除。
4. §5 #7（declined.v1）：建議 (b) 不納入（除非客戶要求拒絕率即時看板）。
5. §5 #8（REFERRAL）：建議 (b)。
6. 是否同意「先做批次 A-1（payment.payment.posted.v1 生產＋消費）」——該條不依賴任何裁定。
7. §5 #15（Kafka 主題命名不一致）：建議 (a) 對齊文件慣例——4 服務各改 1 個常數
   （product／clearing／dispute／posting），主題由「多一層重複」改為文件所示之形狀；
   現階段零消費者，成本極低。⚠️ 本批已依 (a) 實作 4 個新服務，故新舊目前不一致。
8. ★ §5 #16（事件 vs 同步呼叫之重複）—— 請【優先】裁定：建議 (b)「同步為主、事件為輔」——事件僅供投影／通知，不重做同步已做之寫入；SAD-004 §5.2 之「用途」欄須改寫以排除「重做寫入」之語意。理由：① 授權／繳款之即時性使同步不可去；② 事件驅動之價值在跨服務投影與通知，重做寫入無增益且引入重複套用風險；③ (b) 下批次 C 始可大規模推進（C-1／C-2 即採此）。詳 CR-029 §6。
9. §5 #5（清單權威）與 #6（q_* 語意）—— 請一併裁定：二者直接決定批次 C 之範圍（#5 決定「哪些消費邊存在」；#6 決定「7 個自投影是否要做」）。詳 CR-029 §3／§8.5。
10. §5 #10 之追認：CR-029 已依建議 (b) 為 payment.posted.v1 及 statement.issued.v1 補可選 currency（不升版），請追認或指示改為必填／升版。
11. CR-029 §5 C-6（無模板之通知）：rewards.points.*／dispute.case.opened 之通知是否要做？若要做，模板（業務文案）由誰提供？（不應由開發自行編寫）

9. 修訂記錄