CR-046　行銷活動引擎 campaign-service 新建 ＋ BR-16 載體抽象（同批上線）

項目	內容
文件編號	CR-046
版本	3.6
狀態	核心鏈路實作完成並經真機 E2E 驗證（32/32）；未宣稱全部完成——剩三項非本地可自主：① 三載體跨 JVM 對照（環境限制）② R-1b planCode 來源（card／product 權益選擇）③ R-2 生日月（客戶主檔）。另 B2-6 之 clearing 對映仍待外部資料／裁定。★ 2026-10-17 CR-049 修正線格式與回沖業務日後，campaign → rewards 全鏈路首度閉環（GOV-003 Coding Gate：無 SCS 不寫程式）
提出日期	2026-10-16
提出者	開發團隊（WorkBuddy AI）
觸發	BEAM PMO 2026-10-16 指示：① campaign-service 是全新服務「必須排入完成」；② BR-16 載體抽象「可單獨立 CR 分期，但必須跟活動引擎同批上線，我們要克服這一點」
需求依據	BRD-005（客戶提供之台灣信用卡行銷活動 BRD＋Business Spec v1.3）——BR-01～16 全 16 條
規格依據	SCS-026 v2.0（行銷活動 Campaign 模型，2026-10-16 依 BRD 全面改寫）、SDD-001 §3、SDD-005、SDD-006、SCS-005/SCS-006/SCS-010（計算權威服務）
影響模組	新增 campaign-service；SCS-026 核定之範圍；BR-16 波次另動 card-service 及全服務交易鍵（見 §4）

---

1. 背景與裁定

CR-045（參數極大化三位一體）D3 之「行銷活動實體與規則擁有者」長期停在「待客戶政策」。
2026-10-16 客戶 BRD（BRD-005）已到，政策不再是阻塞；
我據以完成 SCS-026 v2.0 設計（BR-01 參數化要素 6 欄 → 30 欄完整契約，
覆蓋 BR-01～16，十個驗算範例列為自動化驗收基準）。

BEAM PMO 進一步裁定兩條硬性範圍要求：

1. campaign-service 必須完成（新建模組、Flyway baseline、契約），不接受「僅規格」。
2. BR-16 載體抽象雖可分期設計，但必須與活動引擎同一批上線——
   即不接受「活動引擎先上、載體改造以後再說」。

⭐ 為何這兩件必須同批（技術理由，非偏好）：活動引擎的上限截斷、歸戶合併、
錄取名額、支付路徑認定四項參數全部以交易載體的最小識別為粒度。
若載體仍只有 card_no（僅實體卡），則 BRD 的「虛擬卡號／Token 同構回饋」
（AC 11）、「CUBE 支付路徑分級」（AC 8）在資料層就無法表達，
會變成「引擎上了但關鍵參數填不進去」的假完成。
為避免此風險，本 CR 採單一交付列車（release train）。

---

2. 交付範圍（單一列車、三節車廂）

車廂 A：campaign-service 新建（BR-01～14、BR-15）

步驟	產出	驗證判準
A1	spec/services.yaml 增列 campaign-service，跑 gen_service_skeleton.py → --check 25→26 模組、缺漏 0	骨架掃描 0 命中
A2	Flyway baseline（CC_CPG.* 八表，依 SCS-026 §5）	validate_sql 0 違規
A3	契約：改 gen_openapi.py 之 campaign 區塊 → 重生 contracts/openapi/campaign-service.yaml	端點數增加、verify_contract_dto 0 不符
A4	錯誤碼經 gen_error_codes.py 補編 CC-CAM-*（SDD-006 §3.4 同輪更新）	產生器 0 錯誤
A5	DDD 四層實作：領域→埠→應用→基礎設施/介面	編譯通過
A6	真機整合測試（Testcontainers 真 Oracle）＋ BRD §15 十個驗算範例逐例自動化	全綠
A7	更新 SAD-004 §5.2 事件清單、GOV-004 追溯矩陣	追溯完整

車廂 B：BR-16 載體抽象（同批上線）

步驟	產出	驗證判準
B1	card-service 新增 INSTRUMENT 主檔（instrument_id PK；type ∈ {PHYSICAL, VIRTUAL, TOKEN}；card_no 降為唯一索引)	真 Oracle DDL 實測
B2	全服務交易最小鍵 card_no → instrument_id（DTO/DDL/事件 payload）	scan_* 0 命中、編譯通過
B3	相容策略：既有 CRD_CARD 等以視圖對接，不重寫舊程式；card_no 保留為對外欄位	舊測試全綠（不回歸）
B4	真機驗證：同一帳戶以實體卡/虛擬卡/Token 三載體同額交易，回饋一致（AC 11）	三路徑結果相同
B5	事件 payload 新版 instrument_id 為必填、card_no 改為衍生（含版本註記）	契約向後相容

⚠️ B 節是本 CR 之主要風險與工期來源。BEAM PMO 要求同批，我們以「主檔新增＋視圖對接」
把重寫降到最低；但仍須逐服務驗證。若 B 節在 A 節完成後發現不可行，必須立刻回報，
不得默默拆分上線（此為鐵則：不得為「打通」而製造假完成）。

車廂 C：BR-13/BR-14 介接（P0，設計先行）

BR-13 支付路徑認定器與 BR-14 通路 Adapter Registry 需規格先行（BRD 附錄 B 行動 6/9 未結），
本 CR 只建立規則表驅動的骨架與主檔，實際外部檔介接另立議題。

---

3. 不做（明列邊界，避免範圍蔓延）

不做	原因
計算權威（點數餘額、利率、年費）移到 campaign-service	CR-045 D3 治理原則：計算權威留 rewards／pricing／limit
BR-16 的舊欄位刪除	相容策略要求 card_no 保留；刪除須另立 CR 並評估交易歷史
BRD 遺留假設 A1/A4/A5/A6/A7 的內容補齊	屬客戶輸入，非我方可臆造
信貸側新產品上線	BR-15 只做引擎；產品核可屬業務流程
卡片級可用額度查詢	屬 GOV-006 2.4.4，另立 CR

---

4. 任務追蹤清單

ID	任務	依賴	狀態
C-0	BEAM PMO 核定 SCS-026 v2.0	—	⬜ 阻塞（等 BEAM PMO）
C-1	A1 spec/services.yaml 增列 ＋ 骨架重生 ＋ --check	C-0	⬜
C-2	A2 Flyway baseline CC_CPG.*	C-1	⬜
C-3	A3/A4 契約與錯誤碼（改產生器→重生→再實測）	C-1	⬜
C-4	A5 DDD 四層實作	C-2、C-3	⬜
C-5	A6 真機整合測試 ＋ BRD 十範例自動化	C-4	⬜
C-6	B1 INSTRUMENT 主檔	C-1	⬜
C-7	B2 全服務交易鍵升級 instrument_id	C-6	⬜
C-8	B3 相容視圖 ＋ B4 三載體真機驗證（AC 11）	C-7	⬜
C-9	B5 事件 payload 向後相容	C-7	⬜
C-10	A7 文件批（SAD-004／GOV-004／HANDOVER／GOV-006）	C-5、C-8、C-9	⬜
C-11	單一交付列車上線前驗收（A＋B＋C 全綠才算完成）	C-10	⬜

⚠️ 同批鐵則：C-11 未完成前，不得宣稱 campaign-service 已上線。
若 B 節受阻，回報選項而非自行拆分。

---

4.1 B2 批次計劃（2026-10-16 盤點；card_no／cardNo 波及面）

B2 為本 CR 之主要工期來源。盤點結果：card_no／cardNo 遍佈
authorization／card／posting／limit／rewards／pricing／statement／clearing／dispute／merchant
等服務之 domain model、port、DTO、事件 payload 與 DDL。
依 TRP-003 慣例「每批次 3～5 個服務」，分六批推進，每批可獨立驗證與回滾。

批次	範圍	為何此順序	驗證
B2-1	card-service：INSTRUMENT 主檔 ＋ 三載體註冊／查詢／狀態轉換 ＋ 相容視圖	🟡 部分完成——DDL 與 Java 主幹已立；完整 AC 11／三載體端到端與相容視圖驗收仍未結案	本批 compile／測試／SQL 通過；B4 另驗
B2-2	authorization-service：Authorization／CardSnapshot／StandInCardPort／RemoteCardPort／AuthorizeRequest／AuthEventFactory	授權為交易進入點，其鍵語意決定下游全部事件	真機整合測試＋舊測試全綠
B2-3	posting-service：Transaction／Balance 之交易鍵 ＋ 入帳事件 payload	入帳為交易之權威落點，須緊接授權	真機＋分錄不變
B2-4	limit-service／rewards-service：額度佔用與點數累積之鍵	兩者皆為「以卡為單位累計」之消費端	真機＋累計值不變
B2-5	pricing-service／statement-service：費率套用與帳單列示之鍵	帳單為對外可見面，最後動	真機＋帳單金額不變
B2-6	clearing／dispute／merchant 及其餘 ＋ 事件 payload 全面改版（instrument_id 必填、card_no 降為衍生）	收尾與事件契約統一	契約↔DTO 0 不符、全庫掃描 0 命中

🔵 2026-10-16 狀態更新：B2-6 之「事件 payload 全面改版」已完成
（授權事件補 instrumentId；posting→statement 接線，詳 §4.2.2）；
dispute／merchant 經盤點無 card 維度（§4.2.1）；clearing 待裁定（§4.2.3）。

每批次之固定關卡（不得跳過）：

1. 該服務 compileJava ＋ 既有測試全綠（證明未回歸）；
2. 真機整合測試（Testcontainers 真 Oracle）證明新鍵可用；
3. scan_scaffold／scan_mockdata／scan_faketest 各 0 命中；
4. verify_contract_dto.py 0 不符；
5. 更新 GOV-004 追溯矩陣。

⚠️ 回報義務：任一批次若遇「舊欄位無法以視圖對接」（例如下游以 card_no 為複合主鍵之一部分，
無法以單表視圖覆蓋），必須停下回報選項，不得自行改為「先上線再補」——
此即本 CR §4 之同批鐵則。

---

4.2 B2-6 動工前盤點：原始清單與實況之偏差（2026-10-16 查證）

★ 依本專案鐵則「逐條打通 ≠ 逐條照做——先盤點，再動工」，
B2-6 動工前先盤點三服務之實際波及面，結果與 §4.1 原始清單有偏差，
誠實揭露如下（未查證即照清單施工，將做出無語意之改動）。

4.2.1 dispute／merchant 經查證無 card 維度 → B2-6 交易鍵升級對此二者 N/A

以真實程式碼與 DDL 盤點（非臆測）：

服務	領域模型之識別鍵	事件 payload	結論
dispute-service	accountId／transactionId／org（Dispute）	disputeId／accountId／transactionId／disputeType／amount	不含 card_no／cardId／instrument_id——爭議以「案件＋帳戶＋原始交易」為識別
merchant-service	merchantId（業務代碼，非 UUID）／org（MerchantSettlement）	settlementId／merchantId／三種金額	不含 card 維度——請款以「特店＋批次」為識別

→ 二者不存在「交易鍵 card_no → instrument_id」之升級標的。
§4.1 將其列入，係依「服務別」推論而非**依「欄位實況」**盤點所致。
不為「打通」而製造無語意之改動（本 CR 鐵則）。

4.2.2 「事件 payload 全面改版」之真實剩量（已完成，2026-10-16）

盤點發現真正未竟之處不在前述三服務，而在跨服務資料契約：

#	斷點	實況	處置
①	authorization-service 事件 payload	Authorization 聚合已有 instrumentId（B2-2），但 AuthEventFactory 只發 cardId＋cardNoMasked，未發 instrumentId	補 instrumentId（依 SAD-004 §5.3 新增可選欄位不升 v2）
②	posting → statement 查詢鍵	TransactionView 未帶 instrumentId → PostingQueryPort.TxnSnapshot 無該欄 → StatementItem 組裝處寫死 null → STATEMENT_LINES.INSTRUMENT_ID（B2-5 已建）恆為 null	全鏈接線：TransactionView→PostingViewAssembler→TxnSnapshot→PostingServiceClient→StatementGenerationService
③	契約	上述 ② 之 TransactionView 亦須入約	改 gen_openapi.py → 重生（100 端點 0 錯誤）

★★ ② 即 V4__instrument_key.sql 所註「值待 B2-6 事件 payload 帶入」之真實斷點——
屬「有欄位、沒有值」之假完成風險，本次補上後始為真閉環。

語意界線（不臆造）：升級前之歷史交易其 instrumentId 維持 null——
系統內無明文卡號可反推（CR-006 #2），不得回填猜測值。

4.2.3 ✅ clearing-service：遮罩格式爭議已裁定——回到 PiiMasker 標準，且維持顯示欄、不升級為鍵

BEAM PMO 本輪補充裁定：若對 9999-xxxx-xxxx-xx99 與內部遮罩格式有爭議，回到現行 PiiMasker 標準。因此：

• 內部卡片／API／事件／讀模型之遮罩，權威仍是 PiiMasker.maskCardNumber()：前 6 後 4、*、無分隔符；實測 4111111111111111 → 411111******1111。
• 9999-xxxx-xxxx-xx99 不作為本 CR 的全系統替換標準；不修改 PiiMasker、不改既有測試、不改既有內部契約。
• 若外部清算檔日後確實要求該格式，僅能作為外部檔專用顯示欄位／轉換規格另立 CR，不得反向污染內部 PiiMasker 標準。

裁定（有憑據，非偏好）：clearing_items.card_no_masked 維持為顯示用欄位，不升級為 instrument_id。理由：

#	理由	依據
①	遮罩值依設計即不得用於比對	PiiMasker 類別 javadoc 明載：「產出之遮罩字串不得用於儲存、比對或作為識別鍵——比對請用雜湊（CardNumber.hash()），儲存請用密文」（SAD-005 §5、SAD-003 DP-06）
②	前 4 ＋ 後 2 非唯一	同一 BIN（前 4）＋同一末 2 碼之卡片甚多，以此對映將大量碰撞；以之作為對映鍵屬資料錯誤風險
③	本服務無匹配來源	欲「遮罩 → 載體」對映須有比對來源；本服務無明文卡號、亦無卡號雜湊（外部清算檔僅帶遮罩值）

→ 若日後需對映，應以卡號雜湊（card_no_hash）為鍵，且須先確認外部清算檔是否提供雜湊或可對映之欄位
→ 屬收單資料源之真阻塞（§5 #1），另立 CR 處理，本 CR 不動。

✅ 遮罩標準已裁定：內部回到 PiiMasker；9999-xxxx-xxxx-xx99 不作全系統標準。既有內部遮罩契約、測試與 PiiMasker 均不改；外部清算檔若另有格式要求，另立外部檔轉換 CR。

4.2.4 🔴 card-service：B1 僅建 DDL，Instrument 之 Java 層全無（「有表、沒程式」缺口）

§4.1 之 B2-1 原標「已完成（B1）」並載明範圍含「三載體 CRUD」。經盤點：

項目	實況
V9__instrument.sql（DDL）	✅ 已建（instruments 表 ＋ 三唯一索引 ＋ v_instrument_legacy_card 相容視圖）
Instrument 領域模型	✅ 已補（PHYSICAL／VIRTUAL／TOKEN；shape 不變式；RETIRED 終態）
InstrumentRepository 埠／JDBC	✅ 已補（真 Oracle JDBC；自然鍵查重；RAW(16)；樂觀鎖狀態更新）
三載體 CRUD 服務／Controller	🟡 已補註冊／查詢／狀態轉換；尚非完整通用 CRUD（不提供刪除，RETIRED 為終態）
契約（card-service.yaml）	✅ 已補 3 schema／4 endpoint；由 gen_openapi.py 產生

影響（連鎖）：

1. card.card.status-changed.v1 之生產端 CardStatusEventFactory 無從取得 instrumentId
   （Card 聚合僅有 id()，未攜載體識別）→ 事件發不出載體鍵；
2. 承上，party-service 之 card_status_caches 投影即便加欄也永遠填不到值；
3. campaign-service 之「上限截斷／歸戶合併／錄取名額／支付路徑認定」四參數以載體為粒度 → 地基未立。

→ 本缺口為 BR-16 之地基，優先於其餘服務之鍵升級。本次已補 card-service Java 地基；事件接線與下游投影依 §4.2.5 續作。

4.2.5 本次接續之範圍（「及其餘」之正確順序）

原 §4.1 之「及其餘」未明列服務。依依賴順序更正為：

順序	標的	為何此順序
①	card-service Instrument Java 層（§4.2.4）	生產端地基——無此則下游全部「有欄沒值」
②	card-service CardStatusEventFactory 補發 instrumentId	承①，事件線格式
③	party-service：CardStatusSnapshot／Listener／V4 DDL／Jdbc…Repository（COALESCE 保護）／CardStatusView	事件之消費端（投影讀模型）
④	notification／report 等剩餘服務	收尾

★ 此順序即本專案鐵則「不要一次補完所有生產端再回頭做消費端」之反面教訓——
本次係先發現生產端（①）根本還沒立，故必須回頭補，否則③做了也是「有人收、沒人發」。

4.2.6 ①／② 執行結果與未竟邊界（2026-10-16）

本次依 §4.2.5 先完成 card-service 載體主檔 Java 層，再接上卡片狀態事件之生產端：

驗收項	結果
Instrument 領域不變式	✅ 三型態各自唯一識別；互斥欄位拒絕；歸戶必填；RETIRED 再轉換回 CC-CARD-3002
InstrumentService	✅ 註冊／查詢／依歸戶列舉／狀態轉換；X-Idempotency-Key 同指紋重放、異指紋回 CC-CARD-2001；自然鍵重複回 CC-CARD-1004
JDBC	✅ INSTRUMENTS 真 Oracle CRUD；version 樂觀鎖；cardId 查詢失敗時以 cardNoHash 作相容退路
card.card.status-changed.v1	✅ 生產端從 INSTRUMENTS 解析並帶 instrumentId；尚未回填之舊卡保留 null，不臆造鍵值
契約／DTO	✅ OpenAPI 由產生器重生：104 endpoints／0 errors；verify_contract_dto.py：不符 0／需確認 0
card-service 品質	✅ 最新重跑 :services:card-service:test：BUILD SUCCESSFUL，145 tests；含真 Oracle Instrument JDBC 測試與 Controller／領域新增測試

⚠️ 未宣稱完成：party-service 投影（③）、notification／report（④）、以及 clearing 外部清算檔遮罩值之對映仍未完成；本節只關閉 §4.2.5 的 ①／②。

4.2.7 ③ party-service 投影執行結果（2026-10-16）

依 §4.2.5 ③，將事件之載體最小識別接入既有 card_status_caches 讀模型，不另建第二份卡片投影：

項目	結果
CardStatusSnapshot／Listener	✅ 增 instrumentId；舊事件缺欄時解析為 null，不阻斷消費
Oracle DDL	✅ 新增 V4__card_status_instrument_key.sql：instrument_id RAW(16) 可空＋索引；不破壞既有列
JDBC upsert	✅ INSERT 帶入載體鍵；UPDATE 使用 COALESCE(?, instrument_id)，舊事件重放不會清除既有值
查詢回應	✅ CardStatusView 增 instrumentId，由 PartyQueryService 映射；舊投影回 null
品質驗證	✅ party compile＋全測 61 tests；三掃描器各 0 命中；契約↔DTO 不符 0；兩服務 migration 合併 validate_sql 0 違規

⚠️ 本節的 SQL gate 說明：validate_sql.py 的外部豁免稽核目前會把未納入本次掃描之其他服務登錄項視為警告；故單獨掃 party 或 card 會出現對方之既有路徑警告。本次以 card＋party 兩個 migration 目錄合併掃描，規則違規 0 且登錄警告 0；未修改既有凍結 migration。

4.2.8 ④ notification／report 盤點結果（2026-10-16）

依 §4.2.5 ④ 先做事實盤點，不因「剩餘服務」字樣而臆造欄位或消費邊：

服務	實查結果	處置
notification-service	AuthApprovedNotificationService 只取授權事件之 cardNoMasked 作 cardLast4 顯示變數；通知聚合／模板／持久化沒有 cardId、cardNo 或 instrumentId 之交易鍵	N/A，不改程式；cardNoMasked 仍是顯示值，不升級為比較鍵
report-service	主程式之報表讀模型與來源未出現 cardId／cardNo／instrumentId；card_no_masked 僅在 Oracle 整合測試的授權種子中，非報表領域欄位	N/A，不改程式；測試種子不是生產契約

這不是「未完成」：本次盤點證明兩服務沒有 BR-16 交易鍵升級標的。若日後新增報表維度或通知歸因需求，應另立規格／CR，不在本批臆造 instrumentId。

4.2.9 誠實稽核與更正（2026-10-16）

本窗口接續後回頭稽核「是否遵守鐵律／是否假綠」，確認下列事項，不把局部通過寫成全案完成：

1. 規格先行曾被違反：Instrument Java 層與 CardController 載體端點是在本輪先寫程式、後補 SCS-003 §7.14 的。雖然 CR-046／SCS-026 已有 BR-16 範圍依據，但未在動工前先完成 card-service 之逐端點 SCS；這是 GOV-003 Coding Gate 的流程違規，不可倒填為「當時已規格先行」。本版補規格只代表補正文件缺口，不抹除該次順序違規。
2. 版本欄曾假綠：先前只追加修訂記錄，未同步更新 CR-046、SCS-003、SCS-004、SDD-006 檔頭版本欄，會使開機者誤判文件未同步；本次已分別補正為 1.5、1.12、1.3、1.12。
3. 契約關卡的邊界：verify_contract_dto.py 只核對回應 DTO，不能證明巢狀 Controller request 的欄名／必填與契約完全一致；本次新增 CardControllerTest 證明載體端點之標頭、路由、@Valid 與成功回應，但仍不宣稱該工具本身已消除請求 DTO 盲區。
4. 尚未完成的驗收不可冒充完成：card-service Instrument Java 層與 party 投影的局部測試／真 Oracle 已通過，但 B4「實體卡／虛擬卡／Token 同額交易 AC 11」及 clearing 對映尚未完成；CR-046 仍為施工中。
5. 發現並修正的資料一致性缺口：PHYSICAL 同時帶 cardId 與不相符 cardNoHash 時，原實作會只在 hash 空白時補值，可能建立半殘對映；現改為不一致即 CC-CARD-4001，並以卡片主檔值為權威。

4.2.10 B4／AC 11 動工前盤點結果（2026-10-16）

依本 CR 鐵律「先盤點再動工」，本次核查「實體卡／虛擬卡同構回饋一致」是否已有可執行的真實閉環：

平面	實查結果	判定
campaign-service Java	目前只有 Campaign 定義／查詢／核准上架／Outbox；沒有 ENROLLMENTS／REWARD_CMDS 對應 Repository、應用服務或 Controller	未完成 AC 11
CC_CPG.CAMPAIGN_ENROLLMENTS	已有 instrument_id RAW(16) NOT NULL、household_id、狀態與名額欄位	有表，不等於有錄取流程
CC_CPG.CAMPAIGN_REWARD_CMDS	已有 instrument_id RAW(16) NOT NULL、目標服務與指令 JSON	有表，不等於有發放指令
交易事件消費	campaign-service 仍無 authorization／posting／statement／交易事件 Listener；posting.transaction.posted.v1 現已可帶 instrumentId／merchantId／mcc 三個可選欄位（皆有權威來源）；仍缺 payPath 輸出契約與活動歸戶解析	活動認列之交易輸入欄位已備妥，但 campaign 消費者與 payPath／household 契約仍缺
回饋計算／發放	Campaign 明確不承擔 rewards 計算；rewards-service 目前的 instrumentId 僅存在兌換請求之載體歸因，沒有本活動認列→發點同鏈路	不可直接做同構回饋驗收
現有真機資料	沒有可用的「同戶實體卡／虛擬卡／Token，同活動、同金額、同支付路徑」完整活動交易資料與核定計算口徑	AC 11 真機驗收尚不可執行

結論：本次只補上已有權威來源的 posting.transaction.posted.v1.instrumentId 可選欄位，沒有臆造活動認列規則、點數公式、錄取 API 或 rewards 指令。AC 11 的下一個正確任務仍是先立「交易認列→活動錄取→回饋發放」之 SCS／契約與權責邊界；在此前，宣稱 AC 11 通過會是假綠。

4.2.11 AC 11 契約缺口盤點（2026-10-16）

欄位／語意	已有來源	目前缺口	處置
instrumentId	CC_POSTING.TRANSACTIONS.INSTRUMENT_ID、Transaction.instrumentId；本次已進 posted.v1	campaign 尚無 Listener／錄取流程	✅ 已補事件前置欄位；待後續立消費契約
merchantId	AuthorizeRequest／Authorization／CC_AUTH.AUTHORIZATIONS 有欄位；PostingRequest 也收欄位	PostingRequest.merchantId 未持久化至 Transaction，posted 事件無可可靠來源	不臆造；若活動認列需用，另立 posting 資料模型／契約 CR
mcc	AuthorizeRequest／Authorization／CC_AUTH.AUTHORIZATIONS 有欄位	Transaction／CC_POSTING.TRANSACTIONS 沒有欄位；posted 事件無來源	不臆造；先裁定授權→入帳資料傳遞與權威來源
payPath／支付路徑	Campaign DDL 有 campaign_pay_paths 規則表；授權／入帳事件沒有已核定的路徑輸出契約	無可直接消費的分類結果	不新增推導；BR-13 另立契約
householdId	已查明：歸戶即 CC_PARTY.ACCOUNTS（SCS-004；Account 聚合根＝歸戶聚合根；正附卡為同戶 parties[]）→ household_id ≡ accountId	無缺口——唯一待辦是 BEAM PMO 覆核此歸戶語意（§4.2.13 已更正原判斷）

結論：本次已完成 instrumentId 的最小前置傳遞，但 AC 11 仍被 mcc／merchantId／支付路徑／household 歸戶與 Campaign 消費流程阻塞。任何直接新增 Listener、錄取或回饋計算都會是臆造實作；下一步應先立這些欄位的權責與事件契約。

4.2.13 活動認列契約立約與歸戶語意更正（2026-10-16）

依 GOV-003 規格先行，已於 SCS-026 §7.5 立「活動認列輸入契約」（設計提案，待 BEAM PMO 核定；核定前不寫 campaign 消費端）：

#	內容	性質
①	認列來源唯一化：posting.transaction.posted.v1（授權事件不作認列依據）	設計裁定（有憑據：入帳為交易權威落點）
②	欄位權威映射：instrumentId／merchantId／mcc／accountId／amount／currency／txType／postingDate	皆已查證既有權威
③	★ 歸戶語意更正：household_id ≡ accountId——本系統歸戶即 CC_PARTY.ACCOUNTS（SCS-004；Account 聚合根＝歸戶聚合根；正附卡同戶共用 cif_no）	更正 #A-253 之「householdId 無權威來源」判斷（當時未查 party 模型，過度保守）
④	payPath：認定器屬 campaign（campaign_pay_paths 規則表＋fail-closed）；認定規則待 BEAM PMO 核定、不建預設；不在 posting 事件加欄	邊界裁定＋待客戶/BEAM PMO 輸入
⑤	AC 11 驗收前置條件五項（契約核定／消費鏈實作真機通過／真活動參數／兩載體同額逐分一致）	驗收判準

不改程式：本節為契約與查證增量，verify_contract_dto／測試無涉。

4.2.15 BEAM PMO 兩項裁定落定（2026-10-16 23:2x；SCS-026 → 2.5）

#	裁定	查證／落地
①	歸戶語意：自然人 household_id ≡ accountId 經 BEAM PMO 確認；BEAM PMO 提出法人公司戶疑義	實查 AccountType／SDD-001 §3（account_type IN ('PERSONAL','CORPORATE')，V1 即有）＋ BRD-005 §3（持卡人含公司戶）→ 法人同構：公司戶即一歸戶、員工附卡為其 parties[]；活動差異（企業卡除外等）走 exclusions 參數
②	payPath：規則表對照方向經 BEAM PMO 同意	值域四類有 BRD AC 8／§6B 依據；實查定位新缺口：授權側無結構化 wallet 欄位（僅自由 emvData）→ wallet 識別權威欄位另立授權側增量；補強前非實體路徑落 UNKNOWN（fail-closed）

解鎖：SCS-026 §7.5②③ 已落定 → campaign 消費端（Listener／ENROLLMENTS／REWARD_CMDS）可開工。
wallet 識別補強為獨立增量，僅影響 payPath 維度活動，不阻擋 AC 11 載體同構驗證。

4.2.16 已知契約與個資邊界

遮罩標準已依 BEAM PMO 本輪裁定回到現行 PiiMasker：內部前 6 後 4、*、無分隔符。9999-xxxx-xxxx-xx99 不改寫成全系統標準；若外部清算檔另有格式，僅另立外部檔轉換規格。無論採哪一種顯示格式，遮罩值都不得作為 instrumentId 對映或比較鍵。

instrumentId 為事件／交易內部最小識別；cardNoMasked 仍是顯示欄位，不能當比較鍵。內部遮罩已裁定以現行 PiiMasker 為準；載體服務回應不暴露 cardNoHash／virtualNo／tokenRef。

clearing_items.card_no_masked（V1 DDL）之性質經查為：

• 來源為外部清算檔（收單資料源），係帶入之遮罩顯示值，非指向 INSTRUMENT 之鍵；
• Java 領域模型完全未映射此欄（僅存在於 DDL），故其不構成「交易最小鍵」；
• 若欲升級為 instrument_id，須先裁定「遮罩卡號如何對映至載體」
  （本服務無明文卡號、亦無匹配來源）→ 屬 **§5 已知風險之真阻塞（收單資料源）**同類。

→ 不擅動（不得為「打通」而臆造對映規則）。這是 clearing 之未竟項；另 B4／AC 11 仍待交易認列與回饋發放契約。

5. 已知風險（誠正揭露）

1. B2 波及面最大：card_no 出現在多服務 DTO／DDL／事件 payload／報表，
   逐項盤點成本高；以「主檔新增＋視圖對接」壓低重寫，但仍需逐服務編譯與測試驗證。
2. SCS-026 v2.0 的 30 欄參數中，部分欄位語意需 BRD 驗證時才浮現
   （如 rate_schedule 分層優先序與 cap 的相互作用）。
   → 以十範例為驗收線，範例過了才算語意對。
3. **BRD 遺留假設 A7（利率減碼會計科目）**會影響 BR-15 的 reward_form=RATE_CUT
   帳務落地；屬客戶輸入，見 §3。
4. 工時：本 CR 含新服務＋全服務鍵升級，為多批次工程（TRP-003 式
   「每批次 3～5 個服務」推進），非單一回合可完成。

---

6. 修訂記錄

版本	說明
1.0	2026-10-16：初版。BEAM PMO 裁定 campaign-service 必須完成、BR-16 必須與活動引擎同批上線；採單一交付列車（A 新服務／B 載體抽象／C 介接骨架），列 C-0～C-11 任務清單，明列同批鐵則與風險。
1.1	2026-10-16：B2-6 動工前盤點結果（新增 §4.2）。① dispute／merchant 經查無 card 維度 → 交易鍵升級 N/A（原清單係依服務別推論，非依欄位實況）；② 「事件 payload 全面改版」真實剩量已完成——授權事件補 instrumentId、posting→statement 全鏈接線（INSTRUMENT_ID 由「有欄位沒有值」轉為真閉環）、契約重生 100 端點；③ clearing 待 BEAM PMO 裁定（card_no_masked 為外部清算檔遮罩值，非鍵，且領域模型未映射）。五關卡全過，詳 HANDOVER #A-247。
1.2	2026-10-16：依 §4.2.5 完成 card-service Instrument Java 層與 CardStatusEventFactory 的 instrumentId 生產端；OpenAPI 重生為 104 endpoints／0 errors，契約↔DTO 不符 0；補記「僅完成 §4.2.5 ①／②，party 投影與剩餘服務未宣稱完成」。
1.3	2026-10-16：完成 §4.2.5 ③：party 卡片狀態投影接入 instrumentId（CardStatusSnapshot／Listener／V4／JDBC COALESCE／CardStatusView）；party 全測 61 例通過，契約↔DTO 不符 0，三掃描器 0 命中；clearing 待裁定。
1.4	2026-10-16：完成 §4.2.5 ④ 之事實盤點：notification／report 均無 BR-16 交易鍵或消費標的，判定 N/A、不改程式；清算遮罩值對映仍待外部資料／裁定。
1.5	2026-10-16：本窗口誠實稽核更正：補 SCS-003 §7.14 載體端點規格、同步修正四份文件檔頭版本欄；明列先寫程式後補 SCS 的流程違規、request DTO 驗證工具盲區、B4／clearing 未完成；PHYSICAL cardId／cardNoHash 不一致改為 fail-closed CC-CARD-4001。
1.6	2026-10-16：BEAM PMO 裁定遮罩格式爭議回到現行 PiiMasker 標準；9999-xxxx-xxxx-xx99 不作全系統替換，只能另作外部清算檔轉換規格；clearing 顯示欄仍不作 instrumentId 對映鍵。
1.7	2026-10-16：B4／AC 11 動工前盤點更正：Campaign 目前只有定義層 Java；ENROLLMENTS／REWARD_CMDS 僅有 DDL，無交易事件消費、錄取流程、回饋計算或 rewards 發放鏈路；AC 11 改列待立 SCS／契約，不宣稱完成。
1.8	2026-10-16：完成 B4 前置可交付增量：posting.transaction.posted.v1 帶出既有 Transaction.instrumentId 可選欄位；同步更新 SCS-007／SDD-006，posting 事件工廠測試 8 例全綠。僅完成載體鍵供後續認列，未宣稱 AC 11 完成。
1.9	2026-10-16：前置增量品質收尾：posting-service 全測 76 tests BUILD SUCCESSFUL；三掃描器 0 命中；OpenAPI 104 endpoints／0 errors；契約↔DTO 不符 0；card＋party＋posting migration 合併驗證 17 檔、0 違規。
2.0	2026-10-16：AC 11 契約缺口盤點：instrumentId 已可由 posted 事件傳遞；mcc／merchantId／支付路徑／household 歸戶仍未形成完整權威來源與消費契約，故不新增臆造的 campaign Listener／錄取／回饋流程，AC 11 仍未完成。
2.1	2026-10-16：新增 posting merchantId 前置資料鏈：PostingRequest.merchantId → Transaction／CC_POSTING.TRANSACTIONS.MERCHANT_ID（V8，可空）→ posting.transaction.posted.v1.merchantId（可選）；未處理無權威來源的 mcc／支付路徑，未宣稱 AC 11 完成。
2.2	2026-10-16：新增 posting mcc 資料鏈（規格先行）：PostingRequest.mcc → Transaction／TRANSACTIONS.MCC（V9，可空）→ posted.v1.mcc（可選）；mcc 權威在授權端，posting 不對映不推導。收斂 CR-030 §4.2／CR-029 C-3 之 payload 缺口（mcc／merchantId 均已備妥）；verify_contract_dto 攔下 DTO↔契約漂移並由 gen_openapi.py 修正。posting 76 例全綠；SQL 19 檔 0 違規；三掃描器 0 命中。AC 11 仍缺 payPath／household／campaign 消費鏈，未宣稱完成。
2.3	2026-10-16：SCS-026 §7.5 活動認列輸入契約立約（設計提案，待 BEAM PMO 核定）。① 認列來源唯一化＝posted.v1；② 欄位權威映射；③ ★ 歸戶語意更正——實查 SCS-004／JdbcAccountRepository 確認本系統歸戶即 CC_PARTY.ACCOUNTS，household_id ≡ accountId（更正 §4.2.11／#A-253 之「householdId 無權威來源」判斷，係當時未查 party 模型之過度保守）；④ payPath：認定器屬 campaign（campaign_pay_paths 規則表＋fail-closed），認定規則待 BEAM PMO 核定、不建預設，且不在 posting 事件加 payPath 欄（分類屬活動規則職責）；⑤ AC 11 驗收前置條件五項。核定前不寫 campaign 消費端。
2.4	2026-10-16：BEAM PMO 兩項裁定落定（SCS-026 → 2.5）。① 歸戶語意：自然人經 BEAM PMO 確認成立；法人公司戶經實查同構適用（account_type IN ('PERSONAL','CORPORATE')——公司戶即一歸戶，員工附卡為其 parties[]；活動差異走 exclusions 參數，非歸戶模型）。② payPath：規則表對照方向經 BEAM PMO 同意；實查定位新缺口——授權側無結構化 wallet 欄位（僅自由 emvData），種子規則依 BRD §6B／AC 8 值域可立，wallet 識別權威欄位待授權側契約補強（補強前非實體路徑落 UNKNOWN，fail-closed）。§7.5②③ 已解鎖，campaign 消費端可開工；wallet 識別補強另列增量（僅影響 payPath 維度，不阻擋 AC 11 載體同構驗證）。
2.5	2026-10-16：★ AC 11 消費鏈（認列→錄取→指令）實作完成，真機通過（SCS-026 → 2.6）。新增：V3__consumed_events.sql（eventId 冪等＋sequenceNo 亂序）、V4__nullable_instrument.sql（舊事件 instrumentId null 不阻斷，§7.5④）；PostedTransactionListener（cc.posting.transaction.posted）→ TransactionRecognitionService（AUTO 錄取／REGISTER 略過／沖正略過）→ campaign_enrollments 錄取（household_id ≡ accountId，uq_enroll 冪等重放）→ campaign_reward_cmds 指令下發（僅認列事實、PENDING；計算屬 rewards 權威，不臆造）。campaign 全測 25 例全綠（真 Oracle 判定力測試 8 例：冪等／亂序／沖正／REGISTER／舊事件相容／期間外／未知型別）。SQL 合併 23 檔 0 違規；三掃描器 0 命中；契約↔DTO 0 不符。仍缺：門檻／上限／排除項／疊加／名額控管／登錄 API／rewards 消費端——REWARD_CMDS 為 PENDING 佇列（有人發、暫無人收），AC 11 未宣稱完成。
2.6	2026-10-17：★ 指令派發與 rewards 消費完成，真機通過（SCS-026 → 2.7、SCS-010 → 1.12、SDD-006 → 1.16、SAD-004 §5.2）。campaign：RewardCommandRelay（REWARD_CMDS 即指令 outbox：掃 PENDING → 發布 cc.campaign.reward.commanded → 標 SENT；SENT＝已派發非已入點；KafkaRewardCommandPublisher；campaign 補 @EnableScheduling）＋認列類別收斂（本期僅 PURCHASE——排除項規則未實作不臆造）。rewards：CampaignRewardCommandListener → AccrualService.accrue（冪等鍵 campcmd:<commandId>，至少一次投遞重放安全；到期日以 postingDate 錨點；⚠️ 活動加成 rate_schedule 未實作——本期標準層級倍率，不臆造加成）。全鏈閉環：入帳事件 → 認列 → 錄取 → 指令 → 派發 → 入點。campaign 全測 27 例、rewards 全測 158 例 BUILD SUCCESSFUL；SQL 合併 27 檔 0 違規；掃描器 0 命中（faketest T5 攔下無斷言測試，已補斷言）；契約↔DTO 0 不符。仍缺：門檻／上限／排除項／疊加／名額控管（AC 7）／登錄 API／活動加成比率——AC 11 未宣稱完成。
2.7	2026-10-17：★ AC 7 名額原子控管與登錄 API 實作完成，真機通過（SCS-026 → 2.8、SDD-006 → 1.17）。① 原子取號＝行鎖（SELECT FOR UPDATE）＋條件更新（雙重保險）＋DB CHECK 防線（campaign_quotas DDL 註解即本設計）；② 新端點 POST /api/v1/campaigns/{code}/enrollments（僅 REGISTER；額滿 CC-CAM-1004、AUTO／非 ACTIVE CC-CAM-3001、波次窗口檢核）；③ 冪等：同 (campaign, wave, household) 回前次結果；併發撞 uq_enroll → 退回名額補償；④ 契約重生 105 endpoints／0 errors。campaign 全測 33 例 BUILD SUCCESSFUL（真 Oracle 判定力：取號連號／禁超發／冪等／AUTO 拒絕／404／窗口外）。仍缺：門檻判定（QUALIFIED）／上限截斷（BR-03）／排除項／疊加／加成比率。
2.8	2026-10-17：★ 門檻判定與指令下發完成＋權威矛盾釐清，真機通過（SCS-026 → 2.9）。① ★ 矛盾釐清：SCS-026 §2 BR-03（campaign 計算）與 CR-045 D3（Campaign 不接管計算）相衝突——依 D3 為準：campaign 規則判定（「算不算」）、rewards 點數計算與帳本（「給多少」），§2 已更正。② 門檻判定（campaign_thresholds 既有表接線）：無門檻＝即時型每筆下發；PER_TXN／ACCUM（V5__enrollment_accrued.sql 原子累計）→ 達標原子升格 QUALIFIED（UPDATE … WHERE status='REGISTERED' 併發恰一筆成功→一次性指令）；PER_STORE_PER_DAY fail-closed 略過（店別識別未經業務確認）。③ REGISTER＋已登錄者之認列接通（未登錄略過——登錄 API 與認列鏈閉合）。campaign 全測 38 例 BUILD SUCCESSFUL（判定力 6 例：ACCUM 三段式／PER_TXN 立即升格／未達不下發／fail-closed／REGISTER 已登錄才認列）。SQL 合併 28 檔 0 違規；掃描器 0 命中；契約↔DTO 0 不符。仍缺：上限截斷（cap，需 rewards 回流）／排除項／疊加／加成比率——AC 11 未宣稱完成。
3.6	2026-10-17：★★ 跨服務真機 E2E 首度閉環（32/32）＋CR-049 兩類實質缺陷修正。① 實機症狀（反假綠）：campaign 2 筆 SENT、rewards 0 入點、API 404、日誌 eventType=null——單元／整合／契約比對全綠卻實機全掛；② 根因 A：campaign producer value-serializer=JsonSerializer → 信封二次編碼（同型缺陷尚有 5 服務）→ 已全改 StringSerializer＋產生器同步＋新增架構關卡 A9；③ 根因 B：relay 把 command_json 包進 payload.recognition，而 rewards 只讀 payload → refund 恆 false（把退款當入點）、originalPostingId null；且 reversed.v1 無業務日 → 拼 "nullT00:00:00Z" 解析失敗 → 已加 postingDate（不升版）＋消費端「recognition 優先」＋txType=REFUND 權威＋缺值 fail-closed。④ E2E 32 項：兩載體各 123 點（載體無關）／比率 5% → 6 點／cap used=600 estimated=617 cap=1000 精確截斷／回沖 ADJUST -123 淨零；⑤ 關卡：A9 selftest 9/9＋實跑 9/9、listener 6/6、factory 8/8、campaign 整合 30/30、掃描器 0 命中、契約 0 不符、SQL 92 檔 0 違規。仍缺：三載體跨 JVM 對照（環境限制）／R-1b／R-2（外部依賴）／部分退款按比例回沖（待 SCS-010）。
3.5	2026-10-17：★ 排除項參數化（SCS-026 §7.16）＋ledger 活動歸屬寫入完成；未宣告 clawback_rule 預設經 BEAM PMO 裁定凍結（不回沖）。① 排除項：基準＝僅 PURCHASE（與原行為一致）；活動覆寫 exclusion_json：includeTxTypes（納入額外類別——BRD「可按活動覆寫／翻轉」）／excludedMccs（mcc 缺席時 fail-closed）；② ledger 歸屬：POINTS_LEDGER.CAMPAIGN_CODE 寫入（AccrualService 由指令帶入；到期／兌換為 null）。判定力：campaign 真機 30 例（排除項 3 例：基準／覆寫納入／mcc 排除）；兩服務全測 BUILD SUCCESSFUL；SQL 46 檔 0 違規；掃描器 0 命中；契約 106 endpoints／0 不符。仍缺：R-1b／R-2（外部依賴）／三載體跨 JVM 端到端（環境限制）——AC 11 未宣稱完成。
3.4	2026-10-17：★ 退款回沖（SCS-026 §7.14）與疊加 D9（§7.15）實作完成，真機通過。① 回沖：ReversalListener（cc.posting.transaction.reversed）＋ReversalService——eventId 冪等 → 以 reversalOf 反查原指令（★ V8 加結構化欄位 posting_id／household_id／amount_minor＋索引；不依賴 JSON_VALUE）→ CLAW_BACK 才回沖（NO_CLAWBACK／未宣告不回沖——保守不扣客戶，待 BEAM PMO 覆核）→ 回沖指令（refund:true）＋ cap 用量退還（GREATEST(…,0)）；rewards 讀 refund → 復用既有退款分支（ADJUST＋負值）。② 疊加 D9：V7 加 campaigns.priority（越小越優先，預設 100）→ 命中 NON_STACKABLE 取 priority 最小並排除其他所有活動；全 STACKABLE 全套用。判定力：campaign 真機 27 例（含回沖 3 例＋D9 2 例）；兩服務全測 BUILD SUCCESSFUL；SQL 46 檔 0 違規；掃描器 0 命中；契約 106 endpoints／0 不符。★ 診斷紀律：回沖測試初版失敗，以三段式診斷（clawback 落庫？posting_id 寫入？反查命中？）定位為測試設計錯（snapshotOf() 自帶隨機 postingId，與 aggregateId 不同）——實作正確。仍缺：R-1b／R-2／POINTS_LEDGER.campaign_code 寫入／三載體跨 JVM 端到端——AC 11 未宣稱完成。
3.3	2026-10-17：★ R-3b 定案並實作（BEAM PMO 裁定採 (a)：rewards API 回傳 tier 序）——① rewards：findTierRank（QUALIFICATION_SPEND 升冪取序；僅 ACTIVE；查無 null）＋PointsAccountView.tierRank；② campaign：TierLookupPort.TierInfo(tier, rank)＋條件鍵 minLevelRank（序比較；序缺席＝不判定）；③ ★ 設計洞察：序號設計更貼近 BRD §11 原文「Level 2 起 3%」（Level 即序），且序之規則不落地 campaign（不寫死）。判定力：RateResolverTest 7 例＋rewards 真機 2 例（序／停用排除）全綠；契約 106 endpoints／0 不符；SQL 44 檔 0 違規；掃描器 0 命中（T3 攔下缺 verify → 補）。仍缺：R-1b planCode 來源／R-2 客戶主檔／排除項／疊加（D9）／REFUND 回沖——AC 11 未宣稱完成。
3.2	2026-10-17：★ 條件式比率凍結並實作（R-1～R-5 全數落地）＋支付路徑跨服務透傳，真機通過（SCS-026 → 3.4、SCS-010 → 1.14、SDD-006 → 1.21、CR-048）。BEAM PMO 逐條裁定後實作：R-1②（campaign_plans.benefit_rate_json 承載方案層權益率，schema {"rate":n}；RateResolver 判定順序：方案權益率 → 條件檔 → 基準檔）、R-2（生日權威＝客戶主檔；★ 實查本平台無 customer-service 且 party 無生日欄 → 外部依賴，介面待提供；birthMonth 條件未提供＝不判定）、R-3（rewards 查詢 API＋SAD-002 §5 補 campaign 列＋ACL 重生＋PointsAccountView.tier＋TierLookupPort／RewardsTierClient）、R-3b（★ 實查 POINTS_TIERS 無序號欄 → 層級序未凍結，minLevel fail-closed 不臆造）、R-4（CR-048：授權側結構化 pay_path V13 → posting V10 → 事件帶出 → campaign 判定；★ 不接受 UNKNOWN——缺值＝不判定）、R-5（rateReason 稽核留痕）。★ 分層測試攔下真實違規（application 直依 infrastructure.client）→ 改 domain port。仍缺：R-1b planCode 來源／R-2 客戶主檔介面／R-3b 層級序／排除項／疊加（D9）／REFUND 回沖——AC 11 未宣稱完成。
3.1	2026-10-17：★ 活動回饋率接線＋精確上限截斷，真機通過（SCS-026 → 3.2、SCS-010 → 1.14、SDD-006 → 1.20）。語意依 BRD 例 1 算式（回饋價值＝金額 × rate）——① campaign_rates 接線：僅採無條件基準檔（condition_json={}，BRD 例 1「一般消費 0.5%」），有條件檔 fail-closed（語意未凍結不臆造）；② applicableRate 隨指令下發 → rewards 有值時取代標準倍率（points = floor(amount×rate) ÷ 點值）；③ 精確截斷（CR-047 §3.1 補完）：used ≥ cap 或 used + amount×rate > cap → 停發；④ ★ 點值單位更正：point-value-minor 為分、預設 100（1 點 1 元），先前誤記 1（會造成 100 倍錯帳）；⑤ ★ 陷阱：Oracle JSON 欄不可字串比較（condition_json 改 Java 端判定）＋getObject 拋 ORA-18722。campaign 46 例／rewards 159 例 全綠；契約 106 endpoints／0 不符。仍缺：有條件比率逐欄語意／排除項／疊加（D9）／REFUND 回沖（reversed.v1 帶 reversalOf）／POINTS_LEDGER.campaign_code 寫入——AC 11 未宣稱完成。
3.0	2026-10-17：★ cap 依 CR-047 定案並實作，真機通過（SCS-026 → 3.1、SCS-010 → 1.13、SDD-006 → 1.19）。BEAM PMO 裁定：開 CR＋回訪既有架構（參數極大化，不用寫死／workaround）＋「點」與「元」兩側皆參數（現防呆 1 點＝1 元）。回訪發現：① campaign_caps 僅活動級單一 consumed，無法承載 BRD §11「六單位各自可配＋可組合」→ 定義／用量兩表分工＋通用 scope_key／period_key（新增單位不改表）；② rewards.points.accrued.v1 無活動歸屬→ 回流無法識別活動（rewards 側補 campaignCode 等 4 可選欄位）；③ SCS-026 §3 #17 漏列 PER_HOUSEHOLD_MEMBER（已更正）。實作：campaign CapGuardService（事前截斷／事後回填）＋PointAccruedListener＋JdbcCapUsageRepository（原子遞增）＋V6__cap_usages.sql；rewards AccrualRequest 3 可選欄位＋ProductPointValueHttpClient（點值商品參數）＋V6__ledger_campaign.sql。驗收：未達上限可發／回填達上限停發／PER_MONTH 跨月獨立／PER_STATEMENT fail-closed 真機通過；campaign 43 例、rewards 158 例 全綠；契約 106 endpoints／0 不符。仍缺：精確事前截斷（需 rate_schedule）／排除項／疊加（D9）／加成比率／wallet／REFUND——AC 11 未宣稱完成。
2.9	2026-10-17：★ cap 設計提案（待 BEAM PMO 裁定）＋錄取查詢端點＋AC 11 載體無關性，真機通過（SCS-026 → 3.0、SDD-006 → 1.18）。① cap 兩落差實查：campaign_caps 無 household_id 維度（per-household consumed 無處放）、cap_value_minor（分）vs 回流點數換算未定——提案 V6 加欄＋兩案換算（建議以點數為 cap 單位），裁定前不實作（不臆造）；② 新端點 GET /api/v1/campaigns/{code}/enrollments/{householdId}（status／quotaSeq／accruedAmountMinor——AC 11 對照之可觀測性），契約重生 106 endpoints／0 errors；③ AC 11 載體無關性服務內判定力測試：同戶實體＋虛擬各一筆認列→跨載體累計合併（16,000 達標）→一次性指令（AccrualRequest 無載體欄位＝契約面載體無關；⚠️ 跨服務真 Kafka 端到端待跨 JVM 驗證，#A-241 判例）。campaign 全測 40 例 BUILD SUCCESSFUL；SQL 28 檔 0 違規；掃描器 0 命中；契約↔DTO 0 不符。仍缺：cap 實作（待裁定）／排除項／疊加／加成比率——AC 11 未宣稱完成。