CR-045　「參數極大化」三位一體（商品組合 × 行銷活動 × 系統參數）——現況盤點與落差

項目	內容
文件編號	CR-045
版本	1.3
狀態	★ 現況盤點已完成、治理提案待裁定（BEAM PMO 2026-10-15 指示「參數極大化」為最高宗旨）；本版已更正文件／程式漂移及 L0–L3 分級
提出日期	2026-10-15
提出者	開發團隊（★ 來源為 BEAM PMO 2026-10-15 口頭指示：「最高宗旨為參數極大化」）
影響文件	SCS-023（商品組合）、SCS-005（產品服務）、SCS-019（批次框架）、SCS-022（安全）、SDD-001 §3（資料模型）、SDD-005（狀態機）、GOV-004（追溯矩陣）
影響模組	product-service、pricing-service、limit-service、rewards-service、billing/statement-service、card-service、common-security、全體領域服務（消費端）
優先級	P1（高）——跨全系統治理議題；★ 參數表/API 與部分規格已具備，但執行期消費閉環未獲證明且文件有漂移
相關前例	SCS-023 v1.4（「組合優於列舉」，BEAM PMO 2026-09-20 指示）、CR-014（SPECIAL_LIMITS）、CR-043 §3.1（移除未實作端點宣告；卡片級查詢需求另追 GOV-006 2.4.4）、#A-234／#A-235

---

1. 摘要

BEAM PMO 2026-10-15 明示：最高宗旨為「參數極大化」，其至少須達成
三位一體——① 商品組合、② 行銷活動、③ 系統參數——之參數化。
並附帶一句關鍵提醒：RFP 未載明「卡片級可用額度查詢」，但客戶最終一定會要求。

本文為現況盤點與落差報告（★ 未動手新增功能，待裁定後另案執行）。
★ 全篇逐項以現行原始碼 ＋ 現行規格 ＋ 現行 DDL 重新核對（非抄舊結論；
依 MEMORY-RULES #17／#38 之「未查證之待辦／他人之已完成，皆可能是幽靈」紀律）。

一句話結論：本系統已有 product.parameters 參數表/API、product.rule_sets 規則表，
亦有 SCS-023 的 24 個能力鍵與 7 個測試 profile；但規格宣告的跨服務同步取參數路徑，
在現行 Java 原始碼中找不到實際下游客戶端。因此，應將它們視為**「資料模型與規格先備、
尚未證明執行期消費閉環」，不可把「有表／有端點／文件列相依」等同「參數已驅動業務」。
工作重心是先釐清權威與程式/文件漂移，再逐個打通『參數 → 可觀察行為』**；
也不宜為追求「單一」而把所有領域規則硬塞進同一張泛型表。

---

2. 緣起與判準

2.1 BEAM PMO 指示原文（逐字）

「……最高宗旨為：『參數極大化』，所謂參數極大化是個模糊空間，但至少要達到：
商品組合、行銷活動、系統參數，這三位一體參數極大化的目的。
就商品組合而言：新用卡、借記卡、無擔保貸款、採購卡……，這一類『商品』要能夠用參數定義，
當然包括總額度、個別額度等多維度的設計。
就行銷活動而言：年費、免年費、紅利積點、里程累計、刷卡滿額禮……等，都要是參數化。
就系統參數而言：大到每年的節假日、跑批、結算、帳單週期，
小到人員安控機制等，也都要參數化。」

2.2 本文採用之「參數化達成度」判準（四級）

為避免「有表即算完成」之假綠，本文對每一參數維度採四級判定：

級別	意義	判準（可稽核）
L0 無	無可確認的資料模型／功能實體	文件、DDL、程式皆查無該能力（只在需求描述出現不算有）
L1 已建置、未閉環	有資料模型／設定端點／獨立子域規則，但未證明被目標業務流程消費	必須指出具體 API／表／程式；消費鏈缺失或僅能查閱設定
L2 有執行期消費、未閉環	有真實消費路徑，但部分行為仍寫死、功能覆蓋不足或未證明參數變更可即時生效	找到生產程式的讀取與決策分支，但閉環測試未全
L3 閉環	參數變更 → 執行期行為隨之改變（實測可證）	改權威值後，真機業務行為隨之改變且可還原

★ 判準核心：以「改了參數，行為會不會跟著變」為準，不以「表是否存在」為準。

---

3. 軸一：商品組合（Product Composition）

3.1 已具備（規格層）

• SCS-023 v1.4《卡片商品組合與測試卡片檔產生規格》 已立，核心原則為
  「組合優於列舉」（BEAM PMO 2026-09-20 指示）——即商品不由「硬編代碼」列舉，
  而由能力維度組合定義。
• CAPABILITY_KEYS 共 24 維度已定義，涵蓋：
  • 發行／額度：issuance.form、limit.model、limit.shared_scope、limit.grant_required
  • 循環／還款：revolving.enabled、revolving.rate_annual、payment.grace_days、payment.auto_debit
  • 分期／預借：installment.enabled、cash_advance.enabled
  • 商戶控制：mcc.allowed、mcc.blocked
  • 票券／附卡：ticket.*、supplementary.*
  • 跨境／代碼化：cross_border.enabled、dcc.enabled、tokenization.platforms
  • 帳務：billing.cycle_day、billing.currency
  • 風控／網路：kyc.level、network_allowed
• 7 個測試／設計 profile已規劃：REVOLVING_CREDIT、CHARGE_CARD、
  VIRTUAL_LOAN_CARD（對應無擔保貸款 eLOAN）、PURCHASE_CARD（對應採購卡）、
  COBRAND_TICKET、PREPAID、CORP_TRAVEL。★ 這是 SCS-023 的組合範本，不等同於 7 個已部署、
  已可供線上授權使用的商品；另缺借記卡 profile。
• Oracle 實查已存在：CC_PRODUCT.PRODUCTS、PARAMETERS、RULE_SETS 三表皆存在。
  PARAMETERS 有 namespace／param_key／JSON value／value_type／effective date；
  RULE_SETS 有 rule_type／condition／action／priority／status，但沒有 product_code、campaign_id、
  生效區間欄位，且尚無其 CRUD API／執行期 RuleEngine。

3.2 落差（實作層）

#	落差	級別	證據（as-found）
P1	商品參數未證明進入線上決策	L1	全 backend 源碼檢索未找到下游呼叫 /api/v1/parameters 的 client／port；SAD-002 列有同步依賴、CR-031 又稱 9 服務同步取值，但 CR-031 §3.1 同時記錄 9 服務無 ProductClient／ParameterPort——文件與程式結論互相矛盾，應以現行程式為執行事實、以文件為待更正之設計意圖
P2	limit.model／limit.shared_scope 尚未被額度路徑消費	L1	limit-service 無產品參數遠端 client／port；目前有帳戶額度及專用額度模型，但未按 SCS-023 商品能力組合決定額度層級／共享範圍
P3	總額度／個別額度的商品多維度尚未端到端落地	L1	既有帳戶永久／臨時額度與專用額度不是「已按商品參數完成總額度／個別額度建模」的證據；CAPABILITY_KEYS 無執行期分支，卡片與帳戶／企業共享池的分攤語意尚待規格
P4	借記卡（Debit）無對應 profile	L0	7 個 SCS-023 profile 中無 Debit／借記檔（PREPAID 為預付、非借記）；BEAM PMO 明列「借記卡」為應支援商品
P5	product.rule_sets 僅有資料表，尚無管理／執行鏈	L1	Oracle DDL 有表；Java 無 RuleSet repository／API／RuleEngine 實作；表本身亦缺商品／活動關聯與生效區間欄位

3.3 小結

商品組合有設計字典與測試 profile，尚無證據證明線上決策消費這些能力參數：
CAPABILITY_KEYS 的 24 維度不等於已實作的商品行為；既有帳戶級額度、專用額度亦不等於
已按商品定義總額度／個別額度／共享額度。BEAM PMO 所舉情境中，無擔保貸款與採購卡有測試 profile，
一般信用卡有 profile；借記卡 profile 缺漏，且 7 個 profile 均不能視為已上線商品。

---

4. 軸二：行銷活動（Marketing／Campaign）

4.1 BEAM PMO 所列五項之現況

BEAM PMO 所列	現況	級別	證據（as-found）
年費	有規則設定查詢，未形成費用收取閉環——PRICING_RULES.RULE_TYPE=ANNUAL_FEE／FEE_AMOUNT／生效區間存在；GET /fees 可查	L1	SCS-006 §6／§7.7 明定本期只查詢、不計算／不入帳；feeName 由 RuleType 對照表硬編，currency 固定 TWD；DDL 無 fee_name／currency 欄，也無活動連結
免年費	有規則型別，未證明減免政策被費用流程消費——RuleType.FEE_WAIVER／設定列存在	L1	GET /fees 僅查詢設定；無年費收取／免除計算或入帳流程；減免條件未連商品／客層／活動生命週期
紅利積點	有獨立的回饋規則維護端點，未證明規則被累點流程消費——rewards-service RewardRule／/reward-rules	L1	RewardRuleRepository 只在規則維護服務被使用；累點服務未讀取規則計算交易點數；規則與 product.rule_sets、商品／活動未關聯
里程累計	無	L0	源碼／DDL 檢索未找到里程帳戶、里程規則或里程累計流程
刷卡滿額禮	無	L0	源碼／DDL 檢索未找到滿額禮活動實體、資格追蹤或達標發放流程

4.2 結構性落差

#	落差	級別	說明
M1	無「行銷活動」aggregate／生命週期模型	L0	現有 DDL／Java 未找到 campaign 主檔、活動狀態、活動對象／受眾、活動期間及管理 API
M2	規則設定與執行規則分離	L1	product.rule_sets 僅有通用 JSON DDL、無 CRUD／RuleEngine；pricing 只查年費設定，rewards 有 RewardRule 維護端點但累點路徑不消費規則
M3	行銷規則分散於各域且未接合	L1	點數規則在 rewards、年費／費用規則在 pricing；未見共同活動識別碼／跨域參照或統一有效期
M4	無活動資格、期間、疊加／互斥、預算上限模型	L0	PARAMETERS 的單鍵生效區間不等於活動生命週期，也無活動間優先序／疊加及發放上限語意

4.3 小結

行銷活動為三軸中最弱之一軸：里程與滿額禮缺模型與流程；年費／免年費只有費率設定查詢、
沒有費用收取或免除執行；紅利規則可維護，但累點流程未消費該規則。核心缺口不只是「少一張活動表」，
而是缺活動生命週期、規則所屬權威、活動資格／期間／疊加，以及連接 pricing／rewards 執行端的契約。
product.rule_sets 目前只是通用表，沒有 API／消費者，且 schema 缺商品／活動關聯與有效期；
不得僅因它有 REWARD／FEE 值域就推定其足以承載行銷活動。

---

5. 軸三：系統參數（System Parameters）

5.1 BEAM PMO 所列各項之現況

BEAM PMO 所列	現況	級別	證據（as-found）
系統參數儲存	有可用設定庫/API——product.parameters ＋ GET／PUT /api/v1/parameters/{namespace}/{paramKey}	L1	product schema／API 存在；但全 backend 源碼未找到下游呼叫；文件所稱 9 服務同步取值與實作檢索不符（§5.2/S5）
節假日	無日曆模型	L0	源碼／DDL 未找到 holiday／business calendar；批次規格僅要求「須納入」營業日曆
跑批	有排程機制、非集中業務參數——SCS-019 common-batch 框架存在；具體排程由服務註冊	L1	@Scheduled 可由服務屬性覆寫且帶預設值；頻率／作業參數沒有集中納入 product.parameters，各領域 SCS 尚需凍結
結算	有服務作業與排程，非統一設定	L1	clearing 等域有其作業；「每日結算」屬 SCS-019 設計意圖，未見統一結算日曆／營業日規則模型
帳單週期	部分建置——CC_PARTY.ACCOUNTS.statement_day 已存在；SCS-023 另列 billing.cycle_day 商品能力	L1	原始碼／DDL 有帳戶級結帳日；未找到 billing.cycle_day 商品參數消費路徑或其與 statement job 的商品級連動
人員安控（RBAC）	認證存在、角色授權缺失	L0	JWT 認證／角色 claim 解析能力存在；SCS-022 §6.3 明載本期不實作角色授權，故尚無可限制參數／活動維護者的生產授權政策

5.2 結構性落差

#	落差	級別	說明
S1	參數讀取／事件消費的文件與實作漂移	L1	product.parameter.changed.v1 有生產端；CR-031 設計目的為快取失效，並確認 9 服務無快取；但其「各服務同步取值」文字與現行 Java 無下游 HTTP client／port 之檢索結果矛盾。事件無消費者目前不構成「快取失效缺陷」，真正前置工作是先落地至少一個業務參數消費路徑
S2	無節假日／工作日曆模型	L0	SCS-019 提及營業日曆需求，但現行 schema／程式無日期、地區、日曆版本及順延規則模型
S3	批次／結算／帳單參數未有統一權威	L1	部分 @Scheduled 使用服務屬性（可覆寫）而非程式常數；但排程觸發、作業業務日、結算窗口仍為服務級設定，沒有中央業務日曆／參數來源與統一變更稽核
S4	RBAC 授權政策未實作	L0	JWT 認證與 role claim 解析不等於授權；SCS-022 §6.3 明載本期未實作角色授權，參數維護 API 尚無角色／職責分離政策

5.3 小結

系統參數軸已有可用的 product.parameters 設定庫/API，但沒有證據證明它已驅動下游業務；
此外批次排程有服務級屬性、帳戶級結帳日也已有欄位，不能籠統稱作「全數硬編」。
真正缺口是統一的權威分類、業務日曆、跨域參數消費與人員授權。
★ 切入點不是「一口氣新增全體事件消費者」：先選一項業務能力（例如商品級額度策略）
完成規格 → API／port → 真實消費 → 改權威值之真機閉環；快取與事件失效僅在有快取且效能有量測需求時落地。
RBAC 及設定維護稽核必須先於將敏感參數維護 API 開放給業務角色。

---

6. 卡片級可用額度查詢之定位（★ BEAM PMO 特別提醒）

6.1 現況

• RFP 未載明「卡片級可用額度查詢」。
• CR-043 §3.1 已從 OpenAPI 清除未實作的卡片級端點宣告 GET /api/v1/cards/{cardId}/limits
  （端點數 96 → 95）。這只完成契約清理，不是卡片級查詢需求的實作或需求結案。
• 目前有帳戶級額度查詢 GET /api/v1/accounts/{accountId}/limits；其存在不代表已定義卡片／附卡／企業子額度的可用額度分攤。
• ★ BEAM PMO 2026-10-15 明示：RFP 未列、但客戶最終一定會要求；因此列為預期需求準備項，與 CR-043 契約清理分開追蹤。

6.2 定位建議（★ 不回復 stale 端點）

選項	說明	建議
A	回復已移除之 /cards/{cardId}/limits	✗ 不建議——原契約端點沒有實作及消費者，亦未定義查詢語意；不應直接復活
B	另立 WBS 預期需求項＋後續 CR，先凍結額度模型／卡片分攤口徑，再設計新端點	★ 建議

理由：卡片級可用額度本質是「商品組合 × 額度多維度」之消費端（§3 軸一）。
帳戶級額度查詢存在，但不等於卡片／附卡／企業子卡共用池的分攤已定義。
在 limit.model／shared_scope、卡片—帳戶關係、佔用／保留額展示口徑未凍結前，直接重建端點會產生語意不完整的回應。
故建議順序為：先凍結額度權威與多維度規格 → 實作消費閉環 → 依客戶口徑另立卡片級查詢 CR。

6.3 追蹤動作

1. 已在 GOV-006 2.4.4 登錄「預期需求：卡片級可用額度查詢」，與 CR-043 的契約清理分開追蹤。
2. 不在 gen_openapi.py 恢復該端點；正式需求需有新 CR／SCS／生成器規格，並依賴商品額度多維度模型。

---

7. 治理提案：三位一體之統一參數化架構

7.1 核心設計原則

「三軸治理一致、每一領域權威清晰、執行期消費可驗證」——不是把所有設定與規則塞進一張泛型表：

flowchart TD
    subgraph UP["上游權威（參數／規則持有）"]
        PS["product-service<br/>products / parameters<br/>商品能力與一般系統設定"]
        PR["pricing-service<br/>pricing rules<br/>費率／費用計算權威"]
    end
    subgraph CON["消費閉環（執行期行為驅動）"]
        LS["limit-service<br/>額度策略之消費端"]
        ST["statement<br/>帳單週期消費端"]
        PO["posting<br/>實際入帳端"]
    end
    subgraph DOWN["下游規則消費與活動聚合"]
        RW["rewards-service<br/>points rules + ledger<br/>點數計算與帳務權威"]
        CA["Campaign aggregate<br/>新增規格：資格／期間／疊加<br/>連結各域規則，不接管計算"]
    end

    PS -->|domain-owned synchronous API| LS
    PS --> ST
    PS --> PO
    PR --> LS
    PR --> ST
    PR --> PO
    LS --> RW
    ST --> CA
    CA -->|連結各域規則（不接管計算）| RW

注意：product.parameter.changed.v1 事件僅在快取實際存在、失效需求經量測後，作快取失效訊號；不把它當成所有業務行為的命令，也不把未定義的規則值塞入事件。

★ product.rule_sets 現況僅是資料表；是否升格為規則管理 API／執行引擎須經規格裁定。
節假日／批次排程／RBAC 亦應分別由日曆、作業調度、安全政策的權威模型承載，不能假設都適合用同一 JSON 參數。

7.2 三軸之治理動作

軸	治理動作	對應落差
軸一 商品組合	① 先對齊 SAD-002／CR-031 的同步取值設計與現行實作；② 為首個線上消費場景（建議商品額度策略）立 SCS，經 ProductPort 取版本化參數並真機證明改值改行為；③ 定義總額度／個別額度／共享範圍權威與一致性；④ 補借記卡測試 profile；⑤ RULE_SETS 只在規則語意、管理 API 與真實消費者確定後才接線	P1–P5
軸二 行銷活動	① 先立 Campaign aggregate（活動代碼／期間／受眾資格／疊加互斥／優先序／上限／稽核）；② Campaign 關聯 pricing／rewards 各自擁有的規則，不預設將規則搬進 product.rule_sets；③ 年費定價查詢升級到有明確幣別與收取／減免執行鏈；④ 里程與滿額禮先立語意、帳務與冪等規格再實作	M1–M4
軸三 系統參數	① 建工作日曆權威（地區／日期／日曆版本／順延規則）；② 對齊已存在的 statement_day 與 billing.cycle_day，禁止重複真相；③ 將批次「何時跑」與「業務日／業務參數」分離治理；④ 先補設定維護者之 RBAC／職責分離／變更稽核；⑤ 參數事件僅於快取存在且需失效時訂閱	S1–S4

7.3 建議優先順序（依「正確性 × 依賴 × 可驗收」排序）

批次	內容	理由
0：權威與安全	更正文檔與程式漂移；定義參數 owner／key schema／單位／生效日／稽核；先決定誰能維護參數（RBAC）	避免錯把文件意圖當已實作；不能先開放高影響設定寫入再補授權
甲：商品消費閉環	選一條商品能力（優先額度多維度）補 SCS、client/port、runtime 分支與 Oracle 真機改值實驗	以最小閉環證明 SYS-4 真能驅動業務，而非先鋪 9 個空消費者
乙：系統營運參數	工作日曆；帳單日權威映射；批次／結算作業業務日與排程設定分層	先處理會影響跨域日期計算與批次的共同基礎；採既有欄位／框架，不重複建模
丙：行銷活動	Campaign lifecycle + eligibility/stacking/priority/limits；連接 pricing／rewards 實際執行	需業務政策輸入與帳務、冪等、撤銷語意，先規格後開發（★ 政策已於 2026-10-15 由 BEAM PMO 核定，見 §8.2）
丁：預期需求準備	商品額度多維度完成後，另立卡片級可用額度查詢 CR 並真機驗證共享額度分攤	依賴商品／額度權威模型；本期不恢復 stale 端點
戊：擴充商品與規則	借記卡 profile、里程／滿額禮等增量能力	每項依客戶政策逐一形成可執行規則與追溯，不以一張泛型 JSON 表假裝完成

---

8. 待裁定事項

#	事項	建議／待決
D1	是否採納 §7 之治理原則與批次排序	★ 建議採納「單一權威、領域規則由各域持有、消費閉環逐項驗證」；不採一張泛型表／全體事件消費者的做法
D2	卡片級可用額度查詢之定位	★ 另立 WBS 預期需求準備項，待額度多維度與分攤語意凍結後另立 CR；不恢復 stale endpoint
D3	行銷活動實體與規則擁有者	★ 建 Campaign lifecycle／關聯模型；pricing 與 rewards 保留各自計價／點數規則權威。product.rule_sets 不直接升格為活動模型，除非後續規格證明語意適合
D4	軸一第一條消費閉環	建議先補規格與驗收案例；不直接改程式。首案可選商品額度策略，仍須確認 account/card/family/corporate 分層
D5	GOV-004／GOV-006 追蹤方式	新增 CR-045 治理工作包與卡片級查詢依賴項；GOV-004 需先對應確切 FR/NFR 後再追溯，避免創造不存在的需求編號
D6	參數寫入與人員安控先後	★ 建議先凍結維護角色／maker-checker／資料範圍；在授權政策落地前，不將參數／活動寫入 API 作為生產維護入口

8.1 不可由開發臆造之業務輸入

以下需客戶／產品／營運權責單位提供或核定；本文不預填政策值：

範疇	待確認內容
商品與額度	額度模型（單一／共享／子額度）、共用範圍、卡片／附卡／企業子卡扣用順序、總額度與個別額度核算式
行銷活動	年費及免年費條件、紅利／里程換算、滿額門檻與贈品履約、活動是否可疊加、撤銷／退款後回沖、活動預算與每戶上限
日曆與作業	權威節假日來源、地域／時區、遇假日之提前或順延規則、帳單日與批次窗口、清算結算日
人員安控	業務角色清單、角色來源、資料範圍、覆核人數、金額門檻、緊急權限與稽核保留期
卡片級額度查詢	客戶希望看到的卡片／帳戶／共享池口徑、附卡如何分攤、是否揭露保留額、權限與遮罩規則

---

8.2 行銷活動政策（BEAM PMO 2026-10-15 口述核定，對應 §8.1「行銷活動」六項）

★ 本節為客戶／產品權責單位核定之業務政策，非開發臆造；作為 SCS-026 Campaign 模型之權威語意來源。後續若政策異動，須由 BEAM PMO 重新裁定並升版本節。

#	政策項	核定內容
1	年費及免年費條件	① 聯名卡（co-brand）強制繳交年費，且銀行須提供對等福利（例：航空公司聯名卡 年費 20,000、給 50,000 里程）；其餘卡種第一年全免年費。② 第二年起依「年累計消費金額」或「年累計刷卡次數」擇一達標即減免。③ 偶發促銷：當月刷卡金額達門檻 → 次年免年費（視為一種限時 Campaign）。
2	紅利／里程換算	依**卡種／卡別（tier）**分級距：例 VIP 100 元 1 點、一般 200 元 1 點；里程亦採分級距換算。→ 屬 rewards-service 點數／里程規則權威（SCS-010）。
3	滿額門檻與贈品履約	滿額禮為季節性／百貨周年慶等常見促銷；門檻與贈品按卡種／卡別級距而異。→ 屬 Campaign 活動的一種類型，贈品履約由履約／通知路徑處理。
4	活動是否可疊加	關鍵參數與業務邏輯：活動可疊加或不可疊加皆為合法配置；必須以 Campaign 層級參數 stackable 顯式聲明，並定義疊加時的優先序（priority）與互斥群組（exclusion group）。
5	撤銷／退款後回沖	點數／里程類 → 一律回沖（reversal）；贈品類 → 多半以**「打呆帳」**處理（不主動追回實體贈品，僅作帳務沖銷／呆帳認列）。→ 回沖邏輯屬 rewards-service；打呆帳認列須有對應科目與稽核。
6	活動預算與每戶上限	活動設有總預算上限與每戶（per-household）參與／獲利上限，二者皆為 Campaign 參數。達上限即停止發放或進入候補。

★ 與 D3 治理原則一致：pricing-service（年費／免年費計算）與 rewards-service（紅利／里程累點與回沖）各自保留領域規則權威；SCS-026 之 Campaign aggregate 負責「活動生命週期、資格、疊加互斥、預算／上限、與各域規則之關聯」，不接管計算。

---

9. 附錄：查證證據（as-found）

★ 以下皆為 2026-10-15 以現行原始碼／規格／DDL 實查之結果（非抄舊結論）。

查證項	命令／來源	結果
商品參數表與產品表	Oracle 唯讀查詢：CC_PRODUCT.USER_TABLES／USER_TAB_COLUMNS	PRODUCTS／PARAMETERS／RULE_SETS 皆存在；PARAMETERS JSON／生效日欄位、RULE_SETS condition/action JSON 與型別欄位均在 DDL
商品參數 runtime consumer	全 backend 源碼檢索 api/v1/parameters／Product client／port	只找到 product-service 自身 Controller/Repository；未找到下游遠端呼叫程式
文件 vs 程式	SAD-002 §3、CR-029 §5、CR-031 §3.1 對照現行 Java	文件宣告同步依賴／9 個 client，但 CR-031 同段又稱 9 個服務無 ProductClient／ParameterPort；本次源碼掃描支持「無下游 client」，需更正文件，不能當作已實作
limit-service 商品客戶端	全 backend limit-service 源碼檢索	無 ProductClient／ProductPort；現有帳戶級／專用額度並未因此證明商品 capability 已被消費
product.rule_sets API／執行	Oracle DDL + 全 backend Java 源碼	表存在；無 RuleSet CRUD API／repository／RuleEngine，且 schema 無 product/campaign/effective-date link
參數變更事件消費	SCS-005 §7.1／全 backend 事件名檢索	product.parameter.changed.v1 有生產端、無消費端；CR-031 證實原規劃為快取失效，當時 9 服務均無快取
行銷活動模型	DDL＋全 backend Java 源碼檢索	無 campaign aggregate／資料表／管理 API／活動執行路徑
節假日／日曆	DDL＋全 backend Java 源碼檢索	未找到 holiday/business-calendar 模型；SCS-019 §4 僅要求時區與銀行營業日曆納入設計
帳單日	backend 全庫 statement_day／billing.cycle_day 檢索	CC_PARTY.ACCOUNTS.statement_day 已存在；billing.cycle_day 僅在 SCS-023，未發現商品參數消費
排程	backend 全庫 @Scheduled／fixedDelayString 檢索＋SCS-019	有服務級排程，部分屬性可覆寫；不是全部硬編，但亦非由統一業務參數／日曆權威治理
年費／幣別	Oracle CC_PRC.USER_TAB_COLUMNS、SCS-006 §6／§7.7、FeeService／FeeView	ANNUAL_FEE／FEE_WAIVER 與 FEE_AMOUNT 存在；fee endpoint 僅查詢設定、不計費；無 fee_name／currency 欄，顯示名按 enum 硬編、currency 固定 TWD
點數規則	RewardRuleService／RewardRuleRepository／AccrualService 源碼檢索	/reward-rules 可維護獨立規則；未找到累點流程消費 RewardRuleRepository 的路徑，故不是已閉環行銷規則
RBAC	SCS-022 §6.3＋認證/授權程式	JWT 認證／role claim 解析存在；角色授權與維護權限政策未實作
卡片級額度端點	CR-043 §3.1／gen_openapi.py	未實作端點已從契約清除（96→95）；這是契約修整，不是未來卡片級需求結案

---

10. 變更紀錄

版本	日期	變更
1.2	2026-10-15	§7.1 架構示意由 ASCII 圖改為 Mermaid flowchart（通過 validate_mermaid 語法檢查，0 錯誤）；原圖內事件注意事項改為區塊引用
1.3	2026-10-15	新增 §8.2 行銷活動政策（BEAM PMO 2026-10-15 口述核定六項：年費/免年費、紅利里程換算、滿額門檻、疊加、回沖/打呆帳、預算每戶上限），作為 SCS-026 Campaign 模型之權威語意來源；§8.1 行銷活動列標註已核定；§7.3 丙註記政策已到
1.1	2026-10-15	回訪事實查證後修正初版：把規格宣告的同步取參數與現行程式缺少下游 client 之矛盾明列；更正 annual fee／RewardRule 僅查詢／維護、不等於 runtime 消費；區分可覆寫之服務排程屬性與中央業務參數；補 Oracle DDL 實查、角色授權現況、域權威治理、客戶待輸入政策及 card-level 查詢的契約清理／預期需求分離
1.0	2026-10-15	初版——三軸盤點（L0–L3 判準）、落差總表、治理提案與優先順序（甲–戊）、待裁定事項、as-found 證據附錄