# GOV-006　任務追蹤清單（WBS）

| 項目 | 內容 |
|---|---|
| 文件編號 | GOV-006 |
| 版本 | **1.77**（2026-10-17：**2.4.4 定性更正＋`CR-051`／`CR-052` 開立（`#A-277`，BEAM PMO 核准）**——2.4.4 更正為「RFP 已列（FR §2.4(1)）、語意待凍結（`CR-052`）」；開立 `CR-051` 商店對帳單／`CR-052` 卡片級額度查詢（規格先行、不動程式）。前版 **1.76**（2026-10-16：**`CR-046` 受理——`campaign-service` 新建＋BR-16 載體抽象列為單一交付列車（#A-244）**；任務 C-0～C-11；同批鐵則。前版 **1.75**（2026-10-16：**WP2 2.4.2 依客戶 BRD 完成最大參數化設計（#A-243）**——`BRD-005` 納入版控、`SCS-026 → 2.0`（BR-01 要素 6→30 欄、覆蓋 BR-01～16）；2.4.2 ⬜→🟡 設計完成待核定。前版 **1.74**（2026-10-16：**WP2 2.4.1 閉環改採真 socket（#A-242）**——`ParameterClosedLoopIntegrationTest` 由 MockMvc 改為**嵌入式 Tomcat＋真 HTTP**，六例全過；★ 並更正 #A-241「沙箱代理」錯誤解釋（真因：本機 Tomcat 僅綁 IPv6、IPv4 迴路掛住 → 位址須用 hostname）。前版 **1.73**（2026-10-16：**WP2 2.4.1 閉環補強（#A-241）**——`product-service` 新增 `ParameterClosedLoopIntegrationTest`（真 Oracle ＋ 真 web 層）閉合 §7.14 驗收 ②／④／⑤；★ 動工前查證更正「待寫入路徑俱備」之過度保守註記（三者本地早已具備）。前版 **1.72**（2026-10-16：**WP2 2.4.2 Campaign 模型規格先行（#A-240）**——BEAM PMO 2026-10-15 核定六項活動政策（`CR-045 §8.2`），據以新建 `SCS-026` 行銷活動 Campaign 模型規格（草案，待核定）；`GOV-006 2.4.2` 由 ⬜→🟡 規格先行。前版 **1.70**（2026-10-15：新增 WP2 2.4「參數極大化三位一體」治理工作包（`CR-045` v1.1）：2.4.1 商品參數閉環／2.4.2 Campaign 規格／2.4.3 日曆與排程／2.4.4 預期需求之卡片級可用額度查詢；各項待 CR-045 裁定及外部政策輸入，不代表已核定或已實作。前版 **1.69**（2026-10-05：**★★ B1-c 執行計畫（`#A-169`）——含「只做完 `jdbc` 層到不了 80%」之規模認知**。★ **10 服務盤點**（未覆蓋 **1,675 行**；jdbc public 方法 **4～41**）。★★ **排序原則「先低複雜度，不先大缺口」**：**W1** `installment`(73/5)＋`pricing`(65/4) → **W2** `dispute`＋`merchant`＋`payment` → **W3** `statement`＋`posting` → **W4** `rewards`＋`card` → **W5** `authorization`(**326/41**，最大但最複雜、**最後做**)。★★ **誠實推估**：現況約 **55.9%** → B1 全完成約 **67%** → **距 80% 尚缺約 13 pp（≈1,950 行）** → **必須 B2（`rest` 480）＋ B3（`outbox`·`messaging`·`client`·`storage`·`scheduler` 1,109）一併**。★ 附**可複製配方**。**WBS 5.12 → 🟡**。**`TRP-003` → 1.3**。前版 **1.68**（2026-10-05：**★★ B1-b 落地——`limit-service` 剩餘 jdbc 層整合測試（`#A-168`）**。**`jdbc` 層 36.4% → 81.0%**（B1 前 **3.2%**）；`limit-service` 行覆蓋 **52.6% → 67.0%**、分支 43.7% → 51.4%；測試 **86 → 102（+16）**、0 失敗。★ 涵蓋 `JdbcOutboxRepository` **30/30**／`JdbcSpecialLimitTempAdjustmentRepository` **52/52**／`JdbcLimitAdjustmentRepository` **60/62**／`JdbcSpecialLimitPolicyRepository` **37/39**。★★ **測試抓到「我自己的理解錯誤」**（`outstandingMinor` 誤解為「已調高額」，實為「未回收額」）——**程式正確、斷言錯誤**；★ **這正是真機整合測試之價值：它會反駁你**。★ **防假綠**：條件類測試**各造 3～4 種近似情境、僅 1 種應命中**。★ **修訂誠實推估**：**一個服務 ≈ +2.0 pp** → 達 80% 需 **約 20～22 個服務**。**WBS 5.11 ✅；新增 5.13 ⬜（B1-b2 兩投影）**。**`TRP-003` → 1.2**。前版 **1.67**（2026-10-05：**★★ B1-a 落地——`jdbc` 層之真機整合測試（`TRP-003` 首個增量，`#A-167`）**。★ **先查證發現「加模板」早已完成**（`T_SERVICE_BUILD` 早已含 Testcontainers 四模組，17 服務皆有）→ **無需改建置檔**。★ **三個實測發現**：**(i)** **Spring Boot 4 測試切片已模組化**，`@JdbcTest` **不在** `spring-boot-starter-test` 內 → 改**純 JUnit 5 ＋ 手動 `JdbcTemplate`**；**(ii)** Testcontainers Oracle 之套件為 **`org.testcontainers.oracle`**；**(iii)** 映像**須用 `gvenzl/oracle-free`**（官方 `database/free` 不吃 `APP_USER`）。★★ **實測增益**：**`limit-service` 行覆蓋 40.7% → 52.6%（+11.9 pp）**；**`jdbc` 層 3.2% → 36.4%（+33.2 pp）**；`JdbcLimitRepository` **0/113 → 88/113**。**測試 69 → 86**；**全庫 1096 → 1113**、**行覆蓋 53.7% → 54.7%（+1.0 pp）**、0 失敗。★★ **誠實推估**：**一個測試類別 ＝ +1.0 pp** → 達 80% 需 **約 25～27 個**同規模類別。★ **避開一項量測陷阱**：單跑一個類別所得之模組覆蓋率**不可與基線比較**（**跨次比較須同一組測試**）。**`TRP-003` → 1.1**。前版 **1.66**（2026-10-05：**★ 覆蓋率提升：缺口分析 ＋ `TRP-003` 計畫（策略轉向：真機驗證自動化）（`#A-166`）**。**缺口分析**：501 類別／**6,936 未覆蓋行**；★ **依架構層**——**`jdbc` 2,833 行（40.8%）**／`application` 1,095／`model` 703／**`rest` 480**／**`outbox` 336**／`client` 316／**`messaging` 245**。★★ **關鍵洞察**：**「接觸外部之層」佔 63.8%**，業務邏輯層已健康（`application` 73.6%／`model` 80.8%）。★ **根因**：真機驗證為**人工 curl＋SQL、不進 JVM** → **JaCoCo 貢獻恆為 0**（★ 全庫 `@Disabled` **為 0**；`JdbcLimitRepository` 被測試提及 **0 次**）。★★ **策略轉向**：**不是多寫單元測試，而是把真機驗證自動化**（**一舉兩得**，且**不違反禁 mock**）。**B1～B5**；★ **B1 可行性已解風險**（Oracle Free 映像本機已有／Testcontainers 2.0.5 已備）。⚠️ **B1 動工前須先定**：Testcontainers 相依加**模板或個別服務**。**WBS 5.7 → 🟡**。前版 **1.65**（2026-10-05：**★ 版本核對工具落地（WBS 5.10，`#A-165`）——雙向防漂移**。★ 新增 **`spec/versions.yaml`**（**機器可讀之規格側單一真實來源**）＋ **`tools/verify_versions.py`**：核對 **① 規格 ↔ 實際**（Gradle catalog／`node_modules`／`java -version`）與 **② 規格 ↔ `CSP-006` 內文**（**防散文漂移**）。**fail-closed**（解析失敗／無法取得實際版本一律非 0）；**`--selftest`** 以人工樣本回測判定力（含**解析負樣本**）。`CSP-006` 新增 **§2.15**（載明**變更版本之四步強制流程**）。★★ **首次執行即抓到真實遺漏**：`CR-039` 之 `lz4` **已改實際、惟未回寫 `§2.14` 內文**——**證明「改了程式沒改文件」是常態，必須靠工具攔**。修正後 **12 項全數相符（exit 0）**。**WBS 5.10 ✅**。前版 **1.64**（2026-10-05：**★★ 前端依賴升版完成（`CR-040`，`#A-164`）→ ★★ 前後端依賴漏洞全數歸零**。**vite 5.4.21 → 8.3.2**／**react-router-dom 6.30.6 → 7.18.4**／**@vitejs/plugin-react 4.3.4 → 6.1.1**。★ **查證 8 項**：**5.x 線無修復版**（必須跨大版）／**plugin-react 必須成對升級**（6.1.1 peer `vite ^8`）／額外 peer 皆 `optional`／**改動僅 3 檔**且皆為 v7 不變之經典 API。**6 項驗證全通過**：實查版本 ✅／`tsc --noEmit` ✅／**`vite 8.3.2` 建置 781ms** ✅／★ **headless Chrome 渲染成功**（`#root` 3,741 bytes、8 個導覽連結）✅／**`npm audit` 0 漏洞** ✅／**無 unmet peer** ✅。★★ **併發現「規格 vs 實物落差」**：`CSP-006 §2.8` **原載「Vite 6.x／React Router 7.x」，實物為 5.4.21／6.30.6**——**規格宣告從未落實**（**編譯與建置都不會報**）→ 已更正並**新增 WBS 5.10**（版本表 vs 實物之核對）。**WBS 5.6 ✅（四支 CR 全完成）；新增 5.10 ⬜**。前版 **1.63**（2026-10-05：**★★ Jackson 10 個 HIGH 修補完成（`CR-038`，`#A-163`）＋ ★ 併修一個 6.25% 之間歇性測試缺陷**。★ **關鍵洞察**：Spring Boot 4.1.1 BOM **import 兩個** Jackson BOM（2.x／3.x）→ **覆寫「整個 BOM」（機制 B）** 而非逐個 artifact（★ 已證：`jackson-datatype-joda` 一起升到 3.1.7，逐個列會漏）。**2.21.5→2.21.7／3.1.5→3.1.7**；**HIGH 10 → 0**。★★ **驗證過程中發現並修正**：`AesGcmFieldEncryptorTest$NoLeak` **6.25% 隨機失敗**（實測 5.87%／2 萬次）——竄改 Base64 **末組**字元，其**低 2 位被丟棄** → 有時不改變任何 byte → 認證反而通過。**與 Jackson 無關**，係測試自身缺陷；修後實測 **0.00%**。★ **併自認一項流程錯誤**：CR-038 §4.1 初稿**在測試跑完前即填入「0 失敗」** → **已更正**（教訓：驗證結果一律等實跑完再填）。**WBS 5.6 → 🟡（前端＋lz4 待處理）；新增 5.9 ✅**。前版 **1.62**（2026-10-05：**★★ Tomcat 3 個 CRITICAL 修補完成（`CR-037`，`#A-162`）**。★ **查證推翻一條路**：Spring Boot 4.1.x **僅 4.1.0／4.1.1（無含修復之 patch）** → **「升 BOM」不可行** → 採 **`CSP-006 §2.14` 之依賴版本覆寫**（**只覆寫落後的那一個**）。**11.0.24 → 11.0.26**（`constraints` 機制；版本源於 `libs.versions.toml`）。**6 項驗證全通過**：解析版本 ✅／編譯 ✅／**1096 測 0 失敗（與基線一致）** ✅／**health 200 UP** ✅／**CRITICAL 3 → 0** ✅／**相依清單僅 3 行變動** ✅。★ **決定性證據**：jar 內打包 `tomcat-embed-*-11.0.26.jar`。**WBS 5.6 → 🟡（Jackson 10 HIGH＋前端 1 HIGH 待處理）**。前版 **1.61**（2026-10-02：**★★ N1 批次完成——覆蓋率與依賴漏洞首次量測（`#A-160`）**。**(1)** ★★ **覆蓋率基線：行 53.7%／分支 46.8%**（門檻 80%／70% → **未達**）；★ **已排除計法假象**（業界慣例排除法僅差 0.1 pp → 低覆蓋是真的缺測試）。**(2)** ★★ **依賴漏洞：後端 3 CRITICAL＋10 HIGH**（**Tomcat 11.0.24**→11.0.25；Jackson 2.21.5→2.21.7／3.1.5→3.1.7）、**前端 1 HIGH＋3 MODERATE**（vite／react-router）。**(3)** ★★ **`tools/verify_nfr.py` 證據矩陣：✅13／❌2／📄24／⚠️21**——60 小節中**只有 13 小節「跑過且過」**，24 小節僅止於設計。★ 準出 #1／#7 **由「無法判定」變為「已量測且未達」**（**這是進步**）。★ **工具開發中修正 3 個缺陷**（OSV batch 只回 ID／修復版本跨分支混收／初版以「有檔案」當證據＝**假綠**）。**WBS 5.5 ✅；新增 5.6／5.7／5.8 ⬜**。前版 **1.60**（2026-10-02：**★★ 視窗重啟後之完整性檢查 ＋ 產出 `TRP-002` NFR 驗證計畫（`#A-159`）**。**完整性檢查 10 項全通過**（`git fsck` 無損毀／工作區 clean／無空檔／編譯 OK／掃描器 0 命中／`validate_sql` 70 檔 0 違規）。⚠️ **服務行程因視窗重啟而停止**（非檔案毀損）→ **已列交接注意**。**`TRP-002`**：60 小節分三類——**Ａ 可本地 39（689 項／78.8%）／Ｂ 需外部 13（137 項）／Ｃ 需客戶 8（48 項）**。★★ **關鍵洞察**：**「未驗證」≠「都要等外部」**——近 8 成素材本機已備，過去一律記「未驗證」是**自我設限**。★★ **兩項新發現之工具缺口**：**覆蓋率從未量測**（未配置 JaCoCo → 準出 #1 無法判定）；**前端零測試框架**。**可立即做 8 ＋ 需補工具 6**；**N1～N5**。**WBS 新增 5.4 ✅／5.5 ⬜**。前版 **1.59**（2026-10-02：**★★ 8-6 之「繳款截止日」精確化（`CR-036`，`#A-157`）**。**問題**：推算式最長可高估近一個帳單週期，而帳單日（`ACCOUNTS.STATEMENT_DAY`）在 `CC_PARTY`——**跨 schema 不可讀**（`SAD-003`／`SQL-07`）。★★ **關鍵洞察**：精確值**在原理上**只有帳單出帳後才存在 → **正解不是「算得更準」，而是「在精確值出現時校正」**。**裁定：兩階段**——① 請款時調高（`DERIVED`）；② **帳單出帳時**以**權威 `paymentDueDate`** 覆寫為 `+7`、標記 `STATEMENT`，同步 `temp_end_date`（取**所有 OPEN 紀錄之最晚迄日**）。★ **歸屬條件**：僅 `raised_on ≤ 出帳日`（出帳日取信封 `occurredAt`，**不**由 `−25` 反推）。★ **契約無需變更**；架構變更僅 `SAD-004 §5.2` 之消費者 `notification` → `notification` ＋ `limit`。**真機 3 項**（含**負樣本**：出帳日早於調高日 → 不校正）：截止日 2026-11-10 → 迄日 **2026-11-17**、`temp_end_date` 同步。**69 測 0 失敗**。**`SCS-002` 1.11**。前版 **1.58**（2026-10-02：**★★ POC-8 之 8-6／8-7 落地——臨時額度串動（`CR-035` Phase 3，`#A-156`）→ ★★ POC-8 八項全數完成**。**生產端**：`posted.v1` 補**可選** `authorizationId`（來源欄位早已存在、**不升版**）。**消費端**：8-6（`PostingTransactionPostedListener`——★ **本服務原已列為該事件之消費者，惟從未實作**）＋ 8-7（併入繳款消費端、**窄埠**）。★★ **兩項關鍵設計**：**(i)** 8-7 **必須逐筆扣回**（**不得**將 `temporary_amount` 歸零——該欄可能同時承載**人工核准之臨時額度**）；**(ii)** `raiseTemporary` 為**相對增量**。★ **更正 `CR-035 §2.4`**：繳款截止日原載讀 `CC_STMT` 為**跨 schema**、**不可行** → 改為推算並標記 `DERIVED`。★★ **真機 6 項**（真實 Kafka）：請款 → **0 → 15000**（迄日 2026-11-03）；繳款 10,000 → **5000**；再繳 5,000 → **0** 且 `CLOSED`；專用池 `used_amount` **15000 → 0**。**64＋35 測 0 失敗**。**`SCS-002` 1.10／`SCS-007`／`SDD-001` 1.18**；**WBS 2.2.3e ✅**。前版 **1.57**（2026-10-02：**★★ POC-8 之 8-2 落地——「可設定上限」參數化（`CR-035` Phase 2，`#A-155`）＋ ★★ 折衷之處理**。**(i) 角色折衷移除**——`common-spring` 已有 `JwtRoleConverter` → 改由**伺服器自已驗證之權杖**決定角色（**不接受請求帶入**，**防提權**）；**(ii) 客層折衷保留但附四項證據**（`CC_LIM` 無產品欄位／`card` 與 `party` 之 ACL 皆不含 `limit`／`ACCOUNTS` 無客層欄位）。★★ **真機揭露之陷阱**：M2M 權杖之 realm roles 實為 `default-roles-cardcore`／`offline_access`／`uma_authorization`（**皆無區辨力**）→ 第一版把角色解析成 **`offline_access`**（**荒謬**）→ 改以 **`azp` 以 `cc-` 開頭**（與 `ServiceCallerAclManager` **同一判準**）優先。★ **兩個 fail-closed**：查無政策 → 拒絕；認證停用 → `UNVERIFIED`（須顯式設政策）。**真機 6 項**；**55 測 0 失敗**。**`SCS-002` 1.9／`SDD-001` 1.17**；**WBS 2.2.3d ✅** |。**(i) 角色折衷移除**——`common-spring` 已有 `JwtRoleConverter` → 改由**伺服器自已驗證之權杖**決定角色（**不接受請求帶入**，**防提權**）；**(ii) 客層折衷保留但附四項證據**（`CC_LIM` 無產品欄位／`card` 與 `party` 之 ACL 皆不含 `limit`／`ACCOUNTS` 無客層欄位）。★★ **真機揭露之陷阱**：M2M 權杖之 realm roles 實為 `default-roles-cardcore`／`offline_access`／`uma_authorization`（**皆無區辨力**）→ 第一版把角色解析成 **`offline_access`**（**荒謬**）→ 改以 **`azp` 以 `cc-` 開頭**（與 `ServiceCallerAclManager` **同一判準**）優先。★ **兩個 fail-closed**：查無政策 → 拒絕；認證停用 → `UNVERIFIED`（須顯式設政策）。**真機 6 項**；**55 測 0 失敗**。**`SCS-002` 1.9／`SDD-001` 1.17**；**WBS 2.2.3d ✅**。前版 **1.56**（2026-10-02：**★★ POC-8 之 8-3／8-5 落地——專用額度「可動用」了（`CR-035` Phase 1，`#A-154`）**。★ **在此之前專用額度「可設定但不能動用」**。**已完成**：`scope_ref`（MCC 用途範圍）／`limit_holds.special_limit_id`（池歸屬）／`findApplicable`（決定性選擇順序）／`increaseUsed`（**條件更新**，防併發超額）／釋放對稱回沖／新端點 `special-limits/applicable`／`authorization-service` 之三段式池選擇。★★ **`BR-04-01` 為結構性成立**（專用佔用完全不動 `account_limits`）；★ **Stand-in 期間專用池 fail-closed**。★ **真機 11 項**：8-3 之 `availableLimit` **不因專用佔用而減**、8-4 之卡人池**確有扣減**、8-5 → **DECLINED 51**。**WBS 新增 2.2.3c ✅／2.2.3d ⬜（8-2）／2.2.3e ⬜（8-6/8-7）**。**`SCS-002` 1.8／`SCS-001` 1.14／`SDD-001` 1.16** |。★ **在此之前專用額度「可設定但不能動用」**。**已完成**：`scope_ref`（MCC 用途範圍）／`limit_holds.special_limit_id`（池歸屬）／`findApplicable`（決定性選擇順序）／`increaseUsed`（**條件更新**，防併發超額）／釋放對稱回沖／新端點 `special-limits/applicable`／`authorization-service` 之三段式池選擇。★★ **`BR-04-01` 為結構性成立**（專用佔用完全不動 `account_limits`）；★ **Stand-in 期間專用池 fail-closed**。★ **真機 11 項**：8-3 之 `availableLimit` **不因專用佔用而減**、8-4 之卡人池**確有扣減**、8-5 → **DECLINED 51**。**WBS 新增 2.2.3c ✅／2.2.3d ⬜（8-2）／2.2.3e ⬜（8-6/8-7）**。**`SCS-002` 1.8／`SCS-001` 1.14／`SDD-001` 1.16**。前版 **1.55**（2026-10-02：**★★ 專用額度（POC-8）資料模型落地——`CR-014` 裁定 A′（接線既有 `SPECIAL_LIMITS`）並實作完成（`#A-153`）**。BEAM PMO「**請直接執行A選項**」。★★ **重大更正**：`CR-014 v1.0` 稱之為「**新表**」，**事實是該表早已存在**（`V1__baseline.sql` ← `SDD-001 §3.4`；`CR-001 §2.3` 亦已載明）——**根因＝「實測」只掃 Java、未掃 DDL**（同 `CR-033` 幽靈型）→ 裁定改為 **A′＝接線既有表**。★ **沿用既有值域即權威**（`purpose`／`status` 不自由化），**僅補 `currency`** ＋ **唯一索引 `uk_special_limits_active`**（防授權端**重複計算專用額度**）。★ **修正基準額度**：`SPECIAL` 之 `before` 原誤取主檔永久額度 → **覆核門檻會算錯**。★ **契約破壞性變更**：`SpecialLimitItem` → **`SpecialLimitView`**（定義視角），**併收斂孤兒 schema**；消費端為零 → **不另立 `v2`**。★★ **併同修正真機揭露之契約缺陷**：`POST /limit-adjustments` 之 `targetAmount` ↔ 契約 `amount` **不符**（依契約送件一律 **400**）＋契約**漏列必填 `applicantId`**。★ **真機 13 項**：含 **非快取證明**（繞過服務改 DB → 查詢立即反映）、**不佔卡人額度**（`account_limits` 全程未變）、到期排程約 40 秒。**`SCS-002` 1.7／`SDD-001` 1.15**（併補 1.14 漏列）／**`CR-014` 1.1**；**WBS 2.2.3b ✅**。★ 併辦：**`SCS-016` 1.8／`CR-034` 1.1**（廠商官方來信逐項核對——實作無需變更；確認 Email 網域驗證之聯絡管道 `service@newsleopard.tw`）。BEAM PMO「**請直接執行A選項**」。★★ **重大更正**：`CR-014 v1.0` 稱之為「**新表**」，**事實是該表早已存在**（`V1__baseline.sql` ← `SDD-001 §3.4`；`CR-001 §2.3` 亦已載明）——**根因＝「實測」只掃 Java、未掃 DDL**（同 `CR-033` 幽靈型）→ 裁定改為 **A′＝接線既有表**。★ **沿用既有值域即權威**（`purpose`／`status` 不自由化），**僅補 `currency`** ＋ **唯一索引 `uk_special_limits_active`**（防授權端**重複計算專用額度**）。★ **修正基準額度**：`SPECIAL` 之 `before` 原誤取主檔永久額度 → **覆核門檻會算錯**。★ **契約破壞性變更**：`SpecialLimitItem` → **`SpecialLimitView`**（定義視角），**併收斂孤兒 schema**；消費端為零 → **不另立 `v2`**。★★ **併同修正真機揭露之契約缺陷**：`POST /limit-adjustments` 之 `targetAmount` ↔ 契約 `amount` **不符**（依契約送件一律 **400**）＋契約**漏列必填 `applicantId`**。★ **真機 13 項**：含 **非快取證明**（繞過服務改 DB → 查詢立即反映）、**不佔卡人額度**（`account_limits` 全程未變）、到期排程約 40 秒。**`SCS-002` 1.7／`SDD-001` 1.15**（併補 1.14 漏列）／**`CR-014` 1.1**；**WBS 2.2.3b ✅**。★ 併辦：**`SCS-016` 1.8／`CR-034` 1.1**（廠商官方來信逐項核對——實作無需變更；確認 Email 網域驗證之聯絡管道 `service@newsleopard.tw`）。前版 **1.54**（2026-10-02：**★★ SureNotify Webhook 接收端完成——含簽章驗證、退信／投訴停用名單、寄送前攔阻（`#A-151`）**。BEAM PMO「同意選 (a)」＋提供完整 Webhook 文件。★ **安全裁定**：端點**免認證**（廠商取不到我方 JWT）→ **簽章驗證即唯一身分依據**；**未設金鑰一律拒收**（fail-closed）；**簽章不符 → 401**（回 200 會使「金鑰設錯」變成「**回報悄悄消失**」）；**已驗章之異常 → 200**（避免重試風暴）。★ **冪等鍵含 `timestamp`**（`open`／`click` 可合法重複）。★ **廠商文件型別不一致**（`bounce.type` 表列 number、範例為字串）→ **兩者皆容**。★ **真機驗證 8 項**（自簽 HMAC 模擬廠商 POST）：含 **寄送前攔阻**（通知 `FAILED`、未呼叫閘道）。**2.3.7 更新**；`notification-service` **105 測 0 失敗**。前版 **1.53**（2026-10-02：**★★★ 真實簡訊發送成功——通知鏈路完全打通（`#A-149`）**。BEAM PMO 提供門號 `<手機已遮蔽>`／`<手機已遮蔽>` → **兩封皆 `SENT` 且廠商事件紀錄為 `delivery`（3～4 秒送達）**，**收件人實機確認收到**。★ **完整端到端**：`notification-service` → 事件 → 排程 → `SureNotifyChannel` → **真實閘道** → **電信網路** → **真實手機**；**每一環皆有證據**（DB `SENT`＋日誌 `messageId`＋**廠商 `delivery` 事件**＋人工確認）。⚠️ **Email 卡在外部前置條件**：`HTTP 400 Invalid: sender domain unverified`（**需自有網域 ＋ DNS 驗證**）——程式已完備，**SMS 已完全打通、Email 仍阻塞**。★ **併修**：非 2xx 之失敗原因改為**優先取 `error` 欄文字**（原為原始 JSON）。⚠️ **NCC 實名制字樣**：種子 SMS 模板**皆未含**，上線前必須補。**2.3.7 狀態更新**。前版 **1.52**（2026-10-02：**★★ 通知發送通道解阻塞——SureNotify（電子豹）SMS／Email 真實通道接入並通過真實 API 往返驗證（`#A-148`）**。BEAM PMO 提供測試 API Key → **解除**鐵則 3 類真阻塞之一「**通知發送通道（僅發送）**」。**規格先行**：`CR-034`（計畫與裁定）／`SCS-016` **1.5**（§7.13 ＋ §8）。★ **資安硬性規定**：外部通道**不得**用 `ServiceClientHttpClient`（**一律附加出站 Bearer 權杖 → 對第三方洩漏內部憑證**）→ **獨立** HTTP 客戶端、**只帶 `x-api-key`**。★ **零破壞**（`supports()` 需 enabled 且金鑰非空 → 無金鑰自動退回 Log 通道）。★ **收件人**抽出 `RecipientResolverPort`（**預設誠實失敗、不假造**）。★ **真機三項**：無收件人→誠實 `FAILED`；**真實 API 往返**→廠商原文 `invalid address`（**未實際發送**）；`enabled=false`→退回 Log 通道 `SENT`。★ **實測揭露**：`failure` 文件寫物件、**真實為陣列**。★ **併修** `scan_scaffold` 對 `@FunctionalInterface` 之偽陽性（**含人工樣本回測：正樣本 5／負樣本 14，誤判 0**）。⚠️ **仍阻塞**：**Push／LINE**（廠商不支援）、**收件人來源**（需產品決策）、**NCC 實名制／網域白名單**（業務）。**2.3.7 ✅ 更新**。前版 **1.51**（2026-10-02：**批次 C `C-5` 其餘 8 條目全數結案（`CR-033`，`#A-146`）＋ `bff-web` 補 Bean Validation（`#A-147`）**。★★ **`C-5` 之結論出乎意料但重要**：8 條逐條查證後——**實作 1（`#3`＝`#A-143`）／裁定不做 7／待實作 0**；★★ **揭露「幽靈待辦」根因**（以 `git show 9937bd0` 為證）：該 8 條係依 **`CR-030` 之前**之 `SAD-004 §5.2` 盤點，`CR-030 §2 #5` 重寫權威清單時**已移除／改判**這些消費邊，**惟未回寫 `CR-029`**。★ **併揭露 8 處程式註解與規格不一致**（已修）與 **`SDD-003 §13/§14/§15` 之同步呼叫未實作**（**真缺口但非事件流**，阻塞為**會計科目設計**）。★ **`bff-web` 補 `spring-boot-starter-validation`**——根因為**產生器平台模板漏列**（領域服務模板則有），依「模板＋既有檔兩邊都動」修正；啟動 WARN 消失、**行為零變更**（真機複驗）。**規格先行**：`CR-033` 1.0／`CR-029` 1.2／`SAD-002` 1.2（併補建 §8 修訂記錄）／`SAD-004` 1.8／`SCS-010` 1.10／`SCS-011` 1.11／`SCS-012` 1.5／`SCS-013` 1.4。前版 **1.50**（2026-10-02：**「歸戶 360」頁（`/accounts`）完成——真實 Chrome 端到端驗證通過（`#A-145`）**。★ **三批閉環**：`#A-143`（事件投影）→ `#A-144`（BFF 聚合）→ **`#A-145`（頁面呈現）**；`CR-031 §4.5` 之「**有能力、沒人用**」**已解除**。**規格先行**：`CR-032`（計劃）＋ `SDD-007` **1.27 §5.4.31**（逐鈕／逐區塊定義）。★ **核心規則**：四區塊**各自獨立降級**，`UNAVAILABLE` **必須帶錯誤碼呈現**、**嚴禁以 0／空白代替**；**空狀態與不可用明確區分**。**WBS 1.3.2 完成**；側欄 **29 → 30 頁**；證據 **45 → 47 張**。**4.8 🟡（7 全鏈路；投影之第二消費路徑已可視化）**。前版 **1.49**（2026-10-01：**`bff-web` 之 `BffAccountOverview` 新增 `cards` 區塊（三 → 四區塊）——真機驗證通過（`#A-144`）**。★ **關鍵更正**：下游為 **`party-service`** 而非 `card-service`（`card` 無依歸戶列卡片端點／其 ACL 僅允許 `authorization`／歸戶讀模型由 `party` 持有）。**規格先行**：`SAD-004` **1.7**（§2.2.1 四區塊 ＋ 新增 **§2.2.1.1**）／`CR-031` **1.2**（§4.5）。**新增 WBS 1.3.2**（頁面消費待立 `SDD-007 §5.4.x`）。**4.8 🟡（7 全鏈路；投影新增第二消費路徑）**。前版 **1.48**（2026-10-01：**批次 C 剩餘項（`CR-031`）——`C-5`（`party` 卡片狀態投影）實作完成並真機驗證；`C-7`（參數快取）裁定暫緩（`#A-143`）**。★ **`C-5` 為架構上唯一解**（`card-service` 之 ACL 只允許 `authorization` → `party` 無法同步查卡況）；★ **真機 8 項含兩負樣本**（重複 `eventId`／較舊 `sequenceNo`）；★ **發現並修正跨服務種子不一致**（`party` 種子原自成一戶）；**`C-7` 暫緩之證據**：**實測 9 服務皆無參數快取**。**規格先行**：`CR-031` 1.1／`SAD-004` 1.6／`SCS-004` 1.2／`CR-029` 1.1。**4.8 🟡（7 全鏈路）**。前版 **1.47**（2026-10-01：★★ **`CR-027 §5` 十二項待裁定全數裁定（`CR-030`）並執行完畢（`#A-142`）**——改由**架構師**依 **4 條業界通則（P1～P4）** 直接裁定，**不再逐項回問**。★ **2 項為實證之真缺陷**：**#8**（`REFERRAL` 已佔額度卻不發射事件）、**#9**（未匹配／沖正撤銷額度恢復卻無事件 → **額度永久高估**）；另 **#12**（`card` 同聚合雙序號來源 → 靜默資料遺失）、**#15**（四服務主題命名）。**真機驗證**：REFERRAL 已發射且不建通知；沖正 → `used_amount` **0 → 200,000**。**規格先行**：`CR-030` 1.0／`SCS-001` 1.13／`SCS-002` 1.6／`SCS-003` 1.11／`SCS-008` 1.7／`CR-027` 1.7。**4.8 🟡（8 全鏈路）**。前版 **1.46****`CR-027` 批次 C（消費端）動工（`#A-141`）**——**新建 `CR-029`**（盤點 `SAD-004 §5.2` 22 條 ＋ `SAD-002 §3` 3 條；★ **排除 7/7 自投影之 `q_*`**；★ **揭露架構性重複**：3 條消費邊與既有同步呼叫重複 → `CR-027 §5 #16`）；**`C-1`／`C-2` 完成**（`payment.posted`／`statement.issued` → notification，**語意來源＝既有種子模板 `PAYMENT_RECEIVED`／`STATEMENT_ISSUED`**；依 `SAD-004 §5.3` 補**可選** `currency`；**真機驗證 ＋ 3 負樣本**）；★ **併通用化消費埠**（`EventConsumptionPort` ＋ `EventNotificationService` 基底）。**4.8 🟡（6 全鏈路）**。前版 **1.45****`CR-027` 批次 A-4 完成（`#A-133`～`#A-138`）**——**payload 已定義之 9 項事件全數打通**：`dispute.case.opened.v1`／`posting.transaction.posted.v1`／`.reversed.v1`／`statement.statement.issued.v1`／`rewards.points.accrued.v1`／`.redeemed.v1`／`merchant.settlement.submitted.v1`／`notification.sent.v1`（**皆真機驗證**，含冪等／退款／異常等負樣本）。★ **單測攔下 1 項語意缺陷**（`dispute` 之 `disputeType` 誤取程序類型軸）。★ **`#A-139` 更正 `#A-131` 根因**（實為本機 SSO 開啟 → 401，**非** ACL 403）並**補驗 `clearing`**。★ **`#A-140` 新增 `CR-027 §5 #15`**（Kafka 主題命名不一致）。**4.8 🟡（5 全鏈路 ＋ 13 僅生產端；已接 outbox 12／17）**。前版 **1.44**（2026-10-01：**`CR-027` 批次 B 完成（`#A-128`）**——`limit.hold.created.v1`／`.released` **生產端＋消費端**：auth 本地 `limit_holds` 投影**終於有餵養者**。★★ **動工前查證攔下關鍵風險**（stand-in 後送造成「同一筆佔用兩列 → 重複扣減」）→ **以 `authorizationId` 去重**（**真機負樣本驗證**）。★ **併修正 `JdbcLimitPort.availableLimit` 之超額風險缺陷**（漏計 `PARTIALLY_RELEASED`）。**規格先行**：`SCS-001` 1.12（§7.15）／`SCS-002` 1.5／`SDD-006` §4.2。**4.8 🟡（5 全鏈路 ＋ 3 僅生產端）**。前版 **1.43**（2026-10-01：**`CR-028` 新建——hold 事件群四項矛盾之化解（`#A-127`）**。**方法**：先取三項客觀證據（**全庫程式碼零引用**／payload **逐欄相同**／兩表**皆有 `AUTHORIZATION_ID`**）再定案。**定案**：**廢除 `authorization.hold.*`**、auth **同時訂閱** `limit.hold.*` 兩者、`limit.hold.created.v1` 補 `authorizationId`（**可選**、不升版）。**已執行 6 份文件修訂**（`SAD-002` 1.1／`SAD-004` 1.5／`SDD-006` 1.11／`GOV-001` 1.3／`SCS-002` 1.4／`CR-027` 1.3）。**程式碼零影響**。**→ 批次 B 規格障礙解除**。前版 **1.42**（2026-10-01：**`CR-027` 批次 A-2／A-3 完成（`#A-125`／`#A-126`）——批次 A 全數完成**。**A-2**：`authorization.authorization.approved.v1` → **notification-service 建通知**（`SCS-016` → 1.2 §7.9）；真機：授權核准 → 通知建立（`AUTH_APPROVED`、`SENT`、4 通道）；**併擴充 payload 2 可選欄位**（`cardNoMasked`／`merchantId`）。**A-3**：`card.card.issued.v1`／`card.token.bound.v1` 生產端（`SCS-003` → 1.10 §7.11／§7.12）；真機：兩主題自動建立、payload 逐欄一致。★ **再發現 2 項缺口** → `CR-027` → **1.2**（§5 #11／#12）。**4.8 🟡（4 全鏈路 ＋ 4 僅生產端）**。前版 **1.41**（2026-10-01：**W-2 推廣・`CR-027` 批次 A-1 完成（`#A-124`）**——`payment.payment.posted.v1` **生產端＋消費端**（**首條成對交付**）：payment-service（`V6__outbox.sql` ＋ 同交易寫 outbox ＋ relay）→ Kafka `cc.payment.payment.posted` → limit-service（`V5__event_consumption.sql`；**恢復額度** → `account_limits.used_amount`）。**真機**：繳款 200,000 → `used_amount` **500,000 → 300,000**；**冪等／亂序／溢繳下限／查無主檔**皆通過。★ **實作中再發現 2 項契約缺口** → `CR-027` → **1.1**（§5 #9／#10）。**4.8 🟡（3 全鏈路 ＋ 3 僅生產端）**。前版 **1.40**（2026-10-01：**W-2 事件流推廣至事件 #4／#5（`#A-122`）**——`limit.hold.created.v1`／`limit.hold.released.v1`（**僅生產端**）：`LimitEventFactory` 新增兩個信封產生器 ＋ `LimitApplicationService.hold()`／`release()` 同交易寫 outbox；併補 `LimitRepository.findHoldAccountId`。**真機**：建立佔用 30,000 → outbox → relay → Kafka；**部分釋放** 10,000 → 同上；payload 與 `SDD-006 §4.2` 逐欄一致。**4.8 🟡（2 全鏈路 ＋ 3 僅生產端）**。**併登**：**`CR-027` 新建（`#A-123`）**——事件流 W-2 推廣盤點，**揭露 8 項文件矛盾／缺口**（hold 事件方向／訂閱清單／payload 缺欄位／清單權威／`q_*` 語意／`declined.v1`／`REFERRAL`），**待裁定**；併提四批次排序建議。前版 **1.39**（2026-10-01：**W-2 事件流推廣至事件 #3（`#A-121`）**——`authorization.authorization.approved.v1`（**僅生產端**）：`V9__outbox.sql` ＋ `AuthorizeUseCase` 同交易寫 outbox ＋ relay → Kafka `cc.authorization.authorization.approved`。**真機**：`APPROVED` 件 → outbox 落列 → relay 發布 → 主題建立；**payload 與 `SDD-006 §4.2` 逐欄一致**。★ **負樣本揭露**：`REFERRAL`（已佔用額度）**不發射任何事件**（`isApproved()` 不含 `REFERRAL`）→ **待裁定**（`SCS-001 §10 #8`）。**4.8 🟡（2 全鏈路 ＋ 1 僅生產端）**。前版 **1.38**（2026-10-01：**W-2 事件流推廣至事件 #2（`#A-119`）**——`limit.limit.adjusted.v1`：limit-service（`V4__outbox.sql` ＋ 同交易寫 outbox ＋ relay）→ Kafka（`cc.limit.limit.adjusted`）→ authorization-service（`V8__limit_consumption.sql`；**冪等＋亂序** → `account_limit_caches`）。**真機**：`POST /limit-adjustments` → outbox → relay → 讀模型 `total_amount` 10,000→410,000；**冪等／亂序皆通過**。★ **併處理命名落差**（`V2` 之 `limit.limit.changed.v1` → 依 `SAD-004 §5.2`）。**4.8 🟡（2／16 事件）**。**併登**：**桶 C 解鎖「分流比例管理」（`#A-120`）**——`SCS-020` → 1.11（§9.12）、`SDD-007` → 1.26（§5.4.30）；gateway 自供 `GET`／`PUT /api/v1/gateway/split-ratio`。前版 **1.37**（2026-10-01：**`GOV-006` 4.8 W-2 第二片——卡片狀態事件「生產端」＋ relay（`#A-118`）**。**實作**：`V8__outbox.sql`（`SDD-001 §3.15` 形狀）＋ `OutboxPort`／`JdbcOutboxRepository`／`KafkaEventPublisher`／`OutboxRelayScheduler`／`OutboxRelayConfig`；`CardQueryService.transition` **同交易**寫 outbox。**真機（兩服務串測）**：`LOCK` → outbox 已發布 → 授權讀模型 `SUSPENDED|LOCKED|seq=1`；`UNLOCK` → **`ACTIVE|ACTIVE|seq=2|v=2`**。**4.8 🟡 → ✅（第一＋第二片，全鏈路）**。**未竟**：DLQ／消費延遲指標／事件重放；其餘 15 事件待補。前版 **1.36**（2026-10-01：**`GOV-006` 4.8 W-2 第一切片——卡片狀態事件「消費端」（`card.card.status-changed.v1` → `card_status_caches`）（`#A-117`）**。**缺口（實測）**：`V2__read_model.sql` 明文載明該投影，惟**從未有人餵養**（讀模型恆空，真機 BEFORE `count=0` 證實）。**規格先行**：`SAD-004` → **1.3**（§5.4 事件消費契約）＋ `SCS-001` → **1.9**（§7.12）。**實作**：`CardStatusProjectionService`／`Port`／`JdbcCardStatusProjectionRepository`（冪等＋亂序＋upsert 同交易）／`CardStatusChangedListener`；遷移 **`V7`**。**真機（真實 Kafka＋Oracle）**：發布事件 → upsert 成功；**冪等／亂序皆通過**。**4.8 標 🟡**。**未竟**：生產端（card-service 發射）與 `common-event` relay 待補。前版 **1.35**（2026-10-01：**`CR-026` 業務 KPI（營運總覽第二階段）（`#A-112`）**——4 統計端點（cards/stats＋card-applications/stats／authorizations/stats／disputes/stats）＋ bff `BffDashboard.business` 區塊 ＋ 前端「業務 KPI」第 4 盒。實作全綠（4 模組 `:test` 0 失敗、掃描器 0 命中、mermaid 0 錯誤、契約 0 錯誤）；前端 typecheck 0 錯誤。★ 自曝並更正 `CR-026 §4` 誤載端點數（card 11→12／auth 10→11 → 實為 9→11／9→10，以 `grep` 實測更正）。★ 真機驗證（對真 Oracle）與前端瀏覽器實測 deferred（Oracle(1521) 未起、docker 空；前端依 BEAM PMO 指示延後）。**SCS-003→1.8／SCS-001→1.7／SCS-012→1.3／SCS-020→1.9**）。前版 **1.34**（`SDD-007 §5.4.28`／`SCS-020 §9.11`（`GET /api/v1/bff/dashboard`）；契約 **87 端點**；側欄 26 → **27 頁**；**桶 C 31 → 30**、可交付終點 29 → **30 頁**。併修 `verify_contract_dto.py` 對非封套回應之誤判）。前版 **1.33**（2026-10-01：**桶 B 擴充——`/onboarding/review`／`/onboarding/approval` 移入（BEAM PMO 裁定）**；桶 B 9 → **11**、桶 C 33 → **31**；併更新樹狀圖／WP3／§3 下一步表。差異項（照會記錄／製卡送件）另立 CR）。前版 **1.32**（2026-10-01：**桶 C 就緒度重盤之文件同步（`#A-110`）**——①`SDD-007 §5.1` 頁數 **60 → 59**（逐列實測）；②桶 C **34 → 33**；③WP3「已實作 8 頁」→ **26 頁**、「餘 48 頁」→ **桶 C 33**、「可交付終點 20」→ **29 頁**；④樹狀圖／關鍵路徑同步；⑤**待裁定項**：`/onboarding/review`／`/onboarding/approval` 核心已由 `§5.4.9` 涵蓋，是否移桶 B 待裁定）。前版 **1.31**（2026-09-29：**`§4 #21` 結案 ✅——服務間呼叫改採 `ServiceClientHttpClient`（`CR-024`／`#A-100`）**。★ **原建議之修法方向經查證後修正**：原記「Feign 加 `RequestInterceptor`」**不正確**——`common-spring` **早已有** `ServiceClientHttpClient`（建構子**強制要求**非空之 `OutboundTokenProvider`，註解明載為杜絕「靜默不帶標頭 → 全部 401」，與 `CR-010` 同型），且 `statement`／`payment`／`posting` **皆用它**，**僅 `authorization-service`／`card-service` 用 Feign**（異類）。**真機驗證 4 項**：授權 **`APPROVED`**（修正前 `STANDIN`）／批次後送 **`{uploaded:3, remaining:0}`**（修正前 `{0,3}`）／`standin_upload_at` **全部寫入**（修正前恆空）／`LIMIT_HOLDS` **遠端確實收到佔用**。**`#A-98`／`#A-99` 自此真正閉環**。⚠️ **併登記 `C-45`**（`card-service` 之 `CreditReviewClient` 同型未竟））。前版 **1.30**（2026-09-24 收工：**★ 配合 BEAM PMO 指示「中秋節後要能無縫接軌」**——**§3 加註指向 `HANDOVER` 之「★ 節後開工指引」**（環境啟動／上次做到哪／**下一步第一動**／喚醒指令），並明訂「**下一步做什麼**」以 `HANDOVER` 指引與 `§📊 任務追蹤總表` 為準（本檔為 **WBS 排序**＝結構視角）。前版 **1.29**（2026-09-24：**WP3 `C-14` 批次九（1 頁）——桶 C 解鎖並完成 `/auth/stip` 離線授權與代授權（`#A-99`）**。**規格先行**：動工前查證攔下 `SCS-001 §7.7` 之**規格-實作落差**——三職責中「**查詢待補送佇列**」與「**批次手動上送**」**無端點可達** → 立 **`CR-023`** → 改產生器 → **重生契約（77 端點、驗證 0 錯誤）** → 實作 2 端點 → `SDD-007 §5.4.23` 逐鈕定義 → 頁面實作（**側欄 21 → 22 頁**）。**真機 4 項**：清單三值篩選正確（`PENDING` 含 `REFERRAL` 件——證明未以決策碼篩選）、批次後送 201 `{uploaded:0, remaining:3}`）。前版 **1.28**（2026-09-24：**★ 清單補正——WBS 收錄 `CR-021`／`CR-022` 之葉任務（2.2.6／2.2.7）＋ §4 #19／#20 結案 ＋ §3 排序建議更新為現況**。緣由：BEAM PMO 指出「應按工作清單逐步執行」→ 查證發現**本清單自身過期**：#19 仍寫「待裁定」而 `CR-021` 已於 09-23 執行完畢、#20 未反映 `CR-022` 之裁定與實作，且 **WP2 完全未收錄該兩 CR 之葉任務**（僅存於 §4 待裁定清單）→ **「照清單走」會漏**。**併補**：§3 明列現行主線為 WP3 `C-14`（桶 A 6 頁已完成；**桶 C 之 `/auth/stip` 因 `CR-022` 裁定並實作而解鎖**））。前版 **1.27**（2026-09-24：**`CR-022` (A) 後送 ＋ §7.8 人工／強制授權 ✅ 實作並真機驗證**（`HANDOVER §3.B #B-2` 之續接）。★ **實測揭露 `§4 #21` 之推論已失效**——`REFERRAL` 引入後「`decision=STANDIN`」與「`standIn=true`」**不再等價**，**本地代佔之轉人工件漏標 `standin_flag` → 永不後送**；已立 **`SCS-001 §7.7.1`** 明訂判定依據（依**佔用方式**）並修實作，**真機對照驗證**（修正前 `0` → 修正後 `1`）。`SCS-001` → **1.4**（§9 補 24 例單測＋7 項真機實測）；`CR-022` 狀態更新為已裁定並實作；**單元測試 17 → 41 例**）。前版 **1.26**（2026-09-23：**批次八——桶 C 解鎖 2 頁 ✅（授權策略檢核／沖正機制）**；可交付終點 **20 頁**、側欄 21 頁。⚠️ **版本欄於批次七續漏了同步**（修訂記錄已有 1.25 而版本欄停在 1.24），本版逕升 1.26）。前版 **1.24**（2026-09-23：**批次七——`CR-021` 兩支端點 ✅（check-results／reversals）、advices 待語意裁定**；⚠️ 發現 runtime 掛 `StandInLimitPort`（沖正 Stand-in 佔用之設計待裁定）；查無授權 500 → `CC-AUTH-4040`）。前版 **1.23**（2026-09-23：**批次六 ✅——資料遷移作業落地，★ 桶 A 六頁全數完成**；⚠️ §5.4.19 誤立撤銷（`/finance/gl` 實已由 §5.4.10 涵蓋→桶 B 9）；健康檢查與監控移桶 C（須 bff 聚合端點）；SCS-003 補齊 CR-020 規格。可交付終點 **18 頁**）。前版 **1.22**（2026-09-23：**`CR-021` 新建——authorization-service 三支契約端點完全未實作**；`SDD-007 §5.1.2` 桶 A 盤點錯誤自我更正（23 → **20 頁**）；G-8 擴充「端點存在性」檢查；批次五額度控管 ✅）。前版 **1.21**（2026-09-23：**`CR-020` 四項 ✅ 已裁定並執行完畢**（BEAM PMO 裁定「不得以 workaround 心態」→ 全部修根因）——V7 加 `CARD_APPLICATIONS.CARD_ID`、三要素確實驗證、冪等生效、查無卡片回 404、`status` 依 `SDD-005 §2.4` 映射同步；真機實測 9 項＋單測 10 例＋負樣本）。前版 **1.20**（2026-09-23：**WP3 `C-14` 批次四（2 頁）✅**——卡片生命週期管理／虛擬卡與 Token 管理；**桶 A 進度 4／11**；⚠️ **動工前查證以真機實測攔下四項缺陷** → **`CR-020` 新建**，並**新增 §4 #18**）。前版 **1.19**（2026-09-23：**WP3 `C-14` 批次三（2 頁）✅**——產品與費率設定／參數設定；**桶 A 進度 2／11**；依 `SDD-007 §5.1.2` 就緒度盤點修正 `C-14` 之工作量計法）。前版 **1.18**（2026-09-23：**`CR-019` 批 1 之 15 案 ✅ 已執行並真機驗證**——比對器 **19 處 → 2 處**；**新增 §4 #17**（`INSTALLMENT_PERIODS.AMOUNT` 設計意圖待確認）；#16 縮減為僅 C-1 待核定） |
| 性質 | **WBS（Work Breakdown Structure）**——工作分解、依賴關係與排序建議 |
| 建立者 | WorkBuddy AI（開發團隊），BEAM PMO 2026-09-22 指示「補上一份真正的任務追蹤清單（WBS type）」 |
| 對應需求 | 全案（R1／R2／R3 波次對應見各葉節點） |
| 關聯文件 | `HANDOVER.md §📊 任務追蹤總表`（**狀態唯一權威**）、`GOV-004`（需求追溯）、`GOV-005`（範疇三軸）、各 `SCS-00x`／`CR-0xx` |

> **⚖️ 本文件與 `HANDOVER` 追蹤表之分工（避免雙頭馬車）**：
> - **`HANDOVER §📊 任務追蹤總表`＝狀態之唯一權威**——完成率、實測證據、每日異動都在那裡。
> - **本文件＝WBS 結構**——把總表之任務**階層化**（階段 → 工作包 → 葉任務）、
>   標定**依賴與排序**，供「下一個做什麼」之規劃討論。
> - 葉任務一律**回指**總表之 `C-xx`／`#A-xx` 編號，**不重複記載狀態細節**；
>   兩者衝突時以 `HANDOVER` 為準。
> - ⚠️ `HANDOVER §0` 明載：追蹤清單升格 `GOV-006` **須先裁定 `GOV-001` 文件清冊**——
>   本文件已建，`GOV-001` 之納入**待 BEAM PMO 核定**（併 §3.C `#C-20`）。

---

## 1. WBS 總覽（階段 → 工作包）

```
BEAM 信用卡核心現代化
├── 1. 平台與基礎建設（platform）
│   ├── 1.1 共用模組（common-domain／spring／security／event／batch／saga）
│   ├── 1.2 api-gateway（路由／限流／分流）        ← ✅ 完成（#A-73）
│   └── 1.3 bff-web（聚合層）                      ← ✅ 首增量完成（#A-74）
├── 2. 領域服務（17 個，R1 → R3）
│   ├── 2.1 R1 核心帳務與交易（9 域）              ← ✅ 已完成並實測
│   ├── 2.2 R1 續作／補強（pricing 補強等）
│   ├── 2.3 R2／R3 域（7 個）                      ← ✅ **全數完成**（2.3.1～2.3.7，#A-76／#A-80～#A-85）
│   └── 2.4 跨域參數化（三位一體）                  ← 🟡 **CR-045：待裁定／規格先行**
├── 3. WebUI（作業台頁面）
│   ├── 3.1 已實作 **27 頁**（`SDD-007 §5.4.1`～`§5.4.28`，缺 §5.4.19）  ← ✅
│   └── 3.2 其餘頁面（`§5.1` 59 頁 − 已實作 18 ＝ **41 頁**：桶 B 11〔不另造〕＋桶 C 30〔待後端〕）  ← 🟡（2026-10-01）
├── 4. 橫切關卡（安全／觀測／驗證分工／品質掃描）
├── 5. 測試與驗收（TRR-001 擴充、POC 情境）
├── 6. 待 BEAM PMO 裁定清單
└── 7. 外部阻塞（不可本地解）
```

---

## 2. 工作包明細

### WP1　平台與基礎建設

| WBS | 葉任務 | 追蹤編號 | 狀態 | 依賴 |
|---|---|---|---|---|
| 1.1.1 | common-domain／spring／security／event／batch／saga 模組 | #A-62／#A-64／#A-68 等 | ✅ | — |
| 1.1.2 | 統一錯誤碼與 `GlobalExceptionHandler` | `CR-004` | ✅ | — |
| 1.1.3 | 服務間 `client_credentials`＋fail-closed | `CR-010`（#A-62） | ✅ | — |
| 1.1.4 | 服務間呼叫者身分＋端點白名單 ACL | `CR-011`（#A-63／#A-64） | ✅ | 1.1.3 |
| 1.1.5 | token-relay 模式（gateway/bff 轉傳使用者權杖） | #A-68 | ✅ | 1.1.4 |
| 1.1.6 | RAW 轉換 fail-loud（8/8 服務）＋回歸測試 | #A-71／#A-72 | ✅ | — |
| **1.2.1** | **api-gateway：路由（17 服務）** | **#A-73** | ✅ | — |
| **1.2.2** | **api-gateway：Redis 限流** | **#A-73** | ✅ | 1.2.1 |
| **1.2.3** | **api-gateway：分流 Cycle Split（熱更新／回退／LOG）** | **#A-73** | ✅ | 1.2.1 |
| 1.2.4 | api-gateway：影子比對（W0 並行驗證） | 新增（見 §4 排序） | ⬜ | 1.2.3＋W-2 |
| 1.2.5 | 閘道業務級授權（角色初篩） | `SAD-004 §2.1` | ⬜ | 1.2.1＋#C-34 |
| 1.3.1 | bff-web 首增量：`GET /api/v1/bff/accounts/{id}/overview` **四區塊**聚合（party／**cards**／limits／rewards）＋token-relay（裁切／快取續作） | **C-13**（首增量）／**`CR-031 §4.5`**（`cards` 區塊） | ✅ **#A-74**；✅ **四區塊 #A-144**（真機驗證通過） | 1.2.1 |
| 1.3.2 | **`BffAccountOverview` 之頁面消費**——**「歸戶 360」頁（`/accounts`）** | **`CR-032`**／`SDD-007 §5.4.31` | ✅ **`#A-145`**（**真實 Chrome ＋ Keycloak 端到端驗證通過**；側欄 29 → **30 頁**） | 1.3.1＋`SDD-007` |

### WP2　領域服務

| WBS | 葉任務 | 追蹤編號 | 狀態 | 依賴 |
|---|---|---|---|---|
| 2.1.1 | authorization（8081）／card（8082）／limit（8083）／party（8084） | #A-37 等 | ✅ | — |
| 2.1.2 | posting（8087）／payment（8088）／installment（8089）／rewards（8091）／statement（8092） | #A-61／#A-67 等 | ✅ | — |
| 2.1.3 | pricing（8086）：試算／費用／違約金 | `CR-005`（#A-30） | ✅ | — |
| 2.2.1 | pricing 規則 `TX_TYPE` 欄位 | **C-31** | ✅ **#A-77**（2026-09-22：V2 遷移＋回填；單測 53 例；真機 e2e 含改權威來源驗證；`SCS-006` 1.2／`SDD-001` 1.7／`CR-005` §8 #1 結案） | — |
| 2.2.2 | statement／posting ↔ pricing 之 Round-off／幣別一致性整合測試 | **C-32** | ✅ **#A-78**（2026-09-22：三方逐分一致 1066＝1066＝1066；並修復計息幣別硬編 TWD，USD 實證後還原；`SCS-006` 1.3／`SCS-011` 1.5／`SCS-007` 1.3） | 2.1.3 |
| 2.2.3a | limit 補專用額度**查詢**端點（`GET /accounts/{id}/special-limits`） | **C-11** | ✅ **#A-75** | — |
| 2.2.3b | 專用額度**資料模型**（`SPECIAL_LIMITS` 表＋apply 流程；POC-8-3/8-6/8-7 完整串接） | `CR-014` | ✅ **#A-153**（2026-10-02）——裁定 **A′：接線既有 `SPECIAL_LIMITS`**（**非建表**；該表由 `V1__baseline.sql` ← `SDD-001 §3.4` 早已存在，`CR-014 v1.0` 之「新表」誤述已更正）。**已完成**：`V6` 遷移（補 `currency` ＋ 唯一索引 `uk_special_limits_active`）／SPECIAL 寫入（`upsertActive`）／撤銷（`cancelActive`）／到期排程／查詢端點**改讀 `special_limits`**／`purpose` 值域檢核（`CC-LIM-1003`）／15 支單測／**真機 13 項**。★ **併同修正真機揭露之契約缺陷**（`POST /limit-adjustments` 之 `targetAmount`↔`amount` 不符、契約漏列必填 `applicantId`）。⚠️ **仍未實作**（另列）：`8-2` 角色／客層上限、`8-3`/`8-5` **授權端扣抵**、`8-6`/`8-7` 臨時額度串動、`scope_ref`（MCC）——見 `SCS-002 §10 #12～#15` | — |
| 2.2.3c | **POC-8 之 8-3／8-5：授權端扣抵與超額拒絕 ＋ `scope_ref`（MCC）** | `CR-035` | ✅ **#A-154**（2026-10-02，**Phase 1**）——★ **在此之前專用額度「可設定但不能動用」**。**已完成**：`V7`（`special_limits.scope_ref`＋`limit_adjustments.scope_ref`＋`limit_holds.special_limit_id`）／`findApplicable`（**決定性選擇順序**）／`increaseUsed`（**條件更新**，防併發超額）／釋放之**對稱回沖**／新端點 `special-limits/applicable`（★ `applicable=false` 回 200）／`authorization-service` 之 `SpecialLimitPort`＋**三段式池選擇**／`StandInSpecialLimitPort`（安全降級）／**真機 11 項**。★ `BR-04-01` 為**結構性成立**（專用佔用完全不動 `account_limits`）。**測試**：limit 41＋auth 65 測 0 失敗 | 2.2.3b |
| 2.2.3d | POC-8 之 **8-2：角色／客層上限（參數化權限）** | `CR-035 §2.3` | ✅ **#A-155**（2026-10-02，**Phase 2**）——`V8`（`SPECIAL_LIMIT_POLICIES`）＋ ★ **`CallerIdentityPort`（角色自**已驗證之權杖**，**折衷移除**）**＋ `apply()` 政策檢核（**fail-closed**）＋ `GET`／`PUT` 維護端點。★★ **真機揭露之陷阱**：M2M 權杖之 realm roles 實為 `default-roles-cardcore`／`offline_access`／`uma_authorization`（**皆無區辨力**）→ 第一版實作把角色解析成 **`offline_access`**（**荒謬**）→ 改以 **`azp` 以 `cc-` 開頭**（**與 `ServiceCallerAclManager` 同一判準**）**優先**判定服務權杖。**真機 6 項**（申請 ≤ 上限 → 201；> 上限 → **422 `CC-LIM-1002`**；上限調高 → 同一請求即通過）。⚠️ **客層仍由請求帶入**（四項證據）＋ **政策端點之權限未收斂** | 2.2.3c |
| 2.2.3e | POC-8 之 **8-6／8-7：臨時額度串動** | `CR-035 §2.4` | ✅ **#A-156**（2026-10-02，**Phase 3**）——`V9`（`SPECIAL_LIMIT_TEMP_ADJUSTMENTS`）＋ 消費 `posting.transaction.posted.v1`（**payload 補可選 `authorizationId`**，來源欄位早已存在、**不升版**）＋ 繳款 FIFO 回收（**窄埠** `TempAdjustmentRecoveryPort`）。★ **兩項關鍵設計**：**(i)** 8-7 **必須逐筆扣回**，**不得**將 `temporary_amount` 歸零（該欄可能同時承載**人工核准之臨時額度**）；**(ii)** 繳款截止日以「入帳日＋帳單週期(25)＋7」**推算**並標記 `DERIVED`——★ **更正 `CR-035 §2.4` 原設計**（原載讀 `CC_STMT` 為**跨 schema**、**不可行**）。**真機 6 項**（真實 Kafka ＋ Oracle）：請款 → 臨時額度 **0 → 15000**、迄日 **2026-11-03**；繳款 10,000 → **5000**、再繳 5,000 → **0** 且 `CLOSED`；專用池 `used_amount` **15000 → 0** | 2.2.3c |
| 2.2.4 | `UNMATCHED` 產生者（逾三日未收銷帳檔批次） | **C-19** | ✅ **#A-79**（2026-09-22：批次＋排程＋`reversible()` 放行；真機 e2e 含負樣本與沖正。⚠️ **新增待裁定**：轉換 6 之來源狀態——見 §4 #10） | — |
| 2.2.5 | `InstallmentView` 補 `principal_outstanding` 等欄位 | **C-24** | ✅ **#A-75** | — |
| 2.3.1 | product（8085，產品 CRUD＋參數版本化／熱更新；5 端點） | **C-2** | ✅ **#A-76** | — |
| 2.3.2 | merchant（8095，商戶／請款／對帳單；金鑰除外） | **C-4** | ✅ **#A-80**（2026-09-22：3 端點＋`CR-015` 雙軸拆分；單測 27 例；真機 e2e 7 項含 DB 複核。⚠️ 金額為 stand-in、狀態檢核未納入——見 `SCS-014 §10`） | 2.1.1 |
| 2.3.3 | clearing（8094，清算結算；檔格式除外） | **C-5** | ✅ **#A-81**（2026-09-22：3 端點＋`CR-016` 補齊契約所缺兩表；單測 24 例；真機 e2e 7 項含遷移前後對照與 DB 複核。⚠️ 檔解析／`TIMING`·`FX_RATE` 判別／觸發入帳未實作——見 `SCS-013 §10`） | 2.1.2 |
| 2.3.4 | dispute（8093，爭議；時限參數除外） | **C-6** | ✅ **#A-82**（2026-09-22：3 端點＋`CR-017` **爭議雙軸拆分**；單測 19 例；真機 e2e 6 項含雙軸同列獨立之 DB 複核。⚠️ 無結案端點／TIMELINES 未寫入／時限未參數化——見 `SCS-012 §10`） | — |
| 2.3.5 | report（8098，報表） | **C-7** | ✅ **#A-83**（2026-09-22：2 端點＋**Postgres 讀模型**（CQRS 讀側首例）＋批次投影＋非同步作業產生；單測 16 例；真機 e2e 6 項。⚠️ 物件儲存未部署／跨 schema stand-in／僅 1 報表 2 格式——見 `SCS-017 §10`） | 2.1.x |
| 2.3.6 | migration（8096，波次 W0–W4；狀態機待 `SDD-005` 正式化） | **C-8** | ✅ **#A-84**（2026-09-22：2 端點＋**兩層 wave＋job**；單測 17 例；真機 e2e 6 項含**試跑不動任何列 vs 非試跑標記**。⚠️ 資料源未接入／回退未實作——見 `SCS-015 §10`） | — |
| 2.3.7 | notification（8097，通知；**通道抽象先行**） | **C-9** | ✅ **#A-85**（2026-09-22：2 端點＋**`NotificationChannelPort` ＋ 本地 Log 通道 stand-in**；新增 3 錯誤碼；`SDD-005` 新增 §13 通知狀態機；單測 31 例；真機 e2e **12 項**含三種 422 **受理即擋**、**重試後 `FAILED`＋原因**、DB 複核）<br>✅ **#A-148**（2026-10-02：**`CR-034`／`SCS-016 §7.13`——SureNotify（電子豹）SMS／Email 真實通道接入**，**通過真實 API 往返驗證**）→ **「實際發送」已解阻塞**（SMS／Email）；★ **資安**：外部通道**不得**用 `ServiceClientHttpClient`（會洩漏內部 Bearer 權杖）→ 獨立客戶端、**只帶 `x-api-key`**；★ **零破壞**（無金鑰時自動退回 Log 通道）；★ **收件人**抽出 `RecipientResolverPort`（預設**誠實失敗、不假造**）<br>✅ **#A-149**（2026-10-02：**★★★ 真實簡訊發送成功**——`<手機已遮蔽>`／`<手機已遮蔽>` **皆 `delivery` 送達**（3～4 秒），**收件人實機確認收到**）→ **SMS 完全打通**<br>✅ **#A-151**（2026-10-02：**SureNotify Webhook 接收端完成**——簽章驗證／退信與投訴**停用名單**／**寄送前攔阻**；真機驗證 8 項）<br>⚠️ **仍阻塞**：**Email**（`Invalid: sender domain unverified`——需**自有網域 ＋ DNS 驗證**，**外部前置條件**）、**Push／LINE**（廠商不支援）、**收件人來源**（`party` 聯絡資訊端點，需產品決策）、**NCC 實名制字樣**（種子模板皆未含）、**多語未啟用**、**Webhook 之公開 URL**（廠商無法 POST 至 `localhost`）——見 `SCS-016 §7.13`／`§7.14`／`§8`／`§10` | 2.1.x |

| 2.2.6 | authorization：**`CR-021`** 三支契約端點補實作（`check-results`／`reversals`／`advices`） | **`CR-021`**（§4 #19） | ✅ **#A-95／#A-96**（09-23；`advices` 語意待裁定） | — |
| 2.2.7 | authorization：**`CR-022`** (A) 後送 ＋ `§7.8` 人工／強制授權（併 `§7.7.1` `standin_flag` 修正） | **`CR-022`**（§4 #20） | ✅ **#A-98**（09-24：真機 7 項；單測 17→41） | 2.2.6 |
| **2.4.1** | **參數極大化治理與第一條商品參數消費閉環**（權威邊界／key schema／維護授權；依裁定選商品能力，立 SCS 後真機證明改值改行為） | **`CR-045` D1／D4** | ✅ **L3 已驗證閉環**（#A-239＋#A-241＋#A-242：實作 `ProductParameterPort`＋同步 HTTP 配接器接入 §7.2 核准閾值；自動化閉環測試 ①＋③ 通過；#A-241/#A-242 於 product-service 新增 `ParameterClosedLoopIntegrationTest` 並改為**嵌入式 Tomcat＋真 socket** 閉合 ② PUT 落版／④ 非快取／⑤ businessDate 版控＋同交易 Outbox＋4 負樣本；A4 fail-closed 降級已落地。⚠️ ③之**跨進程**段（limit-service→product-service）尚待另立驗證） | `CR-045` |
| **2.4.2** | **行銷活動模型與域規則接合**（活動期間／資格／疊加優先序／上限；pricing／rewards 各守領域權威） | **`CR-045` D3** | 🟡 **設計完成待核定**（#A-240＋#A-243：客戶 BRD `BRD-005` 已到；`SCS-026 → 2.0`，BR-01 要素 6→**30 欄**、覆蓋 BR-01～16、十驗算範例為驗收基準；⚠️ `campaign-service` 為新建服務、BR-16 載體抽象須單獨立 CR 分期） | 2.4.1 |
| **2.4.3** | **系統營運參數**（工作日曆、批次／結算排程邊界、既有 `statement_day` 與商品帳單週期映射、設定維護授權） | **`CR-045` §5／§7** | ⬜ 待日曆／營運規則及安全政策輸入 | 2.4.1 |
| **2.4.4** | **RFP 已列需求：卡片級額度調額／查詢**（★ **定性更正 2026-10-17 BEAM PMO 核定**——RFP `FR.md §2.4(1)` 原文明列「歸戶、持卡人、**卡片**調額／**查詢**」，原「預期需求（非 RFP 明列）」記載**有誤**（`CR-050 §4` 揭露）；額度多維度／共享池分攤**語意待凍結**（**`CR-052`**），凍結後另立實作 CR；不復原 stale endpoint） | **`CR-052`／`CR-050` §4／`CR-043` §10.5** | ⬜ 語意凍結中（`CR-052` 待逐條裁定）；依賴額度模型與客戶口徑 | 2.4.1＋額度多維度規格（`CR-052`） |

### WP3　WebUI

| WBS | 葉任務 | 追蹤編號 | 狀態 | 依賴 |
|---|---|---|---|---|
| 3.1.1 | 已實作 **27 頁**（`SDD-007 §5.4.1`～`§5.4.28`，缺 §5.4.19）＝桶 A 6＋桶 B 對應 8＋桶 C 已解鎖 12（含 `/dashboard`）＋額外 `/limit-adjustments` 1 | `SDD-007 §5.4`／#A-67／#A-70／#A-72 | ✅ | — |
| 3.2.x | 其餘頁面（`SDD-007 §5.1` 實為 **14 群 59 頁**〔原載 60，2026-09-30 重盤修正〕；**★ 依 `§5.1.2` 2026-09-30 重盤計法**：**桶 A 6〔✅ 已完成〕／桶 B 11〔不另造〕／桶 C 30〔待後端〕** → **可交付終點 30 頁**，而非「59 頁全做完」；每頁先補 §5.4 逐鈕定義） | **C-14** | 🟡 **批次一（3 頁）→ #A-86**：清算與請款／爭議款處理／報表作業；**批次二（1 頁）→ #A-87**：**商店管理與請款**；**批次三（2 頁）→ #A-90**：**產品與費率設定／參數設定**；**批次四（2 頁）→ #A-91**：**卡片生命週期管理／虛擬卡與 Token 管理**；**批次五～八／桶 C 解鎖**：額度控管／資料遷移作業／授權策略檢核／沖正機制／離線授權與代授權／健康檢查與監控／稽核軌跡查詢／批次作業監控／端點與連線管理（**桶 A 6 全數完成 ＋ 桶 C 已解鎖 12〔含 `/dashboard`〕**）；**併依 BEAM PMO 裁定補列原型模組 9／10／12／13（4 群 14 頁）**——⚠️ 其中模組 12／13 之 6 頁**無對應本專案服務**，實作歸屬待 SoW 確認（見 #15）；**側欄 27 頁** | 各域 API |
| 3.3.x | `cardcore-webui-page` skill 持續固化（§5.4.x 同步紀律已補） | #A-72 ⑧ | ✅ | — |

### WP4　橫切關卡

| WBS | 葉任務 | 追蹤編號 | 狀態 | 依賴 |
|---|---|---|---|---|
| 4.1 | SSO：前端 PKCE＋17 服務接線 | `CR-010` 前 #A-29／#A-35／#A-36 | ✅ | — |
| 4.2 | 觀測三支柱（OTel／Prometheus／Loki／Grafana） | #A-27／#A-38 | ✅ | — |
| 4.3 | 驗證分工（控制器 @Valid／應用層語意） | `C-26`（#A-58） | ✅ | — |
| 4.4 | 品質掃描器（scaffold／mockdata／faketest／sql／mermaid） | `CR-001` 等 | ✅ | — |
| 4.5 | 結構化日誌 `total-size-cap` 上限 | **#C-30** | ✅ **已完成**（BEAM PMO 2026-10-01 裁定 **5GB**；**實測 19 個組態檔皆已設定**）——★ **本列為 2026-10-02 更正**（原記「⚠️ 待裁定」**與事實不符**，屬幽靈項） | — |
| 4.6 | SSO 常態啟用（fail-closed 全域） | **#C-34**（`SCS-022 §10 #12`） | ⚠️ 待裁定 | 4.1 |
| 4.7 | `KeyProvider` 是否推廣至無個資欄位之 13 服務 | **#C-21** | ✅ **已核定並結案**（BEAM PMO 2026-09-20：**13 個無個資欄位者不加金鑰**，**不納入交付**）——★ **本列為 2026-10-02 更正**（原記「⚠️ 建議『否』待核」**與事實不符**，屬幽靈項） | — |
| 4.8 | W-2 Kafka **事件流（生產端 ＋ 消費端）** | `SAD-004 §5`／POC-14 | 🟡 **生產端已就緒**：批次 A ✅／B ✅／**A-4 ✅（payload 已定義之 9 項事件全數打通）**。✅ **全鏈路 5**（授權核准／卡片狀態／額度佔用／額度異動／繳款入帳）；🟡 **僅生產端 13**（`card.issued`／`token.bound`／`product.parameter.changed`／`posting.transaction.posted`／`.reversed`／`statement.issued`／`rewards.points.accrued`／`.redeemed`／`clearing.batch.matched`／`dispute.case.opened`／`merchant.settlement.submitted`／`notification.sent`）。★ **已接 outbox 之服務：12／17**（`authorization`／`card`／`limit`／`payment`／`product`／`clearing`／`dispute`／`posting`／`statement`／`rewards`／`merchant`／`notification`）。**18 個 `cc.*` 主題就緒**。🟡 **消費端（批次 C）動工中**：**7 條全鏈路**（新增 `card.status-changed` → **`party`**（`CR-031 §2`，`#A-143`）；另 `payment.posted`／`statement.issued` → notification，`#A-141`）；**★ 計劃已立 `CR-029`**——盤點 25 條消費邊後發現**僅 2 條可立即做**，其餘分 `C-3`～`C-9` 共 7 批待裁定（**最大前提：`#16` 事件 vs 同步呼叫之重複**）。★ **`CR-031`（`#A-143`）**：**`C-5` 首項落地**（`party` 卡片狀態投影——**架構上唯一解**：`card-service` 之 ACL 只允許 `authorization` 呼叫）；★ **`#A-144` 之投影第二消費路徑**：`bff-web` 之 `BffAccountOverview` 新增 **`cards` 區塊**（下游＝`party` 之讀模型，**非** `card`）——**真機驗證通過**；**`C-7`（參數快取）裁定暫緩**（**實測 9 服務皆無參數快取** → 無快取可失效＝假綠），設計已立。⚠️ **未竟**：DLQ／消費延遲指標／事件重放；餘 **12 項事件之 payload 未定義**。★ **`C-5` 已全數結案（`CR-033`，`#A-146`）**——8 條逐條查證後：**實作 1（`#3`＝`#A-143`）／裁定不做 7／待實作 0**；★★ **揭露「幽靈待辦」根因**：該 8 條係依 `CR-030` **之前**之 `SAD-004 §5.2` 盤點，`CR-030 §2 #5` 重寫權威清單時已移除／改判，**惟未回寫 `CR-029`**（教訓：**重寫權威清單後須回寫以舊清單為基礎之盤點**）。★ **併揭露「同步整合缺口」**：`SDD-003 §13/§14/§15` 之同步呼叫（Rewards／Clearing／Dispute → Posting 分錄）**未實作**，阻塞為**會計科目設計**（外部輸入）——**非事件流**。⚠️ **動工前必讀 `CR-027`（v1.7）＋`CR-029`（v1.1）＋`CR-030`＋`CR-031`（v1.1）**：★★ **#5～#16（十二項）已全數裁定（`CR-030`）並執行完畢**——改由**架構師**依 **4 條業界通則（P1～P4）** 裁定；**不再有待裁定之架構問題**（僅餘 4 項**需外部輸入**：業務文案／卡組織規範／聯絡資訊端點／累點規則）。★ **併修正 2 項實證真缺陷**（#8 `REFERRAL` 佔額不發射；#9 未匹配／沖正未回沖額度）＋ #12（`card` 序號來源）＋ #15（主題命名）。 | — |

### WP5　測試與驗收

| WBS | 葉任務 | 追蹤編號 | 狀態 | 依賴 |
|---|---|---|---|---|
| 5.1 | 各域真實 Oracle 端到端實測 | 各 `SCS-00x §9` | ✅／進行中 | 對應域 |
| 5.2 | `TRR-001` 範圍擴充（**實為 17 領域服務 ＋ 8 平台模組 ＋ 26 頁 WebUI**，原載「其餘 8 域」與現況不符） | **C-25** | ✅ **已完成（`#A-108`）**——★ **本列為 2026-10-02 更正**（原記「⬜」**與事實不符**，屬幽靈項） | 各域完成 |
| 5.3 | POC 情境對照（POC-13 分流已部分達成） | `BRD-004` | 🟡 | 1.2.x／2.3.x |
| 5.4 | **`TRP-002` NFR 驗證計畫**（60 小節三分類：Ａ 可本地 39／Ｂ 需外部 13／Ｃ 需客戶 8） | `BRD-003`／`TRP-001 §6.2` | ✅ **`#A-159`**（2026-10-02）——★★ **關鍵洞察**：**「未驗證」≠「都要等外部」**（**689 項／78.8% 素材本機已備**）。★ **兩項新發現之工具缺口**：★★ **覆蓋率從未量測**（`backend` 未配置 JaCoCo → 準出 #1 無法判定）；★ **前端零測試框架**。**可立即做 8 項 ＋ 需補工具 6 項**；執行順序 N1～N5 | 5.1／5.2 |
| 5.5 | **`TRP-002` 之 N1 批次：補工具缺口**（JaCoCo 覆蓋率／依賴漏洞掃描／`verify_nfr.py`） | `TRP-002 §7.2` | ✅ **`#A-160`**（2026-10-02）——★ **覆蓋率首次量測：行 53.7%／分支 46.8%**（門檻 80%／70% → **未達**；已排除計法假象）。★ **依賴漏洞：後端 3 CRITICAL＋10 HIGH**（Tomcat 11.0.24／Jackson）、**前端 1 HIGH＋3 MODERATE**。★ **`verify_nfr.py` 證據矩陣：✅13／❌2／📄24／⚠️21**。**產出 `CSP-005 §4.1～§4.3`／`TRP-002 §11`／`docs/08-evidence/` 2 份** | 5.4 |
| 5.6 | **依賴漏洞修補**（Tomcat ✅／Jackson ✅／lz4 ✅／前端 vite＋react-router ✅） | `CSP-005 §4.3`／`CR-037`～`CR-040` | ✅ **`#A-162`～`#A-164` 全數完成**——★ **後端 CRITICAL／HIGH／MODERATE 全為 0；前端 `npm audit` 0**。**四支 CR**：`CR-037`（Tomcat 3 CRITICAL）／`CR-038`（Jackson 10 HIGH）／`CR-039`（lz4 1 MODERATE）／`CR-040`（前端 1 HIGH＋3 MODERATE）。★ 每支皆走「查證 6～8 項 → 立 CR → `CSP-006 §2.14` 載明 → 覆寫 → 6 項驗證」。⚠️ **滲透測試**仍屬外部環境（`TRP-002 §5`） | 5.5 |
| 5.9 | ★ **測試穩定性缺陷修補**（`AesGcmFieldEncryptorTest$NoLeak` 之間歇性失敗） | `CR-038 §4.2`／`#A-163` | ✅ **`#A-163`**（2026-10-05）——★ **6.25% 隨機失敗**（實測 5.87%／2 萬次）：竄改 Base64 **末組**字元，其**低 2 位被丟棄** → 有時不改變任何 byte。**修法**：改竄最後一段**首字元**（6 位元全有效）→ 實測 **0.00%**。**修正後連跑 12 次全過** | 5.5 |
| 5.10 | ★ **規格版本表 vs 實物之核對**（`CSP-006 §2.8` 原載 Vite 6.x／React Router 7.x，實物為 5.4.21／6.30.6） | `CR-040 §2`／`CSP-006 §2.15` | ✅ **`#A-165`**（2026-10-05）——★ 新增 **`spec/versions.yaml`**（**機器可讀之規格側單一真實來源**）＋ **`tools/verify_versions.py`**（核對 **① 規格↔實際**、**② 規格↔`CSP-006` 內文**，**雙向防漂移**；**fail-closed**）。★★ **首次執行即抓到真實遺漏**：`CR-039` 之 `lz4` **已改實際、惟未回寫 `§2.14` 內文**。**`--selftest`** 以人工樣本回測判定力（含解析負樣本）。修正後 **12 項全數相符（exit 0）** | 5.5 |
| 5.7 | **覆蓋率提升**（行 53.7% → 80%／分支 46.8% → 70%） | `CSP-005 §4`／**`TRP-003`**／**`TRP-004`** | ✅ **行覆蓋達標並超額**（`#A-205` 10-06）：★★ **全服務行覆蓋 `82.42%`**（10,331/12,535；★ 門檻 10,028，**超出 303 行**）。⚠️ **分支覆蓋 `64.33%`（門檻 70%）——未達**（見 **WBS 5.31**）。★ **歷程**：53.7%（B1 前）→ 64.1%（B2）→ 67.0%（W3）→ 70.3%（W4）→ 71.4% → 72.1% → 73.7% → 74.4% → 75.2% → 75.7% → 76.6% → 77.5% → 78.6% → 79.1% → 79.74% → 80.18% → **82.42%**。★ **根因**：本專案之**真機驗證為人工 `curl`＋SQL，不進 JVM** → **對 JaCoCo 貢獻恆為 0**（★ 已查證：全庫 `@Disabled` **為 0**）。★★ **策略不是「多寫單元測試」，而是「把真機驗證自動化」**——**一舉兩得**，**且不違反禁 mock**。★ **總結見 `TRP-004`（v1.1）** | 5.5 |
| 5.11 | ★ **B1-b：`limit-service` 剩餘 jdbc 層** | `TRP-003 §5.2 #6` | ✅ **`#A-168`**（2026-10-05）——★ **`jdbc` 層 36.4% → 81.0%**（B1 前 **3.2%**）；`limit-service` 行覆蓋 **52.6% → 67.0%**；測試 **86 → 102（+16）**、0 失敗。★ 涵蓋 `JdbcOutboxRepository` **30/30**／`JdbcSpecialLimitTempAdjustmentRepository` **52/52**／`JdbcLimitAdjustmentRepository` **60/62**／`JdbcSpecialLimitPolicyRepository` **37/39**。★★ **測試抓到「我自己的理解錯誤」**（`outstandingMinor` 誤解） | 5.7 |
| 5.12 | ★ **B1-c～：其餘 16 個服務之 `jdbc` 層** | `TRP-003 §6` | ✅ **實質完成（`#A-170`～`#A-213`）**——★ W1～W5 全數打通 ＋ 批次 3～17 續推。★★★ **全服務行覆蓋 `90.92%`／分支 `71.64%`**（**兩項門檻皆達標**）。★ 計畫原文（保留供追溯）：🟡 **計畫已立（`#A-169`）**——★★ **10 服務盤點**（未覆蓋 **1,675 行**；jdbc public 方法 **4～41**）；★★ **排序原則「先低複雜度，不先大缺口」**：**W1** `installment`(73/5)＋`pricing`(65/4) → **W2** `dispute`＋`merchant`＋`payment` → **W3** `statement`＋`posting` → **W4** `rewards`＋`card` → **W5** `authorization`(326/41，**最大但最複雜，最後做**)。★★ **誠實推估：只做完 `jdbc` 層仍到不了 80%**（約 **67%**）→ **必須 B2（`rest` 480 行）＋ B3（`outbox`·`messaging`·`client`·`storage`·`scheduler` 1,109 行）一併** | 5.11 |
| 5.14 | ★ **B2：`rest` 層之 `@WebMvcTest` 切片測試**（★ 併**回頭補** `AuthorizationController` 76 行） | `TRP-003 §6.7`／`§6.8` | ✅ **`#A-180`～`#A-183`**（2026-10-05）——★★★ **回頭補：`AuthorizationController` 未覆蓋行 76 → 0**（**行覆蓋 100%**；服務 36.3% → 43.5%）。★★★ **橫向複製至 16 服務／25 個 `@WebMvcTest`／130 條測試**（★ 範圍由計畫之「11」更正為 **16**）。★ **全量 1,063 測／0 失敗／2 略過**；**全服務行覆蓋 64.1%**。★★★ **實測揭露三真缺陷**：`#A-184`（`ResponseStatusException` 未處理 → 應 404 實回 500）／`#A-185`（★ **Jackson 3 預設 `FAIL_ON_NULL_FOR_PRIMITIVES=true`**）／`#A-186`（部分 `@RequestBody` 缺 `@Valid`）——**待裁定** | 5.12 |
| 5.15 | ★ **`CR-041`：B2 實測揭露之請求層三項發現之裁定與修補** | `CR-041`／`CSP-001 §7.2` | ✅ **`#A-187`**（2026-10-05）——★★★ **逐項以「契約實查」為據裁定**：**`#A-184`＝真缺陷→修**（`GET /cards/lookup` 查無由 **`500`** 改 **`404` `CC-CARD-4040`**）；**`#A-185`＝★ 更正為「非缺陷」**（契約列該等欄位為 **`required`** → 省略即 400 **正確**；Jackson 3 之嚴格**符合契約**）；**`#A-186`＝真缺陷→修**（`reverse`／`advise`／`parameters`／`products` 補 `@Valid`；★ 併消除 `reverse` 之 **NPE→500** 路徑）。★ **併立 G-9／G-10**（`CSP-001 §7.2`；**掃描器待實作**）。★ **全量 1,361 測／0 失敗／1 略過**；掃描器全 0 命中。⚠️ **如實揭露**：`verify_contract_dto` 有 4 處**既有**契約不符（**非本 CR 引入**） | 5.14 |
| 5.16 | ★ **`W3`：`statement`／`posting` 之 `jdbc` 層真機整合測試** | `TRP-003 §6.9` | ✅ **`#A-188`／`#A-189`**（2026-10-05）——**2 類別（4 `@Nested`）／21 測**；★ **四個 jdbc 類別全數 100%**（`JdbcStatementRepository` 0/102→100%、`JdbcStatementRunRepository` 0/46→100%、`JdbcTransactionRepository` 0/89→100%、`JdbcBalanceRepository` 0/42→100%）；`statement` 行覆蓋 **51.7% → 73.7%**、`posting` **64.8% → 83.5%**。★★ **真機反駁我方測試**：`TRANSACTIONS.idempotency_key` 具**全域 `UNIQUE`** → `findDuplicates` 至多 1 筆（初版測試試造「同鍵不同歸戶」會違反約束，已修正並註記）。★ 併查 `value_date` 為 `NOT NULL`。★★ **全服務行覆蓋 64.1% → 67.0%**；全量 **1,088 測／0 失敗／1 略過**；掃描器全 0 命中 | 5.12 |
| 5.17 | ★ **`W4`：`rewards`／`card` 之 `jdbc` 層真機整合測試** | `TRP-003 §6.10` | ✅ **`#A-190`／`#A-191`**（2026-10-05）——**2 類別（10 `@Nested`）／39 測**；★ **9 個 jdbc 類別中 6 個達 100%**（`JdbcPointsRepository` 0/95→100%、`JdbcCardApplicationRepository` 0/55→100%、`JdbcTokenRepository`／`JdbcCardNumberPool`／`JdbcIdempotencyStore`／`RawIds` 皆 100%）；`rewards` 行覆蓋 **58.7% → 79.8%**、`card` **70.6% → 89.4%**。★★★ **真機反駁我方三個假設**：`POINTS_EXPIRY_BUCKETS` 之 **`CHECK (points > 0)`**、`save` **不寫 `card_id`**（`CR-020` F1）、`Timestamp.from` **遺失 offset**。★ 併查得一致性瑕疵（`findAvailable` 未修剪 `CHAR(8)`，**無功能影響**）。★★ **全服務行覆蓋 67.0% → 70.3%**；全量 **1,127 測／0 失敗／1 略過**；掃描器全 0 命中。★ **jdbc 層幾已見底**（僅 9 條不可達之防禦分支） | 5.16 |
| 5.18 | ★ **`B4`／`B3-b`／大戶 之續推計畫與批次 1** | `TRP-003 §6.11` | 🟡 **`#A-192` 計畫已立；`#A-193` 批次 1 完成**——★ **先更正前輪錯誤敘述**（「jdbc 幾已見底」不成立，實餘 **935 行**）；★ **精確盤點 3,347 行**（model 393／application 814／scheduler 88／storage 118／messaging 217／client 251／jdbc 935）；★ **批次排序依「每行覆蓋之成本」**。★ **批次 1**：`party` **23.7% → 44.0%**、`rewards` **79.8% → 82.1%**；★★ **全服務行覆蓋 70.3% → 71.4%**；**1,152 測／0 失敗／1 略過**。⚠️ **餘下約 2,400 行尚待續作**（多批次工程） | 5.17 |
| 5.19 | ★ **批次 2（`B3-b-1`）：`infrastructure/scheduler` 8 個排程類別** | `TRP-003 §6.11.6` | ✅ **`#A-194`**（2026-10-05）——★ **scheduler 層 88/88 → `100%`**（`TemporaryLimitExpiryScheduler` 15/15、`ReportProjectionScheduler` 13/13，其餘各 10/10）；8 個測試類別／**17 測**。★★ 核心測試點：**例外不得外溢**（Spring `@Scheduled` 拋例外將**取消後續排程**）；併測 limit 之**兩個 try/catch 各自獨立**與 report 之 **`daysBack` 下限 1**。★★ **全服務行覆蓋 71.4% → 72.1%**；**1,170 測／0 失敗／1 略過**；掃描器全 0 命中。★ 本批 +90 行 | 5.18 |
| 5.20 | ★ **批次 3（大戶 jdbc 首發）：`JdbcAuthorizationRepository`** | `TRP-003 §6.11.7` | ✅ **`#A-195`**（2026-10-05）——★ **全庫最大單一 jdbc 缺口（162 行）→ `162/162` ＝ `100%`**；`authorization-service` 行覆蓋 **43.5% → 59.4%**（+15.9 pp）；`AuthorizationRepositoryIntegrationTest`（**17 測**，涵蓋 **19 個方法**）。★★ **全服務行覆蓋 72.1% → `73.7%`**——★ **本批 +195 行（單批最大增益）**；**1,187 測／0 失敗／1 略過**；掃描器全 0 命中。★★★ **真機反駁我方三項語意錯誤**（DECLINED 不佔額度／`PendingStandIn.authorizationId` 非 holdId／`IS NOT NULL` 條件） | 5.19 |
| 5.21 | ★ **批次 4（大戶 jdbc）：`party-service` 之 `JdbcPartyRepository`＋`JdbcAccountRepository`** | `TRP-003 §6.11.9` | ✅ **`#A-196`**（2026-10-05）——`JdbcAccountRepository` **0/32 → `100%`**；`JdbcPartyRepository` **37/41**（餘 4 為 `parseFlags`／`serializeFlags` 之**不可達 catch**）；`party-service` 行覆蓋 **44.0% → 59.6%**。★★ **全服務行覆蓋 73.7% → 74.4%**（本批 **+92 行**）；**1,194 測／0 失敗／1 略過**；掃描器全 0 命中。★ 驗證 `flags` JSON 往返、兩處樂觀鎖、`BLOCK_CODE_HISTORY` append-only、他歸戶排除。★ **完全不打 mock** | 5.20 |
| 5.22 | ★ **批次 5（大戶 jdbc）：`clearing-service` 之兩個 repository** | `TRP-003 §6.11.10` | ✅ **`#A-197`**（2026-10-05）——**兩個 repository 皆 `33/33 → 100%`**；`clearing-service` 行覆蓋 **65.7% → 81.5%**。★★ **全服務行覆蓋 74.4% → 75.2%**（本批 **+99 行**）；**1,202 測／0 失敗／1 略過**；掃描器全 0 命中。★ 驗證 `findRecent` 之 **ROWNUM 陷阱**、樂觀鎖（`IllegalStateException`）、`findByOrgAndDate` 兩維度防假綠。★ 動查發現 `SETTLEMENTS.DIRECTION` 係 **V2 新增** | 5.21 |
| 5.13 | ★ **B1-b2：兩個付款投影 repository**（`JdbcPaymentPostedProjectionRepository`／`JdbcPaymentReoccupyProjectionRepository`，各 17 行） | `TRP-003 §5.4`／`§6.11.11` | ✅ **`#A-198` 結案**（2026-10-05）——★ 自 `#A-168` 起**延後兩輪**（理由：語意為「事件消費之冪等投影」，需與事件語意一起設計）。★ **兩個皆 `17/17 → 100%`**；以**真實 `JdbcLimitRepository`** 為協作者（無 mock）。★★★ **核心不變式「已記＝已套用」**（套用失敗時不得寫 `consumed_events`，否則重放永久漏套用） | 5.11 |
| 5.23 | ★ **批次 6（大戶 jdbc）：`limit-service` 之兩個付款投影 repository** | `TRP-003 §6.11.11` | ✅ **`#A-198`**（2026-10-05）——**兩個投影 repo 皆 `17/17 → 100%`**；`limit-service` 行覆蓋 **73.1% → 78.5%**。★★ **全服務行覆蓋 75.2% → 75.7%**（本批 **+53 行**）；**1,215 測／0 失敗／1 略過**；掃描器全 0 命中 | 5.22 |
| 5.24 | ★ **批次 7（大戶 jdbc）：`notification-service` 之 5 個 jdbc 類別** | `TRP-003 §6.11.13` | ✅ **`#A-199`**（2026-10-05）——**5 個類別中 4 個達 100%**；`JdbcNotificationRepository` 37/39；`notification-service` 行覆蓋 **71.0% → 83.1%**。★★ **全服務行覆蓋 75.7% → 76.6%**（本批 **+118 行**）；**1,226 測／0 失敗／1 略過**；掃描器全 0 命中。★★★ **真機反駁**：`OracleRawId.toUuid` 對壞長度**拋 `IllegalStateException`（fail-closed）**，非回 null | 5.23 |
| 5.26 | ★ **批次 8（大戶 jdbc）：`report-service` 之 4 個 jdbc 類別** | `TRP-003 §6.11.14` | ✅ **`#A-200`**（2026-10-06）——★★ **用「兩個容器」**（Oracle ＋ PostgreSQL）；`JdbcAuthSummaryReadModel` **0/21 → 100%**、`JdbcReportDefinitionRepository` **0/14 → 100%**、`JdbcReportJobRepository` 35/36；`report-service` 行覆蓋 **47.8% → 72.2%**。★★ **全服務行覆蓋 76.6% → 77.5%**（本批 **+117 行**）；**1,239 測／0 失敗／2 略過**；掃描器全 0 命中。⚠️ **`JdbcAuthorizationSource` 跨 schema 因容器 app user 無 DBA 而誠實略過**（10 行未覆蓋） | 5.24 |
| 5.27 | ★ **批次 9（大戶 jdbc）：`migration-service` 之 3 個 jdbc 類別** | `TRP-003 §6.11.15` | ✅ **`#A-201`**（2026-10-06）——★ **本服務先前無 jdbc 整合測試**；`JdbcLegacyAccountRepository` **0/21 → 100%**、`JdbcMigrationWaveRepository` **0/15 → 100%**、`JdbcMigrationJobRepository` 36/37；`migration-service` 行覆蓋 **60.5% → 92.1%**（★ **+31.6 pp，單服務最大跳幅**）。★★ **全服務行覆蓋 77.5% → 78.6%**（本批 **+134 行**）；**1,249 測／0 失敗／2 略過**；掃描器全 0 命中 | 5.24 |
| 5.25 | ★ **批次 10+（大戶 jdbc 餘）：payment／installment／report／dispute／merchant** | `TRP-003 §6.11.17` | ✅ **`#A-203` 結案**（2026-10-06）——★ 7 個 jdbc 類別全數 **`100%`**；`payment` 74.6%→**81.0%**、`installment` 78.4%→**82.3%**、`report` 72.2%→74.1%。★★ **併解 `#A-200` 之誠實略過項**（`JdbcAuthorizationSource` 跨 schema，3/13→**13/13**）——★ 動查映像腳本發現 `*.sql` 係以 **`sqlplus / as sysdba`** 執行 | 5.24 |
| 5.29 | ★ **批次 12（`B3-b-2`）：`outbox` 套件**（`KafkaEventPublisher`／`OutboxRelayScheduler`／`OutboxRelayConfig` ＝ **28 行／服務**） | `TRP-003 §6.11.18` | ✅ **`#A-204`**（2026-10-06）——★ `limit`／`payment` 兩服務之 **`outbox` 套件 `0/28 → 100%`**；`limit` 78.5%→**80.7%**、`payment` 81.0%→**85.0%**。★★★ **全服務行覆蓋 79.74% → `80.18%`**——★ **行覆蓋目標（80%）達成**（門檻 10,028 行，超出 23 行）。★ **+56 行**；**1,287 測／0 失敗／1 略過**。★ 以**兩個真容器（Oracle ＋ Kafka）**串完整 relay 鏈路。★ **另 10 服務仍為 0/28**（**約 +280 行**，配方已備） | 5.25 |
| 5.30 | ★ **`TRP-004_覆蓋率提升總結報告`**（B1～批次 12 之總結） | `TRP-004` | ✅ **`#A-204`**（2026-10-06）——★ **行覆蓋 53.7% → `80.18%`（✅ 達成）**；⚠️ **分支覆蓋 46.8% → `63.78%`（❌ 未達 70%）**；**1,287 測**。★ 併載**真機反駁我方假設 13 項**、**殘留缺口全貌（2,433 行）**與後續批次建議 | 5.29 |
| 5.36 | ★ **批次 17：`application` 層分支補強**（`party`／`rewards`／`limit`／`payment`） | `TRP-003 §6.11.26` | ✅ **四子批全數結案（`#A-209`～`#A-213`）**——**17-a（`party`）✅ `#A-209`**：★ `party.application` 30/156→**151/156 ＝ `97%`**；★★ **`party-service` 59.6%→`91.5%`（+189 行）**。★★★ **全服務行覆蓋 87.35% → `88.86%`**；★★ **分支 69.80%（僅差 0.20 pp）**。★ **17-b（`rewards`）✅ `#A-210`**：`rw.application` 289/387→**357/387 ＝ `92%`**；**`rewards-service` 85.7%→`93.5%`（+85 行）**。★★★ **全服務行覆蓋 88.86% → `89.53%`**；★★★ **分支 69.80% → `70.43%`——門檻達標**。★★★ **真機發現兩項**（同日同階段桶 → 批次中止＋孤兒桶；首次累點 → FK 失敗）**待裁定**。★ **17-c（`limit`）✅ `#A-211`**：`lim.application` 377/468→**408/468 ＝ `87%`**；**`limit-service` 89.1%→`91.6%`（+31 行）**。★★ **全服務行覆蓋 89.53% → `89.78%`**；★★ **分支 70.43% → `70.73%`**。★ **17-c-2（`LimitAdjustmentService`）✅ `#A-212`**：該類別 0/56→**46/56**；`lim.application` 408/468→**448/468 ＝ `96%`**；**`limit-service` 91.6%→`95.6%`（+51 行）**。★★★ **全服務行覆蓋 89.78% → `90.19%`**；★★★ **分支 70.73% → `71.37%`**。★ **17-d（`payment`）✅ `#A-213` 結案**：`payment.application` 92/187→**184/187 ＝ `98%`**；**`payment-service` 85.0%→`98.0%`（+92 行）**。★★★ **全服務行覆蓋 90.19% → `90.92%`**；★★★ **分支 71.37% → `71.64%`**。★ **`WBS 5.36`（application 層四子批）全數結案** | 5.35 |
| 5.37 | ★ **`platform/` 8 模組之覆蓋率**（★ **另立口徑**：`verify_nfr` 以「全 backend」計） | `TRP-003 §6.11.31～§6.11.37`／`#A-217`～`#A-222` | ✅ **結案（8／8 模組完成）**——★★★ **全 backend：行 87.42% → `91.94%`、分支 68.98% → `76.18%`**（門檻 80%／70%，**雙雙達標**）。★★★ **`platform/` 8 模組：行 69.4% → `97.17%`、分支 59.1% → `92.99%`**（未覆蓋 **745 → 69 行**、**402 → 30 分支**）。★ **逐模組**：`common-domain`／`common-batch`／`common-event` **皆 `100%`**；`api-gateway` **98.9%／95.2%**；`common-security` **98.0%／98.3%**；`bff-web` **97.3%／97.1%**；`common-saga` **95.4%／87.5%**；`common-spring` **94.9%／85.3%**。★★ **配方**：樁伺服器（JDK 內建 `HttpServer`）／`MockServerWebExchange`／`MockHttpServletRequest`／真實 Spring 例外物件／真件之子類（`ContextRefresher`）——★ **皆非 mock**。★ **殘餘 69 行／30 分支逐條記錄**（需 Oracle／Bean Validation 實作／私有巢狀／並發路徑／不可達） | 5.36 |
| 5.38 | ★★★ **`CR-042`：`JwtAuthFilter` 之 401 路徑拋 NPE 之修補**（★ 批次 20-d 實測揭露） | `CR-042`／`#A-220` | ✅ **已立／已執行**（★ **待 BEAM PMO 核定**）——★★ **`sendUnauthorized()` 以 `Map.of("data", (Object) null, …)` 組封套**，★ 而 **`Map.of` 對任何 null 值皆拋 NPE** → ★★ **該過濾器自建立以來「未認證 → 401」從未真正執行過**。★ **查證影響範圍**：★ **全庫零接線**（僅 Javadoc 提及）→ **不影響現行系統**；★ 惟為公開 API，★ **依文件接線後所有 401 立即變 500** → ★ **仍須修**（依 `CR-041 #A-184` 同一標準）。★ **修法**：改用 `LinkedHashMap`（**JSON 形狀不變**）。★ **修補前 14 測中 11 紅燈 → 修補後 14 測全綠**；★ 全 backend 編譯驗證通過。✅ **接線裁定已於 2026-10-15 執行（採橋接模式）——見 `#A-226`／`CR-042 §9`** | 5.37 |
| 5.39 | ★ **批次 20-e：`common-spring`** | `TRP-003 §6.11.36` | ✅ **`#A-221`**（2026-10-06）——★ **行 87.4% → `94.9%`、分支 73.3% → `85.3%`**（+40 行／+32 分支）；7 類別／56 測（全模組 151 測／0 失敗）。★★★ **真機反駁我方 5 項**（★ **`MDC_KEY` 實為 `trace_id`**／★ **`CC-PLT-5002` 映射 `500` 非 503——狀態由登錄表決定，不憑語感**／★ Spring 7 `NoResourceFoundException` 之**參數序**／★ **Keycloak realm 角色在巢狀 `realm_access.roles`**／★ **`JwtAuthenticationToken` 預設 `isAuthenticated=false`**） | 5.37 |
| 5.40 | ★ **批次 20-f：`common-saga`** | `TRP-003 §6.11.37` | ✅ **`#A-222`**（2026-10-06）——★ **行 91.3% → `95.4%`、分支 66.2% → `87.5%`**（+17 行／+29 分支）；2 類別／27 測（全模組 50 測／0 失敗）。★★★ **真機反駁我方 1 項**：★ **截斷在「工廠／衍生方法」非 record 建構子**（★ 且 `MAX_ERROR_MESSAGE` 為 **2000** 非 256）。⚠️ **殘餘 16 行為 `JdbcSagaStore`（需 Oracle 容器）** | 5.37 |
| 5.41 | ★ **N2-a：架構邊界檢核**（★ 新增 `tools/verify_architecture.py`） | `TRP-002 §13.1` | ✅ **`#A-223`**（2026-10-06）——★ **8／8 通過**；`--selftest` **8/8**；產出 `docs/08-evidence/N2_架構邊界檢核.md`。★★★ **真機反駁本工具自身 2 項缺陷**（★ **A6 偽陽性**：逾時保證在程式碼預設值；★★★ **A7 假綠**：埠不在 yml → **空量測卻報 ✅**）→ ★ **「量不到東西必須報無法判定而非 ✅」**。★ 轉換小節：**原雲生原則**／**Connection issue** | 5.8 |
| 5.42 | ★ **N2-b：SSO 五情境端到端** | `TRP-002 §13.2` | ✅ **`#A-224`**（2026-10-06）——★ **9 項全通過**（真實 Keycloak ＋ 真實後端；**無 token→401／帶真 token→200 真實資料／偽造 token→401／refresh→200**）；★ 併加 `verify_sso_pkce.py --out` 產出**機器標記 ＋ verdict** 之執行紀錄，`verify_nfr.py` 新增 `sso` 證據源（★ **無標記或 FAIL 一律不通過**）。★ 轉換小節：**SSO**／**Authentication**／**Authorization** | 5.8 |
| 5.43 | ★★ **`#A-225`：NFR 證據矩陣落檔缺口之修補**（休假歸來現況確認時揭露） | `TRP-002 §13.4.1` | ✅ **已修補**（2026-10-15）——★★ **`verify_nfr.py` 有 `--out` 但 N2 批次未帶** → ★ **證據矩陣檔停在 N1 狀態（10-02，✅13／❌2／📄24）**，★ 而 N2 成果僅存 stdout → ★ **違反「文件為單一真實來源」**。★ **已重跑落檔**（✅20／❌0／📄19／⚠️21）。★★ **量測方法教訓**：**全檔 `grep` 狀態符號會重複計數**（矩陣表格每列亦含符號）→ ★ **一律讀「`## 統計` 區」**。⚠️ **待 BEAM PMO 裁定**：是否將「必帶 `--out`」列為 NFR 量測固定步驟 | 5.42 |
| 5.44 | ★★★ **`CR-042 §8` 裁定「接線」之執行——`JwtAuthFilter` 橋接模式（真機實測）** | `CR-042 §9`／`#A-226` | ✅ **已接線並真機實測**（2026-10-15）——★ **動工前查證攔下規格矛盾**：`SecurityAutoConfiguration`（common-spring）**早已**以 OAuth2 Resource Server 認證（`CC-PLT-4010`）→ ★ 若照字面以**原生模式**接線＝**雙重認證＋錯誤碼變更**（違 `SCS-022 §7.3`）→ ★ 改採**橋接模式**（讀已驗證之 `Jwt` → 寫 `CurrentUser`／MDC，**不認證、不改回應、不發 401**）。★ 新增 `JwtAuthFilterAutoConfiguration`（`FilterRegistrationBean` 順序 `LOWEST_PRECEDENCE`）＋ 註冊於 `AutoConfiguration.imports`；★ `common-security` 加 `compileOnly` oauth2-resource-server。★ `common-security` **147 測 0 失敗**（+10；原 14 測不受影響）。★ **真機**：無 token→**401 `CC-PLT-4010`（未變）**、帶真 token→**通過認證**、日誌見「已由 JWT 主體橋接至 CurrentUser」 | 5.38 |
| 5.45 | ★ **立 `CR-043`：契約 ↔ 實作四處既有不符（`#A-187`）——待核定修法方向** | `CR-043`／`#A-227` | ✅ **已立**（2026-10-15）——★ 現況複查：`verify_contract_dto.py` **不符 4 處**／需確認 7 則。★ 4 處：`authorization` `reversals`／`overrides`（★ 契約**誤宣告** `AuthorizeResponse`）、`AuthorizeRequest`（契約有 `merchantName`／`entryMode`／`emvData`）、`installment` `InstallmentPeriod`（實作有 `principalAmount`）。★ **擋住 `N2-d` 契約一致性全掃**。★ 建議：2.1／2.2 **修契約**、2.4 **補契約**、2.3 **待定**。★★ **§2.3 已執行（BEAM PMO 裁定「補實作接收」）——見 5.47**；★★ **§2.1／§2.2／§2.4 亦已執行——見 5.49**。★ **四處全數閉合 → `verify_contract_dto` 不符 0 處** | 5.15 |
| 5.46 | ★ **立 `CR-044`：三項真機揭露（`#A-210`／`#A-206`）——待核定修法方向** | `CR-044`／`#A-228` | ✅ **已立**（2026-10-15）——★ ① `rewards` 到期**冪等鍵碰撞**致整批中止（鍵用 `account.id()`＋`bucket.code()`，**非 `bucketId`**；`DuplicateKeyException` 逃逸）② `rewards` 新帳戶**先插桶後插帳戶** FK 失敗 ③ 部分釋放時 `limit` 維持 `HELD`／`auth` 寫 `PARTIALLY_RELEASED`。★ 建議：① 改 `bucketId` 為主體＋放寬 catch；② 先插帳戶後插桶；③ 待裁定**權威來源**。★★ **①／②／③ 已執行（BEAM PMO 裁定「同意」）——見 5.48** | 5.36 |
| 5.47 | ★★ **`CR-043 §2.3` 之執行：`AuthorizeRequest` 三欄補實作接收** | `CR-043 §8`／`#A-229` | ✅ **已執行並實測**（2026-10-15）——★★ **動工前盤點（不照字面做）**：契約 `gen_openapi.py` **已**宣告 `merchantName`／`entryMode`／`emvData` → **契約無須改**；★ **DDL 動查**：`merchant_name`／`entry_mode` **早已在 `V1__baseline.sql`** 惟 INSERT **從未綁定**（`entry_mode` 綁死 `null` → **恆 NULL**）；`emv_data` **不存在**。★ **實作**：四層補三欄 ＋ 遷移 **`V10__authorization_entry_emv.sql`**（`emv_data JSON`）＋ INSERT 綁三欄（`emvData` 以 Jackson 序列化經 `JSON(?)`）；★ **回應不擴充**（契約未宣告）。★★ **`verify_contract_dto.py`：不符 4 處 → 3 處**（本項閉合）；★ `authorization-service` **148 測 0 失敗**（含**直查 DB** 之落庫測試）；★ `validate_sql` 71 檔 0 違規；★ 三掃描器 0 命中 | 5.45 |
| 5.48 | ★★★ **`CR-044 ①／②／③` 之執行：`rewards` 到期批次＋插入序 ＋ `limit` 權威鏡射** | `CR-044 §8`／`#A-230`／`#A-231` | ✅ **已執行並實測**（2026-10-15）——★ **①** `PointsExpiryService` 改**逐桶獨立交易**（`TransactionTemplate` `REQUIRES_NEW`；★ 因 `DataAccessException` 標記 `rollback-only`，**僅收窄 catch 不足**）＋ 冪等鍵改 **`EXP:<bucketId>:<entryType>`** ＋ `catch(RuntimeException)` → **單桶失敗不拖垮整批**。★ **②** `AccrualService.accrue` **先插帳戶、後插桶**（滿足 FK）。★ **③** 明訂 **`limit` 為權威、讀模型鏡射**——`SDD-005 §3` 改寫（`PARTIALLY_RELEASED` **本期不可達**）＋ 新增 **§3.0.1**（R1–R4）；`SCS-001 §7.6／§7.15` 同步；`JdbcLimitHoldProjectionRepository`／`JdbcLimitPort` 之部分釋放 **維持 `HELD`**。★ **實測**：`rewards-service` **155 測 0 失敗**；`authorization-service` **148 測 0 失敗** | 5.46 |
| 5.49 | ★★ **`CR-043 §2.1／§2.2／§2.4` 之執行：修契約（`ReversalResult`／`OverrideResult`／`principalAmount`）** | `CR-043 §9`／`#A-232` | ✅ **已執行並實測**（2026-10-15）——★ `reversals`／`overrides` 契約**皆誤宣告 `AuthorizeResponse`**（疑三端點同範本）→ 新增 **`ReversalResult`**／**`OverrideResult`** schema（依實作欄位：`type∈{FULL,PARTIAL}`／`decision∈{APPROVE,DECLINE}`）並改 `$ref`。★ **§2.4**：`InstallmentPeriod` 補 `principalAmount`——★ **關鍵盤點**：該欄**僅在領域模型**、回應 `PeriodView` **未暴露** → **併補 `PeriodView` ＋ `InstallmentViewAssembler`**（契約＝回應＝領域模型一致）。★ 契約重生 **0 錯誤**（96 端點）；★★ **`verify_contract_dto` 不符 4 處 → `0` 處**；★ `installment-service` **49 測 0 失敗**；★ 規格 `SCS-001`→**1.16**／`SCS-009`→**1.6** | 5.45 |
| 5.50 | ★★★ **`N2-d`：契約一致性全掃（`TRP-002 §13` 第 4 項）** | `TRP-002 §13.5`／`#A-233` | ✅ **已執行**（2026-10-15）——★ 原受 `#A-187` 之 **4 處契約不符**阻塞 → 經 `CR-043` 全數閉合（見 5.49）→ 執行 `python3 tools/verify_contract_dto.py`：掃 **17 服務／96 端點**，★★ **不符 0 處**／需確認 **7**／INFO **14**；★ `--selftest` **8/8**（含正／負樣本）。★ 產出 `docs/08-evidence/N2_契約一致性全掃.md`。★★ **`N2` 四項現況：a✅／b✅／c⚠️未執行／d✅**。⚠️ 如實揭露：需確認 7 則（6 命名 ＋ 1 路徑）**未結案** | 5.8 |
| 5.51 | ★★ **`CR-043 §3.1` 之 7 則「需確認」結案：統一契約↔實作型別名 ＋ 移除 stale 端點** | `CR-043 §10`／`#A-234` | ✅ **已執行並實測**（2026-10-15）——★ BEAM PMO 裁定「統一命名差異」。★ **方向**：**契約 schema 名 ＝ 實作型別名**（★ **不採** `…View`——實作型別為 `domain/model` 領域模型，強冠將**污染領域層**且牽動大量引用）。★ 6 則更名（★ #1 **改實作側** `AuthCheckItemView`→`AuthCheckResult`；#2～#6 **改契約側**）＋ #7 **清除未實作契約宣告** `GET /cards/{cardId}/limits`（**契約清理已完成，不代表卡片級查詢需求已完成**；`SDD-003`／`SDD-006` 路徑一併更正；客戶預期需求另列 **2.4.4**，見 `CR-043 §10.5`／`CR-045 §6`）。★★ **併發現並修正** `AuthorizeResponse.checkResults` 之**欄位不符**（原引用 `AuthCheckResult`〔稽核列語意〕，實作 `CheckResultView`〔passed/implemented〕；★ **巢狀＝工具盲區**）→ 補 schema `CheckResultView`。★ 契約重生 **95 端點／0 錯誤**；★★ **`verify_contract_dto`：需確認 7 → `0`、INFO 14 → `8`**；★ `authorization-service` **148 測 0 失敗**。★★ **併更正 `GOV-006` 第 19 列「已於 CR-019 批 1 補正」之幽靈結案**（實不成立） | 5.50 |
| 5.52 | ★★★ **`N2-c`：監控三支柱截圖（Grafana／Prometheus／Jaeger／Loki）** | `TRP-002 §13.4`／`#A-235` | ✅ **已執行**（2026-10-15）——★ 起 `party-service`（真實 Oracle／Kafka／Redis，`SERVER_PORT=8084`）＋ **真實 HTTP 流量**（`GET /api/v1/parties/{partyId}` 200×10／`/actuator/health` 200×10／404×5）→ ★ **4 張截圖皆顯示真實數據**：**Prometheus** 指標圖（`http_server_requests_seconds_count` 4 序列）／**Jaeger** **20 軌跡**（`http get /api/v1/parties/{partyId}` 等，各 5 spans）／**Grafana Loki** **139 行** ECS 日誌（含 `traceId`／`spanId`）／**Grafana Prometheus** 同 4 序列。★ 截圖以**真實瀏覽器**（headless Chrome ＋ CDP）取得，並**逐張檢視驗證**（非「有畫面就算過」）。★ 產出 `docs/08-evidence/N2_監控三支柱截圖.md`。★★ **`N2` 四項至此全數完成（a／b／c／d）**。⚠️ 如實揭露：Loki `service_name` 恆為 `unknown_service`（Collector `filelog` 已知限制）→ 篩選改用 `service_name_extracted`（管線過濾） | 5.8 |
| 5.31 | ★ **分支覆蓋提升**（46.8% → 70%） | `TRP-004 §7.2` | ✅ **`#A-210` 達標結案**（2026-10-06）——★★★ **分支覆蓋 `71.64%`**（門檻 70%）。★ **歷程**：46.8% → 63.78% → 64.33% → 66.67% → **69.80%** → 70.43% → 70.73% → **71.64%**。★★ **關鍵**：`party` application 層（+189 行）貢獻 +114 條分支。★ **未以假測試湊數**——未覆蓋者皆為**不可達之防禦分支**，逐條如實記錄 | 5.36 |
| 5.32 | ★ **批次 13：`outbox` 橫向複製至其餘 10 服務** | `TRP-003 §6.11.19／§6.11.20` | ✅ **`#A-205`**（2026-10-06）——★ **10 服務之 `outbox` 套件 `0/28 → 100%`**（`KafkaEventPublisher`／`OutboxRelayScheduler`／`OutboxRelayConfig`）；★ **每服務恰 +28 行**（與預估一致）。★★★ **全服務行覆蓋 80.18% → `82.42%`**（10,331/12,535；**門檻超出 303 行**）。★ **+60 測**；**1,347 測／0 失敗／1 略過**。★★ **方法論：動工前以「結構簽章抽取」驗證 API 一致（非目視 diff）**。★ **`outbox` 至此 12／12 服務全數完成** | 5.29 |
| 5.33 | ★ **`messaging` 層**（Kafka 消費端／事件處理） | `TRP-003 §6.11.21／§6.11.22` | ✅ **`#A-206` 結案**（2026-10-06）——★ **7 個 Kafka 消費者全數 `100%`**（`limit` 89/89＋`auth` 82/82）；`limit` 80.7%→**89.1%**、`authorization` 61.6%→**72.7%**。★★★ **全服務行覆蓋 82.42% → `84.40%`**（**+249 行**——★ **遠超套件本身 171 行，協同效應**）；**23 測**。★★ **配方**：真實投影服務＋真實 JDBC 埠串鏈，直接呼叫 `onMessage(json)` 再查 DB；**四項必驗**（有效→生效／未知型別→不拋／壞 JSON→不拋／缺欄→不拋）。★★★ **真機揭露跨服務不一致**：部分釋放時 `limit` 維持 `HELD`、`auth` 讀模型寫 `PARTIALLY_RELEASED` | 5.32 |
| 5.34 | ★ **`client` 層**（外部服務呼叫） | `TRP-003 §6.11.23／§6.11.24` | ✅ **`#A-207` 結案**（2026-10-06）——★ **5 個客戶端 → 三套件 94～98%**（`auth` **134/137**、`stmt` **71/74**、`posting` **44/47**）；`authorization` 72.7%→**83.2%**、`statement` 76.7%→**84.3%**、`posting` 86.8%→**92.1%**。★★★ **全服務行覆蓋 84.40% → `86.39%`**（**+249 行**）；**31 測**。★★ **配方**：**JDK 內建 `HttpServer` 之樁伺服器**（零相依、★ **模擬同儕服務，非 mock 我方程式**）→ 驗真實 HTTP 往返；**七項必驗**。★ 未覆蓋 9 行皆**不可達之序列化 catch** | 5.32 |
| 5.35 | ★ **`storage` 層**（物件儲存） | `TRP-003 §6.11.25` | ✅ **`#A-208` 結案**（2026-10-06）——★ 兩服務之 `S3StorageConfig` **皆 `100%`**、`S3ObjectStorageAdapter` **各 `60/62 = 97%`**；`report` 74.1%→**84.5%**、`statement` 84.3%→**90.7%**。★★★ **全服務行覆蓋 86.39% → `87.35%`**（**+120 行**）；**20 測**。★★★ **動查後修正：用 Garage，不是 MinIO**——★ 本專案之本地物件儲存即為 `garage`（`dxflrs/garage:v2.4.1`）；★ MinIO 開源版已封存、Docker Hub 映像已下架 → 改以**專案同一映像與組態**起容器，**更忠實** | 5.32 |
| 5.28 | ★ **批次 10（大戶 jdbc）：`product-service` 之 2 個 jdbc 類別** | `TRP-003 §6.11.16` | ✅ **`#A-202`**（2026-10-06）——★ 本服務 jdbc 原**僅涵蓋** `JdbcOutboxRepository`；`JdbcProductRepository` **0/38 → `100%`**、`JdbcParameterRepository` **0/31 → `100%`**、★ **`jdbc` 套件整體 `99/99 → 100%`**；`product-service` 行覆蓋 **59.0% → 82.4%**。★★ **全服務行覆蓋 78.6% → `79.1%`**（本批 **+69 行**）；**1,261 測／0 失敗／2 略過**；掃描器全 0 命中。★★ **動查**：`param_value` 為 **Oracle 原生 `JSON`**。★★★ **真機反駁（第七次）**：樂觀鎖衝突**不可**以「已落後物件 ＋ `withUpdated`」建構 | 5.24 |
| 5.8 | **`TRP-002` 之 N2 批次：本地證據產出**（監控截圖／SSO 五情境／架構邊界／契約全掃） | `TRP-002 §13`／`#A-223`／`#A-224`／`#A-233` | ✅ **4／4 項完成（`N2-d` 見 5.50、`N2-c` 見 5.52，皆 2026-10-15 補完）——★★ 證據矩陣 ✅15 → `20`；📄 24 → `19`**。★ **N2-a 架構邊界檢核**（`#A-223`）：★ **新增 `tools/verify_architecture.py`**（零相依、可失敗、`--selftest` 8/8）——**8／8 通過**（容器化 19／19、健康探測 19／19、無狀態 0、分層 0、設定外部化 0、呼叫逾時預設 2000/3000/200ms、埠 19 個無重複、DB 身分 17 個無重複）；★★★ **真機反駁本工具自身 2 項缺陷**（★ A6 偽陽性／★★★ **A7 假空量測卻報 ✅＝假綠**）。★ **N2-b SSO 五情境**（`#A-224`）：真實 Keycloak ＋ 真實後端，**9 項全通過**（**無 token→401／帶真 token→200 真實資料 `P001`·王小明／偽造 token→401**）；★ 併加 `verify_sso_pkce.py --out`（機器標記 ＋ verdict）。★ **N2-c 監控三支柱截圖**（`#A-235`）：起 `party-service`＋真實流量 → **4 張截圖皆顯示真實數據**（Prometheus 指標圖／Jaeger 20 軌跡／Grafana Loki 139 行／Grafana Prometheus）；★ **N2-d 契約全掃**（`#A-233`）：**不符 0 處、需確認 0 則** | 5.5 |

---

## 3. 依賴關鍵路徑（供排序討論）

```
C-12 gateway（✅）→ C-13 bff-web → C-14 WebUI（分批；`§5.1` 59 頁中，桶 A 6＋桶 C 已解鎖 12 已完成，餘桶 C 30 頁待後端）
                ↘ 1.2.4 影子比對 ← W-2 Kafka 消費端
C-4 merchant ──→ C-5 clearing ──→ C-6 dispute（R3 波次）
C-2 product → C-7 report（參數／報表依賴產品資料）
C-31 → C-32（pricing 一致性測試）
```

**排序建議（BEAM PMO 裁定後執行）**：

| 順位 | 建議 | 理由 |
|---|---|---|
| 1 | **C-13 bff-web** | 與 `CR-011` token-relay／`C-12` 路由直接連貫；完成後「WebUI → bff → gateway → 領域服務」正式路徑全通，`#A-68` 之「轉傳無端到端實測」最終解除 |
| 2 | **C-24**（小）＋ **C-11**（小） | 快速清掉兩個小型缺口 |
| 3 | **C-2 product** | 解鎖 report（C-7）與部分畫面 |
| 4 | **C-4 → C-5 → C-6**（R3 域，量大） | 依波次推進；外部阻塞部分（D-1～D-4）以 stand-in 先行 |
| 5 | C-31 → C-32、C-19 | 依 capacity 穿插 |

**★ 2026-09-24 現況更新（上列 1～5 順位已全數執行完畢）**：

上列 1～5 順位**皆已完成**（#A-74／#A-75／#A-76／#A-80～#A-85）。**現行主線轉為 WP3 WebUI（`C-14`）**：

| 區塊 | 現況 | 下一步 |
|---|---|---|
| **桶 A**（可立即實作） | ✅ **6 頁全數完成**（#A-90／#A-91／#A-94） | — |
| **桶 B**（與既有頁面重複） | **11 頁**，**不另造**（`SDD-007 §5.1.2.2`；**2026-10-01 BEAM PMO 裁定**新增 `/onboarding/review`／`/onboarding/approval`） | — |
| **桶 C**（無對應端點） | **30 頁**，**待後端就緒** | 依後端逐項解鎖 |
| ★ **桶 C 已解鎖並完成 11 頁** | `/auth/clearing`／`/auth/dispute`／`/system/reports`（`C-14` 批次一）＋`/merchant/settlements`（批次二）＋`/auth/policy`／`/switch/auth/reversal`（`CR-021`）＋`/auth/stip`（`CR-022`，併補後端 `CR-023`）＋`/system/health`（`SCS-020 §9.8`）＋`/system/audit`（`CR-025`）＋`/system/batch`／`/system/endpoints`（`#A-103`／`#A-104`） | ✅ **全數已完成**（側欄 26 頁） |
| 桶 C 其餘 **30 頁** | 需先有後端端點（各服務契約掃描確認**無對應語意端點**，見 `SDD-007 §5.1.2.3`）；其中 **TMS 4／BASE24 2 之實作歸屬待 SoW 確認** | 依後端就緒逐批解鎖 |

⚠️ **`C-14` 之可交付終點為 29 頁**（`SDD-007 §5.1.2` **2026-09-30 重盤**結論 ＝ 既有 12＋桶 A 6＋桶 C 已解鎖 11）——**全數已交付**（可交付終點已由 29 更新為 **30 頁**，含 `/dashboard`）；餘 **30 頁待後端就緒**（另桶 B 11 頁**不另造**）。

> **★ 節後開工請先讀 `HANDOVER` 之「★ 節後開工指引」**——內含：①環境怎麼起（含實測陷阱）②上次做到哪（`#A-99`）③**下一步第一動**（建議 `§4 #21`）④喚醒指令。
> 本節為 **WBS 排序**（結構視角）；**「下一步做什麼」以 `HANDOVER` 之指引與 `§📊 任務追蹤總表` 為準**。

---

## 4. 待 BEAM PMO 裁定清單（彙總）

| # | 議題 | 來源 |
|---|---|---|
| 1 | SSO 常態啟用（fail-closed 全域） | #C-34／`SCS-022 §10 #12` |
| 2 | 日誌 `total-size-cap` 上限 | #C-30／`SCS-020 §9.5 #5` |
| 3 | `KeyProvider` 不推廣至無個資 13 服務（建議否＝避免假覆蓋） | #C-21 |
| 4 | `docs/08-evidence/` 納入 `GOV-001`（併本文件納冊） | #C-20／`GOV-001` |
| 5 | `FROZEN` 入點行為之客戶規範核對 | `CR-003`／`SDD-005 §10.3` |
| 6 | 兌換現金價值進位方向之客戶規範核對 | `CR-013 §6` |
| 7 | `REDENPTIONS.CASH_VALUE` 折算率來源（`REDEEM_RATE`）之參數維護權責 | `SCS-010 §10 #11`（已解決技術面） |
| 8 | 兌換折抵方式（`settlementMethod`）二期擴充與否 | `CR-012 §5` |
| 9 | `OracleRawId` servlet 環境以外之推廣已完成 8/8；新 WebFlux 模組須自帶 reactive 安全配置 | #A-71／#A-73 |
| 10 | ~~**繳款狀態機轉換 6 之來源狀態**（`ALLOCATED` vs `POSTED`）~~ → ✅ **已裁定（2026-09-22）：採方案 B**——來源改 `POSTED`（額度已恢復者方有可撤銷之恢復）；`SDD-005` 1.6／`SCS-008` 1.4 已同步，並以真實受理流程重跑 e2e（#A-79 ④） | #A-79 ④／`SDD-005 §5`／`SCS-008 §8.2` |
| 11 | ~~**R3 域四服務（`C-6`～`C-9`）之缺口裁定**~~ → ✅ **已裁定（2026-09-22）**：`CR-017` 盤點（C-6 兩處**正交維度混用**＋缺 3 欄；**`CC_RPT`／`CC_MIG`／`CC_NOTIF` 完全無表**；C-8 契約與 SCS 粒度不一致；C-9 發送通道為真阻塞）→ 裁定 **A/B 雙欄位、C 補欄、D 含 Postgres 讀模型、E 兩層 wave＋job、F 通道抽象、G 補 `SDD-001`＋V2**；順序 **C-6 → C-7 → C-8 → C-9**。⚠️ **裁定 D 之依賴已揭露**（讀模型 schema 未定義、同步機制未實作〔`W-2` ⬜〕，建議以**批次投影**為 stand-in）——見 `CR-017 §8.1`。**★ 四支已全數實作完成（#A-82～#A-85）** | **`CR-017` 1.5** |
| 12 | **`validate_sql` 之掃描範圍模糊**——以正規範圍（`src/main/resources/db/migration`）掃為 **0 違規**，但以 `backend` 全庫掃會命中 **C-7 之 Postgres 讀模型 5 處**（`migration-postgres/V1__rpt_read_model.sql` **刻意**不含 `id`／`created_at`／`updated_at`／`version`〔複合主鍵、無樂觀鎖〕，且**不在** `CSP-001 §5.3` 豁免登錄檔之適用範圍〔登錄檔明訂「僅供基礎設施表」〕）。**建議**：**(a)** 於 `CSP-001 §5.3` 明訂 `migration-postgres` 之處理（讀模型非 OLTP 主檔，`SQL-04`／`SQL-05` 之立法目的不適用）；或 **(b)** 納入豁免登錄檔並放寬其適用範圍 | **#A-85 ⑦(i)**／`CR-017 §9.4 (i)` |
| 13 | ~~**`merchant-service`（8095）在 `SDD-007 §5.1` 之頁面清單中無對應頁面**~~ → ✅ **已裁定並執行（2026-09-23）**：**採 (a) 補列**。證據：客戶認可原型（`ECSplus信用卡核心系統Vue3版.html`）為 **13 大模組**，其中**模組 11「收單作業平台」**（9 個 L2，含「特店 (MID) 管理」「對帳與結算撥款」）即 `merchant-service` 之歸屬，而 `SDD-007 §5.1` 原**完全缺席**（`merchant-service` 已於 `C-4` 實作完成卻無頁面）→ **屬追溯缺口，非刻意省略**。已執行：`SDD-007 §5.1` 新增「**收單與商店**」群（群數 9 → **10**、頁數 45 → **46**）＋ **§5.4.13** 逐鈕定義＋實作＋真實瀏覽器實測 → **#A-87**。**★ 併發現更大範圍**：原型**模組 9／10／12／13** 於 §5.1 亦無對應群（見 #15） | **#A-87**／`SDD-007 §5.1`／`§5.4.13` |——實測 §5.1 之 45 頁按「主要服務」分佈：`card` 9／`platform` 7／`authorization` 4／`rewards` 4／`party` 3／`notification` 3／`clearing` 2／`product` 2／`statement` 2／`dispute`·`installment`·`limit`·`migration`·`payment`·`posting`·`report` 各 1／**`merchant` 0**。收單（特約商店建檔／請款／對帳單）為 R3 **已實作域**（`C-4`／#A-80）卻**無作業台頁面**，與其他域不一致。**待裁定**：**(a)** 於 §5.1 補列（如 `/merchant/settlements` 商店管理與請款）並於 §5.4 補逐鈕定義；或 **(b)** 確認為**刻意省略**（例：由既有頁面或批次處理），並於 §5.1 加註理由 | **#A-86 ⑥**／`SDD-007 §5.1` |
| 14 | ~~**契約 vs 實作之「逐端點核對」尚未形成例行檢查點**~~ → ✅ **已執行（2026-09-23）**：新增 `tools/verify_contract_dto.py`（**零相依**；`--selftest` 人工樣本 **4/4** 通過）；`CSP-001` → **1.9**（**§7.1 增列 G-8 檢查點**，含實作紀律三條）；全庫掃描得 **19 處不符**（A 陣列性 1／B 型別與欄位 6／C 欄位集合 12）＋1 則僅命名差異。⚠️ **建置中另修正工具自身 7 項缺陷**（曾產生 **12 處偽陽性**——若不鑑別即回報，將嚴重損害可信度）。⚠️ **19 處之修正方向待裁定**（見 `CR-019 §6`）：A 與 B 之 `rewards` 建議**立即修**；B 之 `card` 5 處與 C 之 12 處建議先由我方出**逐案判定表**再一次核定 | **`CR-019` 1.0** |——`CR-016 §8` 與 `CR-018` 於**同一日、同一次 `C-14` 動工前查證**中發現（前者：回應型別**陣列 vs 單一物件**；後者：**實作有欄位、契約無**）。**建議**：於 `CSP-001`／`SCS-000` 增列「新增／修改端點時，須**逐欄核對回應與契約**」之檢查項；或於 `tools/` 增一支**靜態比對器**（以 Java DTO `record` 之元件名比對契約 `properties`，技術上可行——`record` 元件名可由原始碼解析） | **`CR-018 §5`**／`CR-016 §8` |
| 15 | ~~**客戶認可原型之模組 9／10／12／13 於 `SDD-007 §5.1` 無對應群**~~ → ✅ **已裁定並執行（2026-09-23）**：BEAM PMO 裁定「**請補列**」。已於 `SDD-007 §5.1` 補列 **4 群 14 頁**（群數 10 → **14**、頁數 46 → **60**）：**模組 9 獨立授權平台**（5 頁：預授權與交易取消／沖正機制／交易狀態機與冪等／收單端即時風控／清算前置處理）、**模組 10 獨立紅利平台**（3 頁：商城兌換訂單／會員與等級／平台介接與防弊）、**模組 12 TMS**（4 頁）、**模組 13 BASE24 SWITCHING**（2 頁）；併新增 **§5.1.1 逐 L2 對照表**（18 個 L2 逐一判定「新增」或「已由既有頁面涵蓋」）。⚠️ **併明確界定範圍（誠實揭露）**：**模組 12／13 之 6 頁無對應本專案服務**（TMS 屬收單端設備管理、Switch 核心屬 ACI BASE24 產品）→ **「已補列」≠「已承諾實作」**，其實作歸屬須先確認 SoW。**★ 2026-09-23 已查 RFP 原文（`proposal_v2/sources/FR.md`／`NFR.md`），證據如下**：①**`FR.md` 明載「終端資訊維護由 CAKU 提供支援，BASE24eps 提供交易路由」** → **終端管理（TMS）由既有 CAKU 支援，不在本案新建範圍**；（惟收單授權需求之「**特店及刷卡機驗證**」屬**授權檢核**，非 TMS，已在模組 9 之「收單端即時風控」涵蓋）②`FR.md` 另有「**1.3 交易路由（Switching）**：國際卡組織連線…」之需求 → **交易路由有 RFP 依據**，惟載體為 **ACI BASE24 產品**（本案為 BASE24-eps → BASE24-mas 遷移），**非自建 17 微服務**；③`NFR.md` 之 `BASE24` 出現 **56 次**、`設備管理` 僅出現於「亂碼化設備管理規範（金鑰）」之語境 → 佐證 **BASE24 為既有／目標平台**而非本案開發物。**→ 我方建議**：**模組 12 之 4 頁與模組 13 之「Switch 核心」不列本案交付**（分別由 CAKU／ACI 產品承擔）；**模組 13 之「清算檔案處理」可由 `clearing` 承接**（列後續）。**仍請 BEAM PMO 就合約範圍確認** | **#A-87**／`SDD-007 §5.1`／`§5.1.1`／`FR.md` |
| 16 | ~~**`CR-019 §3.6` 逐案判定表之核定（20 案）**~~ → 🟡 **批 1 之 15 案 ✅ 已執行**（BEAM PMO「請繼續」；見 `CR-019 §3.8`）：**契約 14 案**（`posting` transactions 改陣列／`card` 5 處改指 `CardStatusView`／新增 `ApplicationResult`／`rewards` 新增 `RewardRuleView`／`CardView` 移除 `createdAt`／`TransitionRequest` 補 `operatorId`／`limit` 之 `HoldRequest`·`HoldView`·`LimitView`·`ReleaseRequest` 補正／`SubAccountEntry` 補 `currency`）＋**實作 1 案**（`limit` record 改名 `SpecialLimitsView`）。**比對器 19 處 → 2 處**；真機回歸實測 4 端點通過。⬜ **僅剩批 2（C-1）待裁定**：`AuthorizeRequest` 之 `merchantName`／`entryMode`／`emvData`——實作未接收，而 Spring Boot **預設忽略未知欄位** → 消費端送出將被**靜默丟棄**（「靜默不做」型風險）；**我方建議契約加註「本期未實作」**（屬 13 大項檢核既有未實作範圍 `L-1`），不建議現在補實作 | **`CR-019` 1.2 §3.8／§6** |
| 17 | **`INSTALLMENT_PERIODS.AMOUNT` 之設計意圖待確認**（`CR-019` 批 1 執行前查證時發現，**非機械性修正**）——實測 `InstallmentPlan` 產生期數為 `new InstallmentPeriod(i, principal, principal, fee, …)`（**第 1、2 參數同為本金**），DDL 之 `AMOUNT` 與 `PRINCIPAL_AMOUNT` 兩欄**值相同**；而 `SCS-009 §2`／`§7` 僅定義「每期本金／手續費／到期日／剩餘本金」、契約之 `amount` 描述亦為「本期本金」。**待裁定**：`AMOUNT` 之設計意圖為 **(a) 本期本金**（＝現行實作與契約描述；則 `PRINCIPAL_AMOUNT` 為**冗餘欄**，建議 V3 清理）或 **(b) 本期應繳總額＝本金＋手續費**（則**現行實作與契約描述皆為缺陷**，須修正 `amount` 之計算與描述）？⚠️ 本項**不可由工具或機械推論決定**——涉及帳務語意 | **`CR-019 §3.8.3`** |

| 20 | ~~**Stand-in 佔用之沖正設計**~~ → ✅ **已裁定（2026-09-23）並實作**：採 **(a) 對稱釋放**——`StandInLimitPort.release` 先遠端、失敗（即 Stand-in 情境）降級本地讀模型並 WARN、遠端成功後 best-effort 清本地同列；本地釋放語意與 limit-service 一致（查無／終態／超釋皆拒）。**FULL 沖正已真機驗證**（#A-96）。原記之選項說明——（批次七真機實測發現：runtime 掛載 `StandInLimitPort`，種子授權之佔用皆為 Stand-in 本地佔用）——選項：(a) 沖正時同步本地釋放＋併入上送對帳；(b) 沖正拒絕（現況 fail-loud）並由上送批次沖抵。**另 `advices` 語意**（`SCS-001 §7.7`）：(a) 後送 Advice／(b) 人工覆核 Override **／(c) 對轉人工（`REFERRAL`）核決**——★ **已立 `CR-022` 供裁定**（三案對照表；契約**內在矛盾**之逐欄位證據：`summary` 說人工/強制授權、路徑指向既有授權、body 為完整請求、回應含檢核明細與佔額——**四欄位互斥**，任一案皆須修契約）。**我方建議 (A)**（與原型 L2「待補送佇列/補送結果」高度吻合、`StandInUploadService` 可重用、沖正已完成可閉環），(C) 列後續、(B) 不建議。★ **2026-09-24 已裁定並實作**：BEAM PMO 裁定採 **(A) 後送**，已實作並**真機驗證**（**#A-98**）；併依 RFP `FR 1.1` 第 4 項「支援人工授權、強制授權、人工取消授權」（廠商回覆欄已填「滿足」）新增 **§7.8 人工／強制授權**（人工取消＝沖正 §7.6 已完成）。⚠️ 實測併揭露 `standin_flag` 之推導缺陷 → 已立 **`SCS-001 §7.7.1`** 並修正（詳 §4 #21） | **`CR-022`（已結案）／#A-98／`SCS-001` §7.7／§7.7.1／§7.8** |
| 21 | ~~**`LimitServiceClient`（Feign）對 limit-service 未接 M2M outbound token → 一律 401**~~ → ✅ **已修除（2026-09-29，`CR-024`）**：**修法方向經查證後修正**——原建議「Feign 加 `RequestInterceptor`」**不正確**，因 `common-spring` **早已有** `ServiceClientHttpClient`（建構子**強制要求**非空之 `OutboundTokenProvider`，正是為杜絕「靜默不帶標頭」），且 `statement`／`payment`／`posting` **皆用它**，**僅 `authorization-service`／`card-service` 用 Feign**（異類）。→ 改為**直接使用 `ServiceClientHttpClient`**（新增 `LimitServiceHttpClient`／`CardServiceHttpClient`、刪除兩個 Feign client、移除 `@EnableFeignClients` 與依賴）。**真機驗證 4 項**：授權 **`APPROVED`**（修正前 `STANDIN`）／批次後送 **`{uploaded:3, remaining:0}`**（修正前 `{0,3}`）／`standin_upload_at` **全部寫入**（修正前恆空）／`LIMIT_HOLDS` **遠端確實收到佔用**。**`#A-98`／`#A-99` 自此真正閉環**（見 **#A-100**）。⚠️ **併發現同型未竟**：`card-service` 之 `CreditReviewClient`（Feign）→ 已登記 **`C-45`**。原記載（保留供追溯）——授權之佔用／釋放**全數降級 Stand-in**（決策恆為 `STANDIN`），本地讀模型與權威側恆有落差（靠上送批次收斂）。屬 `CR-010/011`（M2M／ACL）範疇之**既有缺口**，非本 CR 引入；修法方向：Feign 加 `RequestInterceptor` 接 `OutboundTokenProvider`（`cc-authorization-service` → limit-service 之 ACL 白名單須同步）。★ **2026-09-24 更新（B-2 真機實測揭露）**：本項原述「**決策恆為 `STANDIN`**」於 `SCS-001 §7.8` 新增 `REFERRAL` 後**已不成立**——轉人工件在降級時決策為 `REFERRAL`，而 `standin_flag` 舊以**決策碼**推導 → **漏標 → 該筆永不後送**（額度權威側永久落差＝超額風險）。已由 **`SCS-001 §7.7.1`** 明訂改依**佔用方式**（`HoldResult.standIn`）判定並修實作；**真機對照**：修正前 `standin_flag=0` → 修正後 **`1`** 且列入待上送清單 | **`CR-024`**／**#A-100**／#A-96 ⑥ |
| 22 | **`CR-045`：參數極大化治理提案之裁定**（D1～D6：權威邊界／第一條商品參數閉環／活動模型／帳單與日曆／安全授權）；**不得把文件宣告當成已實作消費** | `CR-045 §8`／`HANDOVER #A-236` |
| 19 | ~~**`CR-021`：authorization-service 三支契約端點（`reversals`／`advices`／`check-results`）完全未實作，與其三頁之處置**~~ → ✅ **已裁定並執行完畢（2026-09-23～24）**：採 **(a) 本期補實作**——`check-results` ✅（#A-95，併修契約陣列性）／`reversals` ✅（#A-95～#A-96，含 Stand-in **對稱釋放**）／`advices` ✅（**#A-98**，`CR-022` 裁定採 **(A) 後送**）。**真機驗證**：FULL 沖正 200＋重複沖正 `CC-AUTH-3002`；後送非 Stand-in 件 `CC-AUTH-3001`；後送遇額度服務不可用**保留待上送**。**併處置**：`limit-service` 路徑維度差異（契約 `cards/{cardId}/limits` vs 實作 `accounts/{accountId}/limits`）。⚠️ **原記「已於 `CR-019` 批 1 補正」為不實**（★ **幽靈結案**；2026-10-15 實查契約仍為卡級路徑）→ ★ **已於 `CR-043 §3.1` #7 真正補正**（移除 stale 端點＋更正 `SDD-003`／`SDD-006`） | **`CR-021`**／#A-95／#A-96／#A-98 |
| 18 | ~~**`CR-020`：卡片生命週期端點之四項缺陷待裁定**~~ → ✅ **已裁定並執行完畢（2026-09-23，BEAM PMO）**：**採「修根因」而非 workaround**——F1 加 `CARD_APPLICATIONS.CARD_ID`（V7）＋`ACTIVATE` 確實驗證三要素；F2 確實綁定標頭＋冪等生效；F3 查無卡片回 `CC-CARD-4040`（404）；F4 `status` 依 `SDD-005 §2.4` 映射表由 `blockCode`推導（**兩欄為衍生關係，非獨立維度**）。真機實測 9 項＋單測 10 例＋負樣本驗證。⚠️ **併發現新缺口**（`SCS-003 §10 #13`）：`POST /cards/{cardId}/instant-issuance`仍**未綁定** `X-Idempotency-Key`（契約宣告為必要）——非本 CR 範圍，已登記供後續。原四項內容——**F1** `threeFactors` 契約宣告但實作未接收（三要素驗證**完全缺失**，`CC-CARD-1002` 不可達）；**F2** `X-Channel`／`X-Idempotency-Key` 契約宣告為必要但實作未綁定（**冪等鍵無效**）；**F3** 查無卡片回 `CC-CARD-3001`（409）而非 404（與同服務 `findById` 之修正**不一致**）；**F4** `ACTIVATE` 未同步 `cards.status`（兩條寫入路徑結果不同）。**我方建議之最小可行組合**：F3 改 404（成本最低、有前例）／F1 先契約加註未實作／F2 先契約移除冪等宣告／F4 補同步**但須先定義全事件之 `status` 映射**（不可只修 `ACTIVATE`） | **`CR-020` 1.0** |

---

## 5. 維護規則

1. **狀態異動只寫 `HANDOVER`**（含實測證據）；本文件僅在 **WBS 結構變更**（新增／拆分／排序調整）時升版。
2. 葉任務完成時：`HANDOVER` 移列 §3.A（取得 #A-xx）→ 本文件之狀態欄改 ✅ 並回指該編號。
3. 新需求一律先入 `HANDOVER §3.C`（或立 CR），再反映至本文件——**順序不可顛倒**。

## 6. 修訂記錄

| 版本 | 日期 | 修訂內容 |
|---|---|---|
| 1.77 | 2026-10-17 | **2.4.4 定性更正＋兩筆缺口開立 CR（`#A-277`，BEAM PMO 2026-10-17 核准）**——①★ **2.4.4 定性更正**：RFP `FR.md §2.4(1)` 原文明列「歸戶、持卡人、**卡片**調額／**查詢**」→ 卡片級查詢為 **RFP 已列需求**，原「預期需求（非 RFP 明列）」記載有誤（`CR-050 §4` 揭露、BEAM PMO 核定更正），語意待凍結轉由 **`CR-052`** 承載。②**開立 `CR-051`**（RFP FR §4.3 商店對帳單未承作——SA/SD 語意凍結清單 S-1～S-7）與 **`CR-052`**（卡片級額度調額／查詢——額度多維度與共享池分攤語意凍結清單 C-1～C-6）；兩 CR 均為**規格先行、不動程式、不補端點**。 |
| 1.76 | 2026-10-16 | **`CR-046` 受理：`campaign-service` 新建＋BR-16 載體抽象，單一交付列車（#A-244）**——BEAM PMO 裁定「campaign-service 必須排入完成」＋「BR-16 必須與活動引擎同批上線」。★ 同批之技術理由：活動引擎四項核心參數（上限截斷/歸戶合併/錄取名額/支付路徑認定）全以交易載體最小識別為粒度，若無 `instrument_id`，AC 11 虛擬卡同構與 AC 8 支付路徑分級在資料層無法表達。任務 C-0～C-11（C-0＝BEAM PMO 核定 SCS-026 v2.0）。⚠️ B 節為主要工期來源，屬多批次工程。 |
| 1.75 | 2026-10-16 | **WP2 2.4.2 依客戶 BRD 完成最大參數化設計（#A-243）**——`BRD-005`（客戶提供，v1.3，1031 行）納入版控（Mermaid 9 區塊 0 錯誤；附錄 A 一處競業引用泛稱化）。`SCS-026 → 2.0`：對應需求擴為 BR-01～16 全 16 條；**BR-01 參數化要素 6→30 欄完整契約**；新增 ENROLLMENT／PLAN／QUEST／PAY_PATH／CHANNELS／REWARD_CMDS 六實體；錄取狀態機照 BRD §12.2；十個驗算範例列為自動化驗收基準。★ 權責紀律：計算權威留各域服務，campaign-service 不接管計算。⚠️ BR-16 載體抽象須單獨立 CR 分期；BRD 遺留假設屬客戶輸入。2.4.2 ⬜→🟡 設計完成待核定。 |
| 1.74 | 2026-10-16 | **WP2 2.4.1 閉環改採真 socket（#A-242）**——`ParameterClosedLoopIntegrationTest` 由 `@WebMvcTest`+MockMvc 改為**嵌入式 Tomcat（`server.port=0`）＋ JDK `HttpClient` 真 socket**，六例全過（②／④／⑤＋同交易 Outbox＋4 負樣本）。★ **根因定位並更正 #A-241 錯誤解釋**：同埠四路競賽證實「沙箱代理攔迴路埠」不成立；真因為**本機 Tomcat 僅綁 IPv6，IPv4 迴路（`localhost`／`127.0.0.1`）連線掛住**，改用 hostname／`[::1]` 即通。`SCS-002` → **1.15**。⚠️ ③之跨進程段仍未驗證。 |
| 1.73 | 2026-10-16 | **WP2 2.4.1 閉環補強（#A-241）**——`product-service` 新增 `ParameterClosedLoopIntegrationTest`（真 Oracle via Testcontainers ＋ `@WebMvcTest` 真 web 層，`@Import` 生產元件、零替身），閉合 `SCS-002 §7.14` 驗收 **②／④／⑤**：PUT 落新版＋現行版封閉於 `newFrom−1`、businessDate 取昨日／今日得舊值／新值、直改 `CC_PRODUCT.PARAMETERS` 後再取即反映（非快取）、同交易 Outbox 事件、4 項負樣本（422 `CC-PRD-1002`／404 `CC-PLT-4040`／空 body 400／缺 header 400）。★ **動工前查證（MEMORY-RULES #17）**：前版「待 product-service 寫入路徑與 `CC_PRODUCT.PARAMETERS` 表俱備」**實為過度保守**——三者本地早已具備，②／④／⑤ 並非被外部阻塞。★ **如實揭露**：本機沙箱有傳輸層 HTTP 攔截代理（攔走連 `127.0.0.1` 之請求）→ 捨棄嵌入式 Tomcat＋socket，改 MockMvc；③之真 HTTP 段仍待另立跨 JVM 驗證。`SCS-002` → **1.14** |
| 1.72 | 2026-10-16 | **WP2 2.4.2 Campaign 模型規格先行（#A-240）**——BEAM PMO 2026-10-15 核定六項活動政策（年費免年費／紅利里程換算／滿額禮／疊加／回沖打呆帳／預算每戶上限），錄入 `CR-045 §8.2`；據以新建 `SCS-026` 行銷活動 Campaign 模型程式設計規格（草案，待核定），含 Campaign 聚合／狀態機／疊加互斥／預算上限／回沖策略，明訂與 pricing／rewards 之領域權威邊界（Campaign 聚合不接管計算）。`SCS-000` 索引補 SCS-026。2.4.2 由 ⬜→🟡 規格先行。 |
| 1.70 | 2026-10-15 | **新增 WP2 2.4「參數極大化（三位一體）」待裁定工作包**：2.4.1 商品參數治理與第一條消費閉環、2.4.2 Campaign／領域規則接合、2.4.3 工作日曆／批次／帳單參數、2.4.4 預期需求之卡片級可用額度查詢。依 `CR-045`：文件／DDL／程式須分辨，凡未裁定／未立規格之項目不動程式；★ 更正 2.4.4 非 RFP 明列，亦非 CR-043 #7 契約清理之結案範圍 |
| 1.45 | 2026-10-01 | **`CR-027` 批次 A-4 完成（`#A-133`～`#A-138`）**——**payload 已定義之 9 項事件全數打通**（`dispute.case.opened.v1`／`posting.transaction.posted.v1`／`.reversed.v1`／`statement.statement.issued.v1`／`rewards.points.accrued.v1`／`.redeemed.v1`／`merchant.settlement.submitted.v1`／`notification.sent.v1`），**每項皆「規格先行 → 實作 → 真機驗證」**（真實 Oracle ＋ Kafka；含冪等／退款／異常狀態等**負樣本**）。★ **單測攔下 1 項語意缺陷**：`dispute` 之 payload `disputeType` 原誤取 `DISPUTE_TYPE`（程序類型，恆為 `INQUIRY`），應取 `DISPUTE_REASON`（爭議原因）——**若未攔下，下游將收到恆為 `INQUIRY` 之錯誤事件**。★ **`#A-139` 更正 `#A-131` 之根因**：原記「受服務間 ACL 阻擋」**兩處不成立**——ACL 之拒絕碼為 `403`，實測為 `401 CC-PLT-4010`；真因是**本機 SSO 開啟**（`ops/local/sso.env` 之 `CARDCORE_SECURITY_ENABLED=true`）。以合法使用者權杖重跑即通，**`clearing` 已補驗完成**。★ **`#A-140` 新增 `CR-027 §5 #15`**——Kafka 主題命名不一致（4 服務寫入「完整名」致主題多一層重複；本批新服務依文件慣例實作 → **新舊並存，待裁定一次對齊**）。**規格先行**：`SCS-012` 1.4／`SCS-007` 1.4／`SCS-011` 1.4／`SCS-010` 1.9／`SCS-014` 1.2／`SCS-016` 1.3；`CR-027` → **1.5**。**4.8 🟡（5 全鏈路 ＋ 13 僅生產端；已接 outbox 12／17；18 個 `cc.*` 主題就緒）** |
| 1.46 | 2026-10-01 | **`CR-027` 批次 C（消費端）動工（`#A-141`）**——①**新建 `CR-029`**：依 `SAD-004 §5.2`（權威事件清單）＋ `SAD-002 §3`（各服務訂閱）盤點 **22 ＋ 3 條**消費邊，逐條標註「語意來源／目標模型（實測 `user_tables`）／payload 足夠度／**同步冗餘**」並分 `C-1`～`C-9` 共 9 批；★ **明確排除 `SAD-003 §4.1` 之 7 個 `q_*`**——**逐列比對確認 7／7 皆為自投影**（來源事件與存放服務同一），非批次 C 之內容（屬 `CR-027 §5 #6`）。②★ **揭露架構性問題並新增 `CR-027 §5 #16`**：**3 條消費邊所描述的行為已由既有同步呼叫完成**（auth→limit 佔用／payment→posting 入帳／statement→posting 查詢），**並存必然重複套用** → **建議 (b)「同步為主、事件為輔」**，**此為批次 C 之最大前提**。③**`C-1`／`C-2` 實作並真機驗證**：`payment.payment.posted.v1` → notification（模板 **`PAYMENT_RECEIVED`**）、`statement.statement.issued.v1` → notification（模板 **`STATEMENT_ISSUED`**）——**語意來源為既有種子模板，非臆造**；★ **前置契約變更**：兩事件 payload 原缺 `currency` 而模板需要 → 依 `SAD-004 §5.3` 補為**可選**（**不升版**；`SCS-008 §7.2`／`SCS-011 §7.2`，即 `CR-027 §5 #10` 之建議 (b)，比照 `#11`／`#14` 之先例）。④★ **重構**：`AuthApprovedNotificationPort` → **`EventConsumptionPort`**（表本即通用）＋ 抽出 `EventNotificationService` 基底（守門順序 ①型別 ②冪等 ③亂序 ④建立 ⑤同交易記錄），**三個消費者共用**。⑤**真機**：繳款 → `PAYMENT_RECEIVED`／`SENT`；出帳 → `STATEMENT_ISSUED`／`SENT`；**3 個負樣本**（週期重跑／同鍵重送／**人工送「無 `currency` 之舊事件」→ 不建半殘通知且不寫消費紀錄**）；★ **天然對照實驗**：消費端由 `earliest` 重放，**舊事件全數略過、新事件正常建通知**。⑥**併修自身疏漏**：`#A-135` 加了 `SCS-011 §7.1` 卻**漏升版次與補列**（且 `HANDOVER` 誤記「1.4」，該檔實際 1.8）→ 已補正為 **1.10**。**規格先行**：`CR-029` 1.0／`SCS-008` 1.6／`SCS-011` 1.10／`SCS-016` 1.4；`CR-027` → **1.6**。**4.8 🟡（6 全鏈路）** |
| 1.47 | 2026-10-01 | ★★ **`CR-027 §5` 十二項待裁定全數裁定（`CR-030`）並執行完畢（`#A-142`）**——BEAM PMO 指示「以 Best Practice（Payment Industry 20 年架構師）直接將這些問題解決」→ **不再逐項回問**，改由架構師依 **4 條業界通則（P1 單一真實來源／P2 事件＝狀態變更／P3 同步 vs 非同步分界／P4 契約向後相容）** 裁定。★ **以程式證據確認 2 項真缺陷**：**#8**（`AuthorizeUseCase` 之 `willApprove` 證實 `REFERRAL` **佔用額度**，惟發射條件 `isApproved()` **排除**之 → **額度被佔用而下游不知**）；**#9**（`SCS-008 §7`／`§8.2` 之「撤銷額度恢復」**無任何消費者** → **可用額度永久高估**）。**程式 A 批**：#8（`holdsLimit()` ＋ `decision` 可選 ＋ notification 對 REFERRAL 不建通知）、#9（`payment` 補發射 `unmatched.v1`／`reversed.v1`；`limit` 新增 `PaymentReoccupyProjection*` ＋ `reoccupyUsedAmount`）、#12（`card` 序號統一）。**程式 B 批**：#15（四服務 `event_type` 常數）。**文件批**：#5（`SAD-004 §5.2` 為唯一權威＋補登 4 事件）、#6（`SAD-003 §4.1` 廢除 7 自投影）、#7（declined 改 metrics）、#10（`currency` 通則入 `SDD-006 §2.5`）、#13／#11／#14（追認）、#16（用途欄改寫）。★ **併修 `SDD-006 §4.2` 表格結構缺陷**（原被 `CR-028` 說明截斷）。**真機**：REFERRAL 已發射（payload 含 `decision`）且**不建通知**；沖正 → `used_amount` **0 → 200,000**。**九服務 384 測 0 失敗**；掃描器 9×3 全 0；mermaid 0 錯誤。**4.8 🟡（8 全鏈路）** |
| 1.48 | 2026-10-01 | **批次 C 剩餘項：`CR-031` 讀模型設計與裁定 ＋ `C-5` 實作完成（`#A-143`）**——①**依 `CR-030` 之 P1～P4 通則直接裁定**（不再逐項回問）：**`C-5`（`party` 卡片狀態投影）實作**、**`C-7`（參數快取）設計先行、暫緩實作**。②★ **`C-5` 為「架構上唯一解」**：實測 `cardcore-service-acl.yml`——`card-service` **只允許 `cc-authorization-service`** 呼叫 → **`party` 在架構上無法同步取得卡片狀態** → **事件投影是唯一途徑**（對照 `#16`：本項**不存在**可重做的同步路徑 → 屬「做沒人做的事」→ **應做**）。③**實作**：`V3__card_status_projection.sql`（`card_status_caches`＋`consumed_events`）／`CardStatusProjectionPort`（讀＋寫）／`JdbcCardStatusProjectionRepository`（冪等＋亂序＋upsert **同交易**）／`CardStatusProjectionService`／`CardStatusChangedListener`（`cc.card.card.status-changed`）／`GET /api/v1/accounts/{accountId}/cards`（契約 **93 端點 0 錯誤**）。④★ **真機驗證 8 項**（真實 Oracle ＋ Kafka）：**歷史回填**（新消費群組 `earliest` 自動回填）／**INSERT 路徑**（鎖卡 → 新增投影列）／**UPDATE 路徑**（`version 1→2`）／端點 200／**負樣本①重複 `eventId` → 略過**／**負樣本②較舊 `sequenceNo=100` ＋ 相反狀態 → 略過（若無亂序防護將被錯誤覆寫為 `ACTIVE`）**／404（歸戶不存在）／200 空陣列（歸戶存在無投影）／`UNLOCK` 還原。⑤★ **發現並修正「跨服務種子不一致」**：`card`／`limit`／`authorization` 種子皆用 `…0001`～`…0003`，惟 `party` 種子自成一戶 `…0010`（且無卡）→ 新端點對**所有真實卡片**回 404；**修正**為補齊該三戶（**不放寬守門**——歸戶權威在 `party`，`P1`）。⑥**`C-7` 暫緩之證據**：**實測 9 個可呼叫 `product` 之服務全部沒有參數快取**，且參數化自載「已登記為後續項」→ **無快取可失效＝建監聽器即假綠**；★ **併更正 `SAD-004 §5.2`**：`product.parameter.changed.v1` 之「全體」實為**可呼叫 `product` 之 9 服務**（ACL 所限）。⑦**測試／關卡**：`party` **23 測 0 失敗**；掃描器 3 支 **0 命中**；`validate_sql` 全庫 **65 檔 0 違規**。⑧**併修自身兩處疏漏**：`SCS-004` 新章節**誤植 `§7.1`**（與既有「§7.1 個資處理」衝突）→ 更正為 **`§7.5`**；該檔修訂表 1.1 列**多一欄**。**規格先行**：`CR-031` 1.1／`SAD-004` **1.6**／`SCS-004` **1.2**／`CR-029` **1.1**。**4.8 🟡（7 全鏈路）** |
| 1.49 | 2026-10-01 | **`bff-web` 之 `BffAccountOverview` 新增 `cards` 區塊（三 → 四區塊）——真機驗證通過（`#A-144`）**（BEAM PMO 指示「先執行（a）」）——①★ **關鍵更正**：下游為 **`party-service`**（`GET /api/v1/accounts/{id}/cards`）**而非 `card-service`**——**(i)** `card` **無「依歸戶列卡片」端點**（僅 `lookup/{cardNoHash}`／`/{cardId}`）；**(ii)** `card` 之 ACL **只允許 `cc-authorization-service`**；**(iii)** 「歸戶 → 卡片清單」之**讀模型由 `party` 持有**（`#A-143`）→ **BFF 應呼叫持有讀模型者**。②**規格先行**：`SAD-004 §2.2.1`（聚合列改四區塊）＋**新增 §2.2.1.1**（下游理由／回傳形狀／降級／**不含 PAN**／★ **尚無前端消費者**之揭露）→ `SAD-004` 升 **1.7**；`CR-031` 升 **1.2**（§4.5）。③**契約**：`gen_openapi.py` 加 `cards` → 重生 **93 端點 0 錯誤**、**僅 `bff-web.yaml` 變動**。④**程式四檔**＋★ 併修 `AccountOverviewService` 之**重複 import**。⑤★ **真機驗證**：`bff`(8101)＋`party`(8084)＋`limit`(8083)＋`rewards`(8091)＋Keycloak——**四區塊成功**（帳戶 `…0001`：party／**cards（2 張卡）**／limits OK，rewards `CC-RWD-4040`）；**cards 與 `CC_PARTY.card_status_caches` 逐欄一致**；帳戶 `…0010` → **cards OK ＋ `data: []`**（非 404）；無權杖 **401**／非 UUID **400 `CC-PLT-4003`**；★ **負樣本**：第二實例（8102）party 指向死埠 → **`party`＋`cards` 皆 `UNAVAILABLE`**（同一下游），而 **`limits` 仍 `OK`**（`…0001`）／**`rewards` 仍 `OK`**（`…0010`）→ **降級為「逐區塊」而非「全有全無」得證**。⑥**測試／關卡**：`bff-web` **21 測 0 失敗**（新增 2 支）；掃描器 3 支 **0 命中**；`validate_mermaid` **0 錯誤**；`verify_contract_dto` 之 4 處不符**全為既有**、**本次零新增**。⑦★ **新增 WBS 1.3.2**（頁面消費）與 **1.3.1 之狀態更新**。⑧⚠️ **誠實揭露**：**本端點仍無前端頁面消費者**——`SDD-007` 未立對應 §5.4.x → **接頁面前須先補逐鈕定義**。⑨⚠️ **併發現（既有、非本次）**：`bff-web` **未引入 validation starter**（啟動 WARN `ConstraintViolationException not present`），不影響本端點（UUID 檢核在應用層，實測 400 正常）→ **登記供日後評估**。 |
| 1.50 | 2026-10-02 | **「歸戶 360」頁（`/accounts`）完成——真實 Chrome 端到端驗證通過（`#A-145`）**（BEAM PMO「好期待『歸戶 360』頁做出來，先來這個」）——①**擬定計劃**：新建 **`CR-032`**——裁定**新頁**而非併入 `§5.4.3`（職責：**作業** vs **唯讀總覽**；存取路徑：`/party-api` 直呼 vs `/bff-api` 聚合）；★ **誠實揭露**本頁**超出 `§5.1` 之 59 頁清單**（第 2 頁，先例 `/limit-adjustments`）。②**規格先行**：`SDD-007` **1.27** 新增 **§5.4.31** 逐鈕／逐區塊定義；★ **併修該檔兩處既有缺陷**——**修訂記錄漏列 1.26**（版本列早已載，**「已做卻漏記」**）＋ `§5.4` 導言與 `§5.1.2` 之計數過時。③★★ **本頁最重要之設計規則**：四區塊**各自獨立降級**，`UNAVAILABLE` **必須明顯呈現並帶下游錯誤碼**，**嚴禁以 `0`／`-`／空白表格代替**（**「取不到」≠「真的是 0」**——額度取不到卻顯示 `0` 會讓客服誤判）；**空狀態（`OK` 且 `[]`）與不可用明確區分**。④**程式三檔**：`api/bff.ts`（新類型 ＋ `fetchAccountOverview`；**沿用既有 `AccountView`／`LimitView`／`PointsAccountView`，不另造**）／`pages/AccountOverviewConsole.tsx`／`App.tsx`（**側欄／路由／頁首同源**）。**無契約變更、無後端變更**。⑤★ **真機驗證（真實 Chrome 154 ＋ CDP ＋ Keycloak 登入）**：側欄 30 頁含「歸戶 360」；歸戶 `…0001` → 歸戶／卡片（2 張）／額度**可用**、點數**不可用 ＋ `CC-RWD-4040`（錯誤盒，未以 0 代替）**；歸戶 `…0010` → 卡片**可用但空 →「此歸戶尚無卡片」**、額度**不可用 ＋ `CC-LIM-1001`**、點數**可用（CUR 100,003／AV1 0／AV2 0，真實 0）**；非 UUID → `CC-PLT-4003`。⑥**證據納管**：新增 2 張截圖（**45 → 47 張**）並更新 `docs/08-evidence/README.md`。⑦**關卡**：`typecheck` 0 錯誤、`build` 成功（131 模組）、掃描器 3 支（frontend）0 命中、`validate_mermaid` 0 錯誤。⑧★ **環境教訓**：本機 **`agent-browser` 未安裝** → 以 **`node:net` 自製最小 WebSocket 客戶端直連 CDP**（零相依）；三坑：**Chrome 須 `--no-sandbox`**（否則 renderer 不回應 `Runtime.*`／`Page.*`）、**須用 `localhost:5173`**（`127.0.0.1` 不符 Keycloak `redirect_uri` 白名單）、**Node 內建 `WebSocket`（undici）不可用**（僅 `open` 內之首指令有回應，其後 1006 關閉）。⑨**WBS 1.3.2 完成**；側欄 **29 → 30 頁**。**4.8 🟡（7 全鏈路）** |
| 1.51 | 2026-10-02 | **批次 C `C-5` 其餘 8 條目全數結案（`CR-033`）＋ `bff-web` 補 Bean Validation**（BEAM PMO：「**請先執行 `C-5` 其餘 8 條目，之後再補 `bff-web` 的 validation starter**」）。<br>**① ★★ `C-5` 結案（`#A-146`）**：`CR-029 §5` 之 8 條（`#1`／`#3`／`#7`／`#9`／`#13`／`#18`／`#20`／`#21`）逐條查證後——**實作 1 條**（`#3`＝`card.status-changed` → `party`，`#A-143`）、**裁定不做 7 條**、**待實作 0 條**。<br>**② ★★ 揭露「幽靈待辦」根因**（以 `git show 9937bd0` 取 `CR-030` 前之 `SAD-004 §5.2` 為證）：該 8 條係依 **`CR-030` 之前**之清單盤點；`CR-030 §2 #5` 將該清單**重寫為唯一權威**時**已移除／改判**這些消費邊，**惟未回寫 `CR-029`** → 仍顯示為待辦。**教訓**：**重寫權威清單後，必須回寫「以舊清單為基礎之盤點」**。<br>**③ 逐條理由**（`#13`／`#18`／`#20`／`#21` 皆「查無事件消費語意」）：`#13` 自扣屬**未實作功能**（`SCS-008 §10`）且其**執行**為寫入（**P2**：命令不走事件）；`#18` `SDD-003 §13` 為**同步呼叫**且在寫事件之前（**`#16`**）；`#20` `§5.2` 已標「不做消費端」（批次對帳）；`#21` `SDD-003 §15` 屬**結案**路徑。<br>**④ ★ 併揭露「同步整合缺口」（真缺口，非事件流）**：`SDD-003 §13／§14／§15` 之 **Rewards／Clearing／Dispute → Posting 同步呼叫未實作**（僅 TODO 註解）。**不實作**——分錄之**科目與借貸方向未定義**（`SCS-013 §10` 自載需會計科目設計）→ 實作即**臆造會計**；且 `clearing → posting` **不在 `posting` 之 ACL**。**留待外部輸入**。<br>**⑤ ★ 併修 8 處程式註解與規格不一致**（`grep -rn '消費者：'` 全庫掃描而得，遠多於初判之 3 處）：`rewards`／`dispute`／`clearing`／`merchant`／`payment`／`posting`／`product`／`limit`——**純註解、零行為變更**。僅 `notification` `NotificationService:232` 主動指出清單不一致者**正確保留**。<br>**⑥ 文件批**：`CR-029` → **1.2**（新增 §7.4）；`SAD-002` → **1.2**（§3.6／§3.7 殘留訂閱加刪除線；**§3.9～3.17「主要相依」欄加註「為同步相依、非事件訂閱」**；★ **併補建 §8 修訂記錄**，原檔缺）；`SAD-004` → **1.8**；`SCS-010` → **1.10**／`SCS-011` → **1.11**／`SCS-012` → **1.5**／`SCS-013` → **1.4**。<br>**⑦ `bff-web` 補 Bean Validation（`#A-147`）**：根因為 **`common-spring` 之 `GlobalExceptionHandler` 以 `@ExceptionHandler(ConstraintViolationException.class)` 引用 `compileOnly` 型別**，而其註解稱「由 `spring-boot-starter-web` 提供」——**自 Spring Boot 2.3 起已不成立**（starter-web 不再帶入 validation-api）。★ **模板層根因**：`gen_service_skeleton.py` 之**平台模組模板漏列**此依賴（領域服務模板則有）→ 依「**模板＋既有檔兩邊都動**」兩者皆修；`--check` 通過（**25 模組、缺漏 0**）。★ **現況**：17 領域服務皆有／`bff-web` 為唯一遺漏者／`api-gateway` 正確地不需（WebFlux，該 handler 不生效）。★ **真機複驗：行為零變更**（四區塊結果不變；非 UUID 仍 **400 `CC-PLT-4003`**；無權杖仍 **401**），啟動 `TypeNotPresentException` WARN **消失**（啟動時間 13.4s → **7.2s**）。★ 併更正 `common-spring` 之**過時註解**。 |
| 1.52 | 2026-10-02 | **★★ 通知發送通道解阻塞：SureNotify（電子豹）SMS／Email 真實通道（`#A-148`，`CR-034`）**——BEAM PMO 提供測試 API Key（「請您把 SMS/Notification 的 API Key 存好……接下來靠您了」）→ **解除**鐵則 3 類真阻塞之一「**通知發送通道（僅發送）**」。<br>**① 憑證**：`~/.config/cardcore/notify.env`（**repo 之外**、**600**）＋ `ops/local/env.sh` **若存在才載入** → **不進版控**。**金鑰驗證**：錯金鑰 → **403 `Forbidden`**；正確 → 認證通過（**唯讀**端點，**未發送**）。<br>**② ★★ 資安硬性規定**：外部通道**不得**使用 `ServiceClientHttpClient`——該共用客戶端**一律附加出站 Bearer 權杖**（`CR-010`），**用於外部呼叫即對第三方洩漏本專案 Keycloak 權杖**。→ 改用**獨立** `java.net.http.HttpClient`、**只帶 `x-api-key`**；`SCS-016 §7.13` **明令日後不得以「統一改用共用客戶端」為由改動**；單測**釘住「無 `Authorization` 標頭」**。<br>**③ 實作**：`RecipientResolverPort`（新埠）／`ConfiguredRecipientResolver`／`SureNotifyChannel`（SMS `POST /v1/sms/messages`＋Email `POST /v1/messages`）／`@Order`（SureNotify **10**、Logging **100** fallback）。<br>**④ ★ 零破壞**：`supports()` 需 **enabled 且 api-key 非空** → **無金鑰時 SMS／EMAIL 自動退回 Log 通道**（真機：`SURENOTIFY_ENABLED=false` → `SENT`）。<br>**⑤ ★ 收件人（誠實失敗、不假造）**：`recipientRef` 為 `party:{uuid}` **參照**；`party` **無聯絡資訊端點**（`CR-030 §4.2`）→ 抽埠解耦「**地址從哪來**（產品決策）」vs「**怎麼呼叫閘道**（技術）」，**預設回 `empty` → 誠實失敗**；`test-recipient` **僅供本地／驗證**、**預設為空**、啟動記 **WARN**。<br>**⑥ ★ 真機驗證三項（真實 API）**：**無收件人** → `FAILED`「收件人聯絡資訊不可得…」（重試 1→2）；**真實往返（負樣本）** → `test-recipient=abc` → **廠商回 `invalid address`** → `failReason = SMS：SureNotify 拒絕：abc：invalid address`（**原文保留**）——**證明「服務→適配器→真實廠商→回應解析」全鏈路**，且**未實際發送**；**零破壞** → 退回 Log 通道 `SENT`。<br>**⑦ ★ 實測揭露（文件與實況不符）**：官方文件示例之 `failure` 為**物件** `{}`，**真實回應為陣列** `[{"abc":"invalid address"}]` → 實作**同時容忍兩者**（已回寫 `SCS-016 §7.13`／`CR-034 §1.4`）。<br>**⑧ ★ 併修掃描器偽陽性**：`scan_scaffold` 將 `@FunctionalInterface` 判為「空殼」——該標註**由編譯器保證恰一抽象方法**，屬**刻意之可注入接點**（`SureNotifyChannel.HttpTransport`）。依「**修正掃描器須以人工樣本回測**」紀律新增**負樣本**並豁免 → **`--selftest`：正樣本 5／漏判 0、負樣本 14／誤判 0**；**全庫掃描 0 命中**。<br>**⑨ 測試／關卡**：`notification-service` **86 測 0 失敗**（新增 **20**）；掃描器 3 支（全庫）**0 命中**；`validate_mermaid` **0 錯誤**。<br>**⑩ ★ 併記兩處實作陷阱**：**(i)** YAML **重複鍵 `cardcore`**（`application-local.yml` 已存在）→ 啟動失敗，改為**合併進既有區塊**；**(ii)** 兩建構子（正式＋測試）致 Spring **`No default constructor found`** → 主要建構子須標 **`@Autowired`**。<br>**⑪ ⚠️ 仍阻塞（如實揭露）**：**Push／App Push／LINE**——廠商**不支援**（文件無對應端點）；**收件人來源**（`party` 聯絡資訊端點，**需產品決策**）；**NCC 實名制字樣**與**簡訊網域白名單（5–7 工作天）**（**業務**）。**真實簡訊發送**待 BEAM PMO 提供**測試門號**。**2.3.7 狀態更新**；**鐵則真阻塞由 3 類降為 2.5 類**。 |
| 1.53 | 2026-10-02 | **★★★ 真實簡訊發送成功——通知鏈路完全打通（`#A-149`）**——BEAM PMO 提供測試門號 `<手機已遮蔽>`／`<手機已遮蔽>`（「我立刻完成最後一哩」）。<br>**① 真實簡訊 ×2（完整端到端）**：<br>　**`<手機已遮蔽>`**：通知 **`SENT`**（`sentAt` 03:30:20Z）→ `messageId=20261002033020-0-…` → **SureNotify 事件 `accept` 03:30:20 → `delivery` 03:30:23**（**3 秒**）。<br>　**`<手機已遮蔽>`**：通知 **`SENT`**（`sentAt` 03:31:54Z）→ `messageId=20261002033153-0-…` → **`accept` 03:31:53 → `delivery` 03:31:57**。<br>　★ **收件人（BEAM PMO）實機確認收到**：「已收到您的繳款【BEAM 測試】300元，收到請忽略，謝謝。」<br>　★ **每一環皆有證據**：DB 狀態（`SENT`）＋ 服務日誌（`messageId`）＋ **廠商事件紀錄（`delivery`）** ＋ **人工確認**——**非「單測過了」而已**。<br>**② 為何訊息含「【BEAM 測試】」**（**判斷，非疏漏**）：種子 SMS 模板為「已收到您的繳款 {amount} {currency}，謝謝。」，**對真實手機送出易被誤認為真帳務通知** → 以**模板變數**帶入明確測試標記，**仍走完整生產路徑**（模板→渲染→通道→閘道）。<br>**③ ⚠️ Email 卡在外部前置條件（不在本服務）**：`<信箱已遮蔽>` → **`SureNotify HTTP 400：Invalid: sender domain unverified`**。程式／請求組裝／錯誤呈現**皆已完備**；缺的是 **SureNotify 帳號側「寄件人網域驗證」**（需**自有網域 ＋ DNS 控制權**：`POST /v1/domains/{domain}` → 設 DNS → `PUT`）。→ **SMS 已完全打通；Email 仍阻塞**。<br>**④ ★ 併修（由 Email 失敗驅動）**：非 2xx 之失敗原因原為**原始 JSON** → 改為**優先取 `error` 欄文字**，維運**無須自行挑重點**；**已補單測釘住**（並斷言**不得**夾帶 `{"error"`）。<br>**⑤ ⚠️ NCC 實名制（既有缺口）**：種子 SMS 模板（`PAYMENT_RECEIVED`／`AUTH_APPROVED`）**皆未含實名制字樣**；含網址者另需**網域白名單（5–7 工作天）**。→ **上線前必須補**（**業務文案**，`CR-030 §4.2`）。<br>**⑥ 測試／關卡**：`notification-service` **87 測 0 失敗**（`SureNotifyChannelTest` **16**）。**規格回寫**：`SCS-016 §7.13`（真實發送實測結果表）／`CR-034 §4.1`。<br>**⑦ ★ 阻塞盤點**：**SMS ✅ 完全打通**；**Email ⚠️ 待寄件人網域驗證**（外部）；**Push／LINE ⚠️ 廠商不支援**；**收件人來源 ⚠️ 待產品決策**。 |
| 1.54 | 2026-10-02 | **★★ SureNotify Webhook 接收端完成——簽章驗證、退信／投訴停用名單、寄送前攔阻（`#A-151`）**——BEAM PMO「**同意選 (a)**」（先實作、後驗證）並提供**完整** Webhook 文件（欄位型別表 ＋ 簽章範例）。<br>**① 規格先行**：`SCS-016` **1.7**（§7.14 由「規格先行」轉為「已實作並真機驗證」）。<br>**② 實作**：`POST /api/v1/notifications/surenotify/webhook`（**免認證**——廠商取不到我方 JWT → 列於 `cardcore.security.permit-all`；**簽章驗證即唯一身分依據**）；`V5__surenotify_webhook.sql`（`notification_delivery_events` append-only ＋ `notification_suppressions`）；`SureNotifyWebhookService`／`Controller`／`JdbcDeliveryEventRepository`／`JdbcSuppressionRepository`；★ **`SureNotifyChannel` 於解析地址後、呼叫閘道前查停用名單**。<br>**③ ★★ 回應碼裁定（安全考量）**：**簽章不符 → 401**——若回 200，「**金鑰設錯**」將表現為「**所有回報悄悄消失**」（**靜默資料遺失**）；**已驗章但內容異常（含未知事件型別）→ 200 ＋ WARN**（避免重試風暴）。<br>**④ ★★ 冪等鍵裁定**：**`mail.id`＋`event`＋`timestamp`**——⚠️ **必須含 `timestamp`**：`open`／`click` 可**合法重複發生**，僅以 `mail.id`＋`event` 去重會把**第二次開信誤判為重送而丟失**（已補單測）。<br>**⑤ ★ 廠商文件型別不一致**：欄位表載 `bounce.type` 為 **number**、範例為**字串 `"1"`** → **兩者皆容**；只認一種則**真實事件可能判不出永久退信**（→ 該地址永不被停用＝退信處理形同虛設）。<br>**⑥ 安全**：**未設 API Key 一律拒收**（fail-closed）；`MessageDigest.isEqual`（**常數時間**）；Hex 大小寫正規化；★ 失敗原因**不含地址**（`FAIL_REASON` 會呈現於介面）。<br>**⑦ ★★ 真機驗證 8 項（自簽 HMAC 模擬廠商 POST；真實 HTTP）**：正確簽章 200（**未帶 JWT** → `permit-all` 生效）／錯誤簽章 401／無簽章 401／重送 200 `DUPLICATE`／`bounce` 字串與數字型別皆正確解析並**寫入停用名單**／**暫時退信不停用**／`complaint` 冪等／★★ **寄送前攔阻**（通知 `FAILED`「收件人已停用…」、**未呼叫閘道**）。★ **第 8 項為目的所在：停用名單真的會擋下寄送**。<br>**⑧ ⚠️ 誠實揭露**：廠商**無法** POST 至本地 `localhost` → 以**自簽 HMAC** 驗證全鏈路；**真實廠商事件仍待公開可達之 URL**。<br>**⑨ 測試／關卡**：`notification-service` **105 測 0 失敗**（新增 18）；`validate_sql` 全庫 **66 檔 0 違規**；掃描器 3 支 **0 命中**。**2.3.7 狀態更新**。 |
| 1.60 | 2026-10-02 | **★★ 視窗重啟後之完整性檢查 ＋ 產出 `TRP-002` NFR 驗證計畫（`#A-159`）**（BEAM PMO：「**請先檢查我們的檔案是否有毀損？…請出一份 NFR 驗證計畫（把 60 小節分成「可本地驗證／需外部環境／需客戶參與」三類，標出可立即做的）**」）。<br>**① 完整性檢查 10 項全數通過**：`git fsck` **無損毀**（僅 1 dangling tree，正常殘留）；工作區 clean；最新提交 `c2243e2` 完好；**無 0-byte／截斷檔**（`docs` 146／`backend` 1086／`frontend` 66／`contracts` 18／`tools` 21）；`HANDOVER` 2698 行結尾正常；★ **編譯 OK**（全庫 `compileJava` ＋ `compileTestJava`）；掃描器 3 支 **0 命中**、`validate_sql` **70 檔 0 違規**、`validate_mermaid` **0 錯誤**。<br>**② ⚠️ 服務行程因視窗重啟而停止**（**非檔案毀損**）：8081／8083／8087 皆無 LISTEN——背景 `java -jar` 隨 session 結束。**已列入交接注意**。<br>**③ ★★ `TRP-002`**：`BRD-003` 之 **60 小節／874 項**分三類——**Ａ 可本地驗證 39 小節（689 項／78.8%）**／**Ｂ 需外部環境 13 小節（137 項／15.7%）**／**Ｃ 需客戶參與 8 小節（48 項／5.5%）**；每小節載明**驗證方法／現有工具資產／可否立即做**；Ｂ 類**逐列附「本地替代」**。<br>**④ ★★ 關鍵洞察**：**「未驗證」不等於「都要等外部」**——**近 8 成（689 項）素材在本機已齊備**（17 服務＋1096 單測＋Oracle／PG／Redis／Kafka／Keycloak／OTel 三支柱／Garage 全在 compose）→ 過去一律記「未驗證」＝**自我設限**（同 `GOV-007` 鐵則）。<br>**⑤ ★★ 兩項工具缺口（新發現，且從未量測）**：**(i)** **覆蓋率**——`backend` **完全未配置 JaCoCo** → `TRP-001 §6.2` 第 1 條「行覆蓋 ≥80%／分支 ≥70%／Mutation ≥75%」**目前無法判定**；**(ii)** **前端零測試框架**（`devDependencies` 僅 `typescript`＋`vite`）。<br>**⑥ 可立即做 8 項（不需新工具）＋ 需補工具 6 項**（`TRP-002 §7.1／§7.2`）；**執行順序 N1～N5**。<br>**⑦ 與 `TRP-001 §6.2` 8 項準出對照**：**2 已達成**／**4 可先做或部分先做**／**2 非等外部不可**。<br>**⑧ ⚠️ 併發現帳務缺口**：`HANDOVER §1` 之「**已實測 2/60**」**未在 `BRD-003` 標明是哪 2 小節** → **不臆測**，列 `TRP-002 §7.4` 收尾項。<br>**⑨ 文件批**：`TRP-002`（新）；**WBS 新增 5.4 ✅／5.5 ⬜**。 |
| 1.59 | 2026-10-02 | **★★ 8-6 之「繳款截止日」精確化（`CR-036`，`#A-157`）**（BEAM PMO：「**「精確的繳款截止日」<- 是的，麻煩您直接執行！**」）。<br>**① 問題**：`CR-035 §2.4` 之迄日為**推算值**（入帳日＋帳單週期＋7）；真正的繳款截止日 ＝「**該筆稅款所屬帳單**之帳單日 ＋ 25」，取決於「入帳日是否已過帳單日」→ **最長可高估近一個帳單週期**。而帳單日（`ACCOUNTS.STATEMENT_DAY`）在 `CC_PARTY`，本服務 schema 為 `CC_LIM`——**跨 schema 讀取為架構級禁止**（`SAD-003`／`SQL-07`）。<br>**② ★★ 關鍵洞察**：在帳單出帳**之前**，「該筆稅款屬於哪一期帳單」**尚未確定** → **任何在請款當下算出的值都是猜測**。→ **正解不是「算得更準」，而是「在精確值出現時校正」**。<br>**③ 裁定：兩階段**——① 請款時**調高**（迄日先給推算值 `DERIVED`）；② **帳單出帳時**（`statement.statement.issued.v1`）以**權威 `paymentDueDate`** 覆寫 `raise_until = paymentDueDate + 7`，標記 `STATEMENT`，並同步 `account_limits.temp_end_date`。<br>**④ ★ 校正之歸屬條件**（避免套錯期別）：僅 `status='OPEN'` 且 `due_date_source='DERIVED'` 且 **`raised_on ≤ 出帳日`**——只有「**在該筆調高之後才出帳**」的帳單才承載該筆稅款。「出帳日」取**信封之 `occurredAt`**，**不**由 `paymentDueDate − 25` 反推（避免把 25 天慣例**硬編**進程式）。校正後標記 `STATEMENT` → **冪等**。<br>**⑤ ★ 契約無需變更**：`statement.statement.issued.v1` payload **早已包含** `accountId`／`paymentDueDate`（`SCS-011 §7.2`）→ **不升版、不增欄**。架構變更僅 `SAD-004 §5.2` 之消費者 `notification` → **`notification` ＋ `limit`**（`SAD-002 §3.2` 同步）。**不新增同步呼叫、不開放任何 ACL**。<br>**⑥ ★ `temp_end_date` 同步取「所有 OPEN 紀錄之最晚迄日」**——不得因校正某一筆而**縮短**另一筆之窗口。<br>**⑦ ★★ 真機驗證 3 項（真實 Kafka ＋ Oracle）**：① 8-6 調高 → `temp_end=2026-11-03`／`DERIVED`；② ★ **負樣本**：出帳日 **2026-09-30**（**早於**調高日 10-02）→ **不校正**（仍 `2026-11-03`／`DERIVED`）；③ ★★ **正樣本**：出帳日 **2026-10-02** ＋ 截止日 **2026-11-10** → `raise_until` **→ 2026-11-17**、`due_date_source` **→ `STATEMENT`**、★ `temp_end_date` **同步為 2026-11-17**。<br>**⑧ 測試／關卡**：`limit-service` **69 測 0 失敗**（新增 5）。<br>**⑨ 文件批**：`CR-036`（新）；`SCS-002` → **1.11**（新增 **§7.13** ＋ 真機表）；`SAD-004 §5.2`／`SAD-002 §3.2`（新增訂閱）。<br>**⑩ ⚠️ 仍為推算值之情形**：該歸戶**長期不出帳**時迄日將停留 `DERIVED`（可由 `due_date_source` 辨識）。 |
| 1.58 | 2026-10-02 | **★★ POC-8 之 8-6／8-7 落地——臨時額度串動（`CR-035` Phase 3，`#A-156`）→ ★★ POC-8 八項全數完成**（BEAM PMO：「…**再接著做 Phase 3（8-6/8-7）**」）。<br>**① 生產端（契約缺口之補正）**：`posting.transaction.posted.v1` payload 補**可選** `authorizationId`——`limit-service` 需據以判定「該筆請款是否用了專用額度」。來源 `CC_POSTING.TRANSACTIONS.AUTHORIZATION_ID` **早已存在**（**不需臆造**）；依 `SAD-004 §5.3` **不升版**。⚠️ **缺該欄之舊事件 → 正常略過**（不臆測）。<br>**② 消費端（8-6）**：新增 `PostingTransactionPostedListener`（★ **本服務原已列為該事件之消費者（`SAD-002 §3.2`），惟從未實作**）＋ `SpecialLimitTempAdjustmentService`：依 `authorizationId` 查 `hold_type='SPECIAL'` → **釋放佔用**（請款比對）→ **調高臨時額度** → 落**串動紀錄**。<br>**③ 消費端（8-7）**：併入既有之繳款消費端（**窄埠** `TempAdjustmentRecoveryPort`）→ 依紀錄**先進先出**回收。<br>**④ ★★ 兩項關鍵設計**：**(i)** 8-7 **必須逐筆扣回**，**不得**將 `temporary_amount` 歸零——該欄可能**同時**承載「**人工核准之臨時額度**」，歸零會**誤砍客戶經核准之額度**；**(ii)** `raiseTemporary` 為**相對增量**（**非** `applyAdjustedAmount` 之絕對值，混用會覆蓋人工設定）。<br>**⑤ ★ 更正 `CR-035 §2.4` 之原設計**：原載「以 `CC_STMT.STATEMENTS.payment_due_date` 為準」——**跨 schema**（`SAD-003`／`SQL-07` 禁止），**不可行** → 改以「入帳日 ＋ 帳單週期(25) ＋ 7 日」**推算**並標記 `due_date_source=DERIVED`（**不臆造為「帳單之繳款截止日」**）。<br>**⑥ ★★ 真機驗證 6 項（真實 Kafka ＋ Oracle）**：`V9` 遷移；建立專用佔用；★ 發佈 `posted.v1` → 臨時額度 **0 → 15000**、`temp_end=2026-11-03`（入帳日＋32）、串動紀錄 1 筆（`DERIVED`／`OPEN`）、★ **專用池 `used_amount` 15000 → 0**（請款比對釋放）；★ 繳款 10,000 → **5000**（部分回收、紀錄仍 `OPEN`）；再繳 5,000 → **0** 且紀錄 **`CLOSED`**。<br>**⑦ 測試／關卡**：`limit-service` **64 測**（新增 `SpecialLimitTempAdjustmentServiceTest` 9）＋ `posting-service` **35 測**（新增 2，★ **併修原「恰 8 欄」斷言為 9**），皆 0 失敗。<br>**⑧ 文件批**：`CR-035` → **1.1**（狀態改「全數執行完畢」）；`SCS-002` → **1.10**（新增 **§7.12** ＋ §7.12.4 真機表）；`SCS-007`（payload 補 `authorizationId` 之說明）；`SDD-001` → **1.18**。**WBS 2.2.3e ✅**。<br>**⑨ ★★ 里程碑**：**POC-8 之 8-1～8-7 八項全數完成**。⚠️ **仍未實作（另列）**：精確之繳款截止日（需 `statement` 整合）、部分請款之精確回沖、客層自動取得、政策端點之權限收斂。 |
| 1.57 | 2026-10-02 | **★★ POC-8 之 8-2 落地——「可設定上限」參數化（`CR-035` Phase 2，`#A-155`）＋ ★★ 折衷之處理**（BEAM PMO：「**先處理 8-2 的那個折衷，再接著做 Phase 3**」）。<br>**① ★★ 折衷之處理（本輪重點）**：初版設計把「角色」與「客層」**都**推給請求帶入並承認是折衷。**動工前查證後兩者處置不同**：**(i) 角色 → 折衷移除**——`common-spring` **已有** `JwtRoleConverter`（抽 Keycloak `realm_access.roles`）→ 改為**由伺服器自「已驗證之權杖」決定，不接受請求帶入**（**防提權**）；**(ii) 客層 → 折衷保留但附四項證據**（`CC_LIM` 無產品欄位／`card` 與 `party` 之 ACL 皆不含 `limit-service`／`ACCOUNTS` 無客層欄位）→ 自動取得需**同時**開放兩個 ACL，**與 8-2 之價值不成比例**；故定位為「**政策查詢鍵**而非授權判斷」並列後續。<br>**② ★★ 真機揭露之陷阱（第一版實作即踩）**：M2M 權杖之 `realm_access.roles` 實為 `["default-roles-cardcore","offline_access","uma_authorization"]`——**皆為無區辨力之預設角色**。若先取 realm roles，角色會被解析為 **`offline_access`**（**荒謬**）→ 政策永遠查不到（真機兩次回 422「查無適用政策」）。**修法**：改以 **`azp` 以 `cc-` 開頭**（**與 `ServiceCallerAclManager` 同一判準**，**避免兩套定義**）**優先**判定服務權杖；使用者權杖則取 realm roles 並**排除預設／雜訊角色**。**已補 9 支單元測試釘住**。<br>**③ 實作**：`V8__special_limit_policies.sql`；`SpecialLimitPolicy`／`SpecialLimitPolicyRepository`／`JdbcSpecialLimitPolicyRepository`；`CallerIdentityPort` ＋ `SecurityContextCallerIdentity`；`apply()` 之政策檢核（**僅 SPECIAL**）；`GET /special-limit-policies` ＋ `PUT /special-limit-policies/{roleCode}/{segmentCode}`（**冪等**；停用 ＝ `status=INACTIVE`，**不做 DELETE**——政策屬稽核相關設定）。<br>**④ ★ 兩個 fail-closed 設計**：**(i)** 查無適用政策 → **拒絕**（`CC-LIM-1002`）；**(ii)** 認證停用時角色為 **`UNVERIFIED`** → 須**顯式**設定該角色之政策才會通過（不會「因為沒認證所以放行」）。★ **不設 `('*','*')` 萬用列**——那會使「忘了設定」與「刻意全域放行」無法區分。<br>**⑤ 真機驗證 6 項**：★ **角色解析為權杖之 `azp`**（**非** `offline_access`）；申請 200,000 ≤ 上限 300,000 → **201**；申請 400,000 > 300,000 → **422 `CC-LIM-1002`**「超過可設定上限…（角色 cc-payment-service／客層 *）」；★ **上限調高至 500,000 → 同一請求即通過**（證明為**活值**）；另設他角色之政策**不影響**本次。<br>**⑥ 測試／關卡**：`limit-service` **55 測 0 失敗**（新增 `SecurityContextCallerIdentityTest` 9 ＋ 政策檢核 5）；契約 **96 端點 0 錯誤**。<br>**⑦ 文件批**：`SCS-002` → **1.9**（新增 **§7.11** ＋ §7.11.6 真機表）；`SDD-001` → **1.17**（§3.4 新增 `special_limit_policies` 之變更交付說明）。**WBS 2.2.3d ✅**。<br>**⑧ ⚠️ 仍未實作**：`CR-035` Phase 3（8-6／8-7 臨時額度串動）。 |
| 1.56 | 2026-10-02 | **★★ POC-8 之 8-3／8-5 落地——專用額度「可動用」了（`CR-035` Phase 1，`#A-154`）**（BEAM PMO：「**請接續完成 8-2…8-3/8-5…8-6/8-7…`scope_ref`**」）。<br>**① 動工前事實查證（8 項）**：`LIMIT_HOLDS` **無** `special_limit_id`；★ **全庫無客層欄位**（最接近者 `CC_PRODUCT.PRODUCTS.CARD_GRADE`）、**無 RBAC 資料源**；`posting.transaction.posted.v1` **不含 `authorizationId`**（惟 `CC_POSTING.TRANSACTIONS` **有**該欄 → 可作可選欄位補入）；★ **`card-service` 只接受 `cc-authorization-service`** → `limit-service` **不得**呼叫它（影響 8-2 之客層自動取得）。<br>**② 立 `CR-035`**（四項設計與裁定＋三階段計畫＋契約變更全為**非破壞**＋五項已知限制）。<br>**③ Phase 1 完成**：`V7`（`scope_ref`×2 ＋ `special_limit_id`）；`SpecialLimit#coversMcc`／`hasExplicitScope`；`findApplicable`（**決定性選擇順序**：有明確 scope 者優先）；`increaseUsed`（★ **條件更新** `used_amount + ? <= amount`，防併發超額）；`release` 之**對稱回沖**；新端點 **`special-limits/applicable`**（★ **`applicable=false` 回 200**——「無適用」與「服務故障」必須可區分）；`authorization-service` 之 `SpecialLimitPort` ＋ **三段式池選擇** ＋ `StandInSpecialLimitPort`（**安全降級**：回 empty → 退回卡人額度；**不建本地投影**以免兩份定義漂移）。<br>**④ ★★ 兩個關鍵設計裁定**：**(i)** `BR-04-01`（不佔卡人額度）為**結構性成立**——專用佔用**只**寫 `limit_holds.special_limit_id` ＋ `special_limits.used_amount`，**完全不動 `account_limits`**；**(ii)** **Stand-in 期間專用池佔用 fail-closed**（`JdbcLimitPort` 拋 `CC-LIM-1003`）——以卡人額度代佔將**同時**違反 `BR-04-01` 並造成雙重佔用。<br>**⑤ ★ 需求語意之裁定**：8-4 明訂「**未設定**」才回歸卡人額度、8-5 為「&gt; 額度 → 拒絕」——本實作採**三段式含回退**，理由「**設定專用額度不得使客戶之交易能力反而下降**」。已明載為**解釋**而非隱含假設。<br>**⑥ ★★ 真機驗證 11 項**：`scopeRef` 可設定；MCC 命中／不命中；★ **8-3 之 `availableLimit` 為 310,000（專用佔用不計入）**，而 **8-4 之卡人池確有扣減（310,000 → 295,000）**；`hold_type='SPECIAL'`／`'GENERAL'` 與 `special_limit_id` 之留痕；**8-5 → DECLINED 51**；★ **`account_limits` 全程未變**；釋放 → `used_amount` **15000 → 0**。<br>**⑦ 測試／關卡**：`limit-service` **41 測**（新增 `SpecialLimitPoolTest` 13）＋ `authorization-service` **65 測**（新增 5），**皆 0 失敗**；掃描器 3 支 ×2 服務 **0 命中**；`validate_sql` **0 違規**；`validate_mermaid` **0 錯誤**；`verify_contract_dto`（limit）**0 不符**。<br>**⑧ 文件批**：`CR-035`（新）；`SCS-002` → **1.8**（新增 **§7.10** ＋ §7.10.4 真機表）；`SCS-001` → **1.14**（新增 **§7.16**）；`SDD-001` → **1.16**。**WBS 新增 2.2.3c ✅／2.2.3d ⬜／2.2.3e ⬜**。<br>**⑨ ⚠️ 環境操作之揭露**：授權端之 ACL **不收任何服務**，故 e2e 期間**暫時**以 `CARDCORE_SECURITY_ENABLED=false` 啟動兩服務（否則出站憑證為 NoOp → 401 → 全數 Stand-in）；**驗證後已還原為 SSO 開啟**。 |
| 1.55 | 2026-10-02 | **★★ 專用額度（POC-8）資料模型落地——`CR-014` 裁定 A′ 並實作完成（`#A-153`）**（BEAM PMO：「**請直接執行A選項，謝謝您！**」）。<br>**① ★★ 重大更正（v1.0 之誤述）**：`CR-014 v1.0` 稱本案為「**`SPECIAL_LIMITS` 新表**」，**事實是該表早已存在**——由 `V1__baseline.sql` 建立（該檔係 `gen_flyway_baseline.py` 依 **`SDD-001 §3.4`** 自動產生，2026-09-19 基線套用）；`CR-001 §2.3`（2026-09-19）**亦早已載明**。**根因**：「實測」**只掃 Java 程式碼、未掃 `db/migration` 之 DDL**（同 `CR-033` 之幽靈型）→ 裁定改為 **A′＝接線既有表**（**不重複建表**，`CR-030` P1）。<br>**② 逐欄位裁定**：**沿用既有值域即權威**（`purpose IN ('TAX','INSURANCE','TUITION','MEDICAL','OTHER')`、`status IN ('ACTIVE','EXPIRED','CANCELLED')`，**不自由化**）；**僅補 `currency`**（多幣別正確性）＋ `uk_special_limits_active`（**一歸戶×一幣別×一用途至多一筆 ACTIVE**，防授權端**重複計算專用額度**）；**不加** `scope_ref`／`applicant_id`／`approver_id`（軌跡之權威在 `LIMIT_ADJUSTMENTS`）。<br>**③ 實作**：`V6__special_limits_currency_and_index.sql`；`SpecialLimit`／`SpecialLimitRepository`／`JdbcSpecialLimitRepository`；`apply()` 之 **SPECIAL 基準額度改取專用額度池**（原誤取主檔永久額度 → **覆核門檻會算錯**）、`applyToMaster()` 之 SPECIAL 分支、`revoke()`（**不得**走 `applyAdjustedAmount`）、**查詢端點改讀 `special_limits`**、到期排程併入既有排程、`purpose` 值域檢核（**沿用 `CC-LIM-1003`**，不新設錯誤碼）；**移除**已無呼叫者之 `findByAccountAndType`（死碼）。<br>**④ ★ 契約破壞性變更（已裁定）**：`SpecialLimitItem`（調整視角）→ **`SpecialLimitView`（定義視角）**，並**收斂掉契約中無端點引用之孤兒 schema**；消費端**為零**（前端無引用）→ 直接修正 schema、**不另立 `v2`**（`CR-030` P4）。<br>**⑤ ★ 併同修正真機揭露之契約缺陷**：`POST /limit-adjustments` 之實作欄位原為 **`targetAmount`** 而契約宣告 **`amount`** → **依契約送件一律 400**（`CC-PLT-4002`）；且實作之 **`applicantId` 為必填而契約漏列**（→ `CC-PLT-4003`）。已一併修正（實作改名 `amount`；契約補 `applicantId`（必填）／`currency`）。★ **揭露工具缺口**：`verify_contract_dto` **只核對回應 DTO、不涵蓋請求 DTO** → 此類漂移**編譯／啟動／單測皆不會錯**。<br>**⑥ 真機驗證 13 項（真實 Oracle ＋ Keycloak M2M ＋ 8083）**：`V6` 套用成功；未超限→`EFFECTIVE` 且落庫／超門檻→`PENDING_APPROVAL` **且不落庫**／覆核通過→落庫；**基準額度取自專用池**（`0→200000→300000` 軌跡為證）；**upsert 仍為 1 列**；撤銷→`CANCELLED` **且未觸碰額度主檔**；負樣本（`CREDIT`／未帶）→ **422 `CC-LIM-1003`**；★★ **非快取證明**（**繞過服務**直接改 DB → 查詢立即反映 777777）；**到期**（讀側日期條件先行把關，排程約 40 秒轉 `EXPIRED`）；★★ **不佔卡人額度**（`account_limits` 全程未變）。<br>**⑦ 測試／關卡**：`LimitAdjustmentServiceSpecialTest` **15 測 0 失敗**；`LayeringTest` 通過；`scan_scaffold`／`scan_mockdata`／`scan_faketest` 各 **0 命中**；`validate_sql` **0 違規**；`verify_contract_dto`（limit-service）**0 不符**；`validate_mermaid` **117 區塊 0 錯誤**。<br>**⑧ 文件批**：`CR-014` → **1.1**（並更名為「…裁定」，原檔名「…設計提案」已不符內容）；`SCS-002` → **1.7**（新增 **§7.9**＋§7.9.7 真機驗證表）；`SDD-001` → **1.15**（§3.4 變更交付說明＋ER 補 `currency`；★ **併補 1.14 之漏列**）；`SCS-016` → **1.8**／`CR-034` → **1.1**（併辦：**廠商官方來信逐項核對**——實作無需變更；★ 確認 Email 網域驗證之聯絡管道 **`service@newsleopard.tw`**）。<br>**⑨ WBS**：**2.2.3b ✅ 完成**。⚠️ **仍未實作**（另列）：`8-2` 角色／客層上限、`8-3`/`8-5` **授權端扣抵**、`8-6`/`8-7` 臨時額度串動、`scope_ref`（MCC）。 |
| 1.0 | 2026-09-22 | 初版：依 `HANDOVER` 1.49 實況編製 WBS（7 個工作包、葉任務回指追蹤編號）、依賴關鍵路徑與排序建議、待裁定彙總；定義與 `HANDOVER` 追蹤表之分工（結構 vs 狀態） |
| 1.1 | 2026-09-22 | ⚠️ **本列為回填**（原版僅有 1.0）：`C-12` api-gateway 完成（#A-73）後，WP1 之 1.2.1／1.2.2／1.2.3 由 ⬜ 改 ✅ 並回指 #A-73 |
| 1.2 | 2026-09-22 | ⚠️ **本列為回填**：1.3.1 `C-13` bff-web 首增量 ✅（#A-74）；新增 1.2.4（影子比對）與 1.2.5（閘道業務級授權）兩葉任務 |
| 1.3 | 2026-09-22 | ⚠️ **本列為回填**：2.2.3a `C-11` ✅（#A-75）、2.2.5 `C-24` ✅（#A-75）、2.3.1 `C-2` ✅（#A-76）；新增 2.2.3b（專用額度**資料模型**，待裁定） |
| 1.4 | 2026-09-22 | ⚠️ **本列為回填**：2.2.1 `C-31` ✅（#A-77）；並補正 2.2.5 `C-24` 之漏標（該項實於 #A-75 已完成） |
| 1.5 | 2026-09-22 | 2.2.2 `C-32` ✅（#A-78：三方逐分一致＋計息幣別硬編修復）；併補齊 1.1～1.4 之修訂記錄列（原版僅有 1.0，違反維護規則 1「結構變更即升版」之可追溯要求） |
| 1.6 | 2026-09-22 | 2.2.4 `C-19` ✅（#A-79：逾三日批次＋`reversible()` 放行；真機 e2e 含負樣本與轉換 8 沖正）；**§4 新增待裁定 #10**——繳款轉換 6 之來源狀態（`ALLOCATED` 不可達，與 POC-11 11-3 矛盾；建議改 `POSTED`） |
| 1.7 | 2026-09-22 | **§4 #10 結案**：BEAM PMO 裁定採**方案 B**（轉換 6 來源＝`POSTED`）——`SDD-005` 升 1.6（mermaid／轉換表同步更正）、`SCS-008` 升 1.4（§8.2 候選條件與實測重寫；§10 #5／#6 兩處錯誤敘述更正），並以**真實受理流程**重跑 e2e（無合成資料），候選可達性解除 |
| 1.8 | 2026-09-22 | 2.3.2 `C-4` merchant ✅（#A-80：3 端點＋**`CR-015` 雙軸拆分**——商店型態 vs 業別；單測 27 例；真機 e2e 7 項含 DB 複核兩軸獨立）；`CR-015` → 1.1、`SCS-014` → 1.1、`SDD-001` → 1.8。★ 動工前查證攔下「契約與 DDL 全面脫鉤」，先立 CR 取裁定再實作 |
| 1.9 | 2026-09-22 | 2.3.3 `C-5` clearing ✅（#A-81：清算執行／對帳查詢／結算 3 端點＋**`CR-016` 補齊契約所缺之「清算執行」與「對帳結果」兩張表**、`org` 值域擴充至 8 值、`SETTLEMENTS.DIRECTION`；單測 24 例；真機 e2e 7 項含**遷移前後對照**）；`CR-016` → 1.1、`SCS-013` → 1.1、`SDD-001` → 1.9 |
| 1.10 | 2026-09-22 | **依 BEAM PMO 指示「先一次盤點再逐支實作」**：新增 §4 #11 引 `CR-017`——`C-6`～`C-9` 四服務缺口總盤點（C-6 兩處**正交維度混用**＋缺 3 欄；`CC_RPT`／`CC_MIG`／`CC_NOTIF` **完全無表**；C-8 契約與 SCS 粒度不一致；C-9 發送通道為真阻塞），待裁定後逐支實作 |
| 1.37 | 2026-10-01 | **`GOV-006` 4.8 W-2 第二片：卡片狀態事件生產端 ＋ relay（`#A-118`）**——`card-service` 於 `lifecycle-transitions` 時**同交易**寫 `outbox`（`V8__outbox.sql`，`SDD-001 §3.15` 形狀）；`OutboxRelayScheduler` 週期呼叫 `common-event` 之 `OutboxPublisher`（`KafkaEventPublisher`）。⚠️ **Kafka 值序列化改 `StringSerializer`**（payload 已為信封 JSON 字串）。**真機（兩服務串測）**：`LOCK` → outbox 已發布 → 授權讀模型 `SUSPENDED\|LOCKED\|seq=1`；`UNLOCK` → **`ACTIVE\|ACTIVE\|seq=2\|v=2`**。**4.8 🟡 → ✅** |
| 1.36 | 2026-10-01 | **`GOV-006` 4.8 W-2 第一切片：卡片狀態事件消費端（`card.card.status-changed.v1` → `card_status_caches`）（`#A-117`）**——**缺口**：`V2__read_model.sql` 明文載明該投影，惟**從未有人餵養**（`JdbcCardPort` 讀之、無寫入者 → 讀模型恆空）。**規格先行**：`SAD-004` → 1.3（§5.4）＋ `SCS-001` → 1.9（§7.12）。**實作**：消費端 ＋ 冪等（`consumed_events`）＋ 亂序防護（`last_sequence_no`）＋ 遷移 `V7`。**真機（真實 Kafka＋Oracle）**：BEFORE `count=0` → 發布事件 → upsert `SUSPENDED\|LOCKED\|seq=1`；**冪等**（重送同 `eventId` → version 不變）／**亂序**（送舊 seq → **不覆寫**）皆通過。**4.8 ⬜ → 🟡**；**未竟**：生產端與 relay |
| 1.35 | 2026-10-01 | **`CR-026` 業務 KPI（營運總覽第二階段）（`#A-112`）**——4 統計端點（cards/stats＋card-applications/stats／authorizations/stats／disputes/stats）＋ bff `BffDashboard.business` 區塊 ＋ 前端「業務 KPI」第 4 盒。實作全綠（4 模組 `:test` 0 失敗、掃描器 0 命中、mermaid 0 錯誤、契約 0 錯誤）；前端 typecheck 0 錯誤。★ 自曝並更正 `CR-026 §4` 誤載端點數（card 11→12／auth 10→11 → 實為 9→11／9→10，以 `grep` 實測更正）。★ 真機驗證（對真 Oracle）與前端瀏覽器實測 deferred：Oracle(1521) 未起、docker 空；前端依 BEAM PMO 指示「等業務 KPI CR 執行完畢再做」延後。**SCS-003→1.8／SCS-001→1.7／SCS-012→1.3／SCS-020→1.9** |
| 1.34 | 2026-10-01 | **桶 C 解鎖：`/dashboard` 營運總覽（BEAM PMO 裁定 (a)）**——`SDD-007 §5.4.28`／`SCS-020 §9.11`（新端點 `GET /api/v1/bff/dashboard`）；契約 **87 端點、0 錯誤**；側欄 26 → **27 頁**；**桶 C 31 → 30**、可交付終點 29 → **30 頁**。★ **回訪查證**：掃 17 服務契約**皆無統計端點** → **本版明訂為「系統營運面」**（服務健康／批次／端點連線摘要），**業務 KPI 屬第二階段**。**併修** `verify_contract_dto.py` 對**非封套回應**（`ResponseEntity<byte[]>`）之誤判（含 2 個人樣本回測 → **8/8**） |
| 1.34 | 2026-10-01 | **`C-14` 桶 C 解鎖：營運總覽（`/dashboard`）（`#A-111`）**——BEAM PMO 裁定「挑投報率最高者，先補後端、再規格先行、再實作」採 (a)。**規格先行**：`SCS-020 §9.11` → 契約 **87 端點、0 錯誤** → 實作（DDD 四層）→ `SDD-007 §5.4.28` 逐鈕定義 → 頁面（**側欄 26 → 27 頁**）。★ **回訪查證**：17 服務**皆無統計端點** → **本版明訂為系統營運面**，**業務 KPI 屬第二階段**。**真機**：`DEGRADED`、`routes=null`（不以 0 充數）、未帶 token **401**。**桶 C 31 → 30**；`C-14` 可交付終點 **30 頁** |
| 1.33 | 2026-10-01 | **桶 B 擴充（BEAM PMO 裁定）**——`/onboarding/review`／`/onboarding/approval` **移入桶 B**（核心流程已由 `SDD-007 §5.4.9` 進件作業台涵蓋，狀態機完整）→ **桶 B 9 → 11、桶 C 33 → 31**（合計仍 59 ✅）；樹狀圖／WP3／§3 下一步表同步。差異項（**照會記錄**／**製卡送件**）**另立 CR** 補端點 |
| 1.32 | 2026-10-01 | **桶 C 就緒度重盤之文件同步（`#A-110`）**——①`SDD-007 §5.1` 頁數修正 **60 → 59**（表列實測）；②桶 C 修正 **34 → 33**（原清單仍含已解鎖之 11 頁）；③WP3 之「已實作 8 頁」→ **26 頁**、「餘 48 頁」→ **桶 C 33**、「可交付終點 20」→ **29 頁**；④樹狀圖／關鍵路徑同步；⑤**併揭露待裁定項**：`/onboarding/review`／`/onboarding/approval` 核心流程**已由 `§5.4.9` 涵蓋**，是否移桶 B 待 BEAM PMO 裁定。⚠️ **併補 1.31 之後之落差**：`#A-101`～`#A-109`（健康檢查／稽核軌跡／批次監控／端點管理四頁解鎖並實作、`C-25`／`W-5`／三裁定）**未回填本檔** |
| 1.31 | 2026-09-29 | **`§4 #21` 結案 ✅（`CR-024`／`#A-100`）**——節後開工第一動（BEAM PMO 指示）。★ **原建議之修法方向經查證後修正**：原記「Feign 加 `RequestInterceptor`」**不正確**——`common-spring` **早已有** `ServiceClientHttpClient`（建構子**強制要求**非空之 `OutboundTokenProvider`，**正是為杜絕**「建了客戶端卻沒給憑證來源 → 靜默不帶標頭 → 全部 401」），且 `statement`／`payment`／`posting` **皆用它**，**僅 `authorization-service`／`card-service` 用 Feign**（異類）。→ 改為**直接使用 `ServiceClientHttpClient`**：新增 `LimitServiceHttpClient`／`CardServiceHttpClient`；**刪除** `LimitServiceClient`／`CardServiceClient`；改注入 `RemoteLimitPort`／`RemoteCardPort`／**`RemoteLimitUploadAdapter`（後送路徑）**；移除 `@EnableFeignClients` 與 Feign 依賴。**契約未變**、**降級邏輯未動**。**真機驗證 4 項**：**(i)** 授權 `AUTH000042` → **`APPROVED`**（修正前 `STANDIN`）、`standin_flag=0`；**(ii)** 批次後送 → **`{uploaded:3, remaining:0}`**（修正前 `{uploaded:0, remaining:3}`）；**(iii)** DB：`AUTH000035/036/040/041` 之 **`standin_upload_at` 全部寫入**（修正前恆空）、**待後送殘留 0**；**(iv)** `limit-service` 側 `LIMIT_HOLDS` **`HELD` 17 筆／215,800 分**（遠端確實收到）。**日誌時間戳對照**：`08:42:57～08:45:59` 為修正前 401（排程每 30 秒重試）；**`08:47:20` 之後無任何 401**。**意義**：`#A-98`／`#A-99` **真正閉環**。⚠️ **併登記 `C-45`**（`card-service` 之 `CreditReviewClient`，Feign 同型，本次未處理） |
| 1.30 | 2026-09-24 | ★ **配合 BEAM PMO 指示「中秋節後要能無縫接軌」**——**§3 加註指向 `HANDOVER` 之「★ 節後開工指引」**（①環境怎麼起②上次做到哪 `#A-99`③**下一步第一動**④喚醒指令），並明訂「**下一步做什麼**」以 `HANDOVER` 指引與 `§📊 任務追蹤總表` 為準（本檔為 **WBS 排序**＝結構視角，**不重複記載狀態**） |
| 1.29 | 2026-09-24 | **WP3 `C-14` 批次九（1 頁）——桶 C 解鎖並完成 `/auth/stip` 離線授權與代授權（`#A-99`）**——**規格先行**：動工前查證攔下 `SCS-001 §7.7` 之**規格-實作落差**（三職責中「查詢待補送佇列」與「批次手動上送」**無端點可達**）→ 立 **`CR-023`** → 改 `tools/gen_openapi.py` → **重生契約（77 端點、0 錯誤）** → 實作 2 端點（`GET /authorizations/standin`／`POST /authorizations/standin/advices`）→ `SDD-007 §5.4.23` 逐鈕定義 → 頁面實作（**側欄 21 → 22 頁**）。**真機 4 項**：清單三值篩選正確（**`PENDING` 含 `REFERRAL` 件**——證明未以決策碼篩選）、批次後送 201 `{uploaded:0, remaining:3}`（額度服務 401 → 保留待後送） |
| 1.28 | 2026-09-24 | ★ **清單補正（BEAM PMO 指出「應按工作清單逐步執行」）**：查證發現**本清單自身過期**——**(i)** `§4 #19` 仍寫「**待裁定**」而 `CR-021` 三支端點已於 09-23 執行完畢（#A-95／#A-96）；**(ii)** `§4 #20` 未反映 `CR-022` 之裁定與實作（#A-98）；**(iii)** **WP2 完全未收錄**該兩 CR 之葉任務（僅存於 §4 待裁定清單）→ **依清單執行會漏**。**已補**：WP2 新增 **2.2.6**（`CR-021`）／**2.2.7**（`CR-022`）；`§4 #19`／`#20` 結案；**§3 排序建議更新為現況**——上列 1～5 順位皆已完成，**現行主線為 WP3 `C-14`**（桶 A 6 頁 ✅；**桶 C 之 `/auth/stip` 因 `CR-022` 裁定並實作而解鎖** → 先補 `SDD-007 §5.4.23` 逐鈕定義）。**教訓**：**§4 待裁定項一經裁定並執行，須於同一輪回填 WP 葉任務並結案該列**——否則清單會累積「已做完卻仍顯示待裁定」的幽靈項 |
| 1.27 | 2026-09-24 | **`CR-022` (A) 後送 ＋ §7.8 人工／強制授權 ✅ 實作並真機驗證**（`HANDOVER §3.B #B-2` 續接完成）。**端點**：`POST /authorizations/{authNo}/advices`（(A) 後送）／`POST /authorizations/{authNo}/overrides`（人工／強制授權）。**真機 7 項**：未帶 token `401`（fail-closed）／超門檻 → `REFERRAL`＋`LIMIT_HOLDS=HELD`（仍佔額）／`APPROVE` → `APPROVED` 且佔用仍 `HELD`／`DECLINE` → `DECLINED` 且佔用 `RELEASED`／守門 `CC-AUTH-3001`（非轉人工、含 `force=true`）與 `CC-AUTH-3002`（重複）／後送非 Stand-in 件 `CC-AUTH-3001`／後送遇額度服務不可用 `CC-AUTH-5000`-級錯誤且**保留待上送**。★ **實測揭露 `§4 #21` 之推論已失效**（見該列更新）→ 新增 **`SCS-001 §7.7.1`**（`standin_flag` 依**佔用方式**判定）＋**修實作**（`Authorization` 保留 `standIn` 旗標、`JdbcAuthorizationRepository` 改用之），**真機對照**：修正前 `0` → 修正後 `1`。**單元測試 17 → 41 例**（新增 `ManualReviewPolicyTest`／`OverrideServiceTest`／`StandInUploadServiceTest`＋`AuthorizeUseCaseTest` 6 例，含兩項 §7.7.1 迴歸）。**文件**：`SCS-001` → **1.4**（§7.7.1／§9）；`CR-022` 狀態更新；`GOV-006` → 1.27 |
| 1.26 | 2026-09-23 | **批次八 ✅**（#A-97）：**桶 C 解鎖 2 頁**——`CR-021` 補實作後端點已備：**授權策略檢核 ✅**（`/auth/policy`：check-results 明細 6 項全 `PASS`；**不補畫未檢核項**——僅 6 項具資料來源）／**沖正機制 ✅**（`/switch/auth/reversal`：FULL 沖正 200＋重複沖正 `CC-AUTH-3002` 如實顯示）。桶 C 33／可交付終點 **20 頁**／側欄 **21 頁**。**⚠️ 併更正本文件版本欄漏同步**（修訂記錄 1.25 vs 版本欄 1.24） |
| 1.25 | 2026-09-23 | **批次七續（#A-96）：Stand-in 沖正 ✅ 已採 (a) 並真機驗證**——`StandInLimitPort.release` 與 `hold` **對稱**（遠端優先／失敗降級本地＋WARN／遠端成功後 best-effort 清本地）；`JdbcLimitPort.release` 本地釋放（查無／終態／超釋皆拒）。**FULL 沖正真機驗證**：新建授權 `AUTH000035`（hold 25000）→ 沖正 200 → 本地佔用 `RELEASED|25000|25000`、`AUTH_REVERSALS` 落列、`reversed_at` 標記、**重複沖正 → `CC-AUTH-3002`**。⚠️ **併發現既有缺陷（§4 新增 #21）**：`LimitServiceClient`（Feign）對 limit-service **未接 M2M outbound token → 一律 401 → 授權全數降級 Stand-in**（決策恆為 `STANDIN`）——屬 `CR-010/011` 範疇之既有缺口，非本 CR 引入 |
| 1.24 | 2026-09-23 | **批次七**（#A-95）：**§4 #19 之 (a) 部分執行**——`check-results` ✅（**併修契約陣列性**；查無 404）／`reversals` ✅（V5 沖正表＋`LimitPort.release`；⚠️ **runtime 掛 `StandInLimitPort`**，Stand-in 佔用沖正 → `CC-AUTH-3001` fail-loud，**FULL happy path 待裁定 Stand-in 沖正設計**）／`advices` ⬜（**`SCS-001 §7.7`：(a) 後送 vs (b) 人工覆核，待裁定**）。**新待裁定（§4 #20）**：Stand-in 佔用之沖正設計 |
| 1.23 | 2026-09-23 | **批次六 ✅**（#A-94）：**資料遷移作業 ✅**（W0 試跑標示／舊帳查詢 snapshot 如實）；**⚠️ §5.4.19 撤銷**——`/finance/gl` 之結算**已由 §5.4.10「結算」按鈕涵蓋**（未查按鈕定義即斷言，屬桶 B）；**健康檢查與監控 → 桶 C**（須 bff 健康聚合端點＋頁面定位釐清）；**桶 A 6 頁全數完成**（**桶 A 6／桶 B 9／桶 C 35／終點 18 頁**）；**SCS-003 → 1.7**（補齊 `CR-020` 後端修正之 §3.3／§7.1／§7.4 規格——原與實作直接矛盾）。**WP3 3.2.x 之桶 A 已完成**；桶 C 之 authorization 三支（`CR-021`）與 bff 健康聚合**待裁定** |
| 1.22 | 2026-09-23 | **批次五＋`CR-021`**（#A-93）：①**⚠️ 盤點錯誤自我更正**——`authorization-service` 之 `reversals`／`advices`／`check-results` **三支契約端點完全未實作**（全服務僅 3 端點），**桶 A 11 → 8、桶 C 31 → 34、可交付終點 23 → 20 頁**；②**G-8 擴充**：`verify_contract_dto.py` 之「契約有端點、Controller 無對應方法」由 `infos` 提升為 **hits／warns 二分級**（防偽陽性；回測 **6/6**）；③批次五**額度控管 ✅**（#A-93：查詢／專用額度／佔用 `HELD`／釋放 `RELEASED`，DB 複核一致；分／元雙顯示、送出用分）；④**新增 §4 #19**：authorization 三支端點之處置（**建議 (a) 補實作**——契約語意已完整，且「沖正」為信用卡業務必要功能）＋ `limit-service` 路徑差異待裁定 |
| 1.21 | 2026-09-23 | **`CR-020` 四項 ✅ 已裁定並執行**（#A-92）——BEAM PMO 裁定「**不得以 workaround 心態處理**」（避免未來接手者推翻重來）→ **F1** V7 加 `CARD_APPLICATIONS.CARD_ID`＋發卡回填＋`ACTIVATE` 確實驗證三要素（**F1 採 A**）／**F2** 確實綁定標頭＋冪等生效（**F2 採 B**）／**F3** 查無卡片改 `CC-CARD-4040`（404）／**F4** 採 **B 完整映射表**（內建 `CardBlockCode#status()`，switch 窮盡性檢查防漂移）。真機實測 9 項＋DB 複核；單測新增 10 例＋**負樣本**（回退 F4 → 2 例精準轉紅）。⚠️ 連帶：既有種子卡多數無來源案件 → `ACTIVATE` 回 `CC-CARD-1002`（**fail-closed，刻意**）；`SDD-007` 同步更正「不提供三要素」之**過時記載**。§4 #18 → ✅；併登錄 **`instant-issuance` 仍缺冪等**（`SCS-003 §10 #13`） |
| 1.20 | 2026-09-23 | **WP3 `C-14` 批次四（2 頁）✅**（#A-91：卡片生命週期管理／虛擬卡與 Token 管理）——依 `SDD-007 §5.1.2` **桶 A** 續作；**規格先行**補 §5.4.16／§5.4.17；⚠️ **動工前查證以真機實測攔下四項缺陷** → **`CR-020` 新建**（F1 `threeFactors` 契約宣告但實作未接收〔送錯三要素仍回 201〕／F2 必要標頭未綁定〔不帶亦回 201，**冪等鍵無效**〕／F3 查無卡片回 `CC-CARD-3001`〔409〕而**同服務**其他端點回 `CC-CARD-4040`〔404〕／F4 `ACTIVATE` 未同步 `status`〔DB 實測產生 `ACTIVE|UNACTIVATED`〕）；★ **四項皆落在 G-8 工具之檢查面之外** → 再次證明**工具不可取代端到端實測**。真機瀏覽器＋Keycloak **實測 7 項**並 DB 複核；`typecheck` 0 錯誤／`build` 115 模組。**桶 A 進度 4／11**；**新增 §4 #18**（`CR-020` 四項待裁定） |
| 1.19 | 2026-09-23 | **WP3 `C-14` 批次三（2 頁）✅**（#A-90：產品與費率設定／參數設定）——依 `SDD-007 §5.1.2` **桶 A** 之「可用端點」欄位推進；**規格先行**補 §5.4.14／§5.4.15；真機瀏覽器＋Keycloak **實測 4 情境**（真重疊如實回 `CC-PRD-1002`；生效日為未來時查詢回 `CC-PLT-4040` 係**正確行為**）；`typecheck` 0 錯誤／`build` 成功。**3.2.x 之計法已修正**：改以 §5.1.2 之三桶計（**桶 A 11／桶 B 8／桶 C 31**，**可交付終點 23 頁**），**桶 A 進度 2／11**。⚠️ 併修正 `SDD-007` 之懸空引用（§5.4 引言已引用 v1.11 而版本欄仍 1.10、1.11 列不存在）→ `SDD-007` **1.11** |
| 1.18 | 2026-09-23 | **`CR-019` 批 1 之 15 案 ✅ 已執行並真機驗證**（BEAM PMO「請繼續」）：契約 14 案＋實作 1 案；**比對器 19 處 → 2 處**（剩餘恰為 C-1／C-4）；OpenAPI 0 錯誤；影響範圍以 `diff -rq` 確認僅 4 檔；真機回歸實測 4 端點（transactions 陣列／`CardStatusView` 欄位／`RewardRuleView` 欄位／`SpecialLimitsView` 改名後正常）。⚠️ **新增 §4 #17**：`INSTALLMENT_PERIODS.AMOUNT` 之設計意圖（(a) 本期本金 vs (b) 應繳總額）——**批 1 執行前查證發現原判定有誤**（`principalAmount` 係 `amount` 之重複欄位），已剔除並改列待裁定。`CR-019` → **1.2** |
| 1.17 | 2026-09-23 | **BEAM PMO 三項裁定之執行**：①**§4 #15 ✅ 已補列**——原型**模組 9／10／12／13** 補列為 `SDD-007 §5.1` **4 群 14 頁**（群數 10 → **14**、頁數 46 → **60**），併新增 **§5.1.1 逐 L2 對照表**；⚠️ **併明確界定範圍**：模組 12／13 之 6 頁**無對應本專案服務**（TMS／ACI 產品）→「已補列」≠「已承諾實作」，**SoW 確認仍待裁定**。②**`CR-019` §3.6 逐案判定表**已產出（**20 案**，含契約／DTO 原文對照、預判方向、影響面；分批 1／2／3）→ **新增 §4 #16 待核定**。③**`CR-019` §3.7 E-1 已執行**——`merchantId` 語意修正（回應改回**業務代碼**）＋真機 3 情境（含**往返回查 200**，修正前 404）＋ DB 複核（未動 DDL）。`SDD-007` 之 1.9 列已擴充為含補列；`CR-019` → **1.1** |
| 1.16 | 2026-09-23 | **§4 #13 之 merchant 部分 ✅ 與 #14 ✅（兩項皆由「待裁定」轉為「已執行」）**——**#13（採 (a) 補列）**：以客戶認可原型（13 大模組）為證據，確認**模組 11「收單作業平台」**（9 個 L2）即 `merchant-service` 之歸屬而 §5.1 原完全缺席；已於 `SDD-007 §5.1` 新增「**收單與商店**」群（9 → **10 群**／45 → **46 頁**）＋ **§5.4.13** 逐鈕定義＋實作＋真實瀏覽器實測 → **#A-87**。**#14**：新增 `tools/verify_contract_dto.py`（零相依、`--selftest` **4/4**）＋ `CSP-001` → **1.9**（§7.1 **G-8** 檢查點）；全庫掃得 **19 處**契約↔實作不符 → **`CR-019`**。**§4 新增 #15**：原型**模組 9／10／12／13** 於 §5.1 亦無對應群（#13 之併發發現）——**待裁定**是否補列或屬 SoW 外。⚠️ **併修本文件之自身缺陷**：上一輪（1.15）插入 #13／#14 時**誤覆蓋掉 #12**（`validate_sql` 掃描範圍列），本版已補回（§4 現為 #1～#15 連續） |
| 1.15 | 2026-09-22 | **`C-14` WebUI 批次一（3 頁）✅**（#A-86：清算與請款／爭議款處理／報表作業；**規格先行**補 `SDD-007 §5.4.10～§5.4.12`；`App.tsx` 重構為 `PAGES` 單一來源；真實瀏覽器＋Keycloak 實測 **8 情境**；`typecheck` 0 錯誤／`build` 107 模組）。⚠️ **動工前查證攔下 2 處契約缺陷**：`CR-016` → **1.2**（對帳回應型別：實作回陣列、契約誤宣告單一物件）、**`CR-018`** 新建（`ReportJobView.errorDetail` 實作有、契約無）。`SDD-007` → **1.8**（併修其修訂記錄版本排序）。**§4 新增 #13**（`merchant-service` 於 §5.1 **無對應頁面**——待裁定）、**#14**（契約 vs 實作逐端點核對之檢查點）。**餘 34 頁** |
| 1.14 | 2026-09-22 | **逐支實作第四支（末支）：2.3.7 `C-9` notification ✅**（#A-85：依裁定 F **通道抽象先行**——`NotificationChannelPort` ＋ **本地 Log 通道 stand-in**，不呼叫任何閘道；V2 建 2 表＋**內建 8 筆模板**；**新增 3 錯誤碼**（`CC-NOT-1002`／`1003`／`4040`，`SDD-006` → 122 碼）；單測 **31 例**；真機 e2e **12 項**含三種 422 **受理即擋**、**重試後 `FAILED`＋原因**、DB 複核）。`CR-017` → 1.5、`SCS-016` → 1.1、`SDD-001` → 1.13（新增 §3.18）、**`SDD-005` → 1.7（新增 §13 通知狀態機）**。★ **`C-6`～`C-9` 四服務全數結案**；⚠️ 併揭露 `validate_sql` 掃描範圍模糊（**待裁定**） |
| 1.13 | 2026-09-22 | **逐支實作第三支：2.3.6 `C-8` migration ✅**（#A-84：**兩層 `WAVE`＋`JOB`**＋舊帳對映；契約加 `waveCode`；單測 17 例；真機 e2e 6 項含**試跑不動任何列 vs 非試跑標記**、`W9`→422）；`CR-017` → 1.4、`SCS-015` → 1.1、`SDD-001` → 1.12（新增 §3.17） |
| 1.12 | 2026-09-22 | **逐支實作第二支：2.3.5 `C-7` report ✅**（#A-83：Oracle 作業指標＋**Postgres 讀模型**（**CQRS 讀側首例**）＋批次投影＋非同步作業產生；單測 16 例；真機 e2e 6 項含投影與權威側逐欄一致、`XLSX` 明確 `FAILED`）；`CR-017` → 1.3、`SCS-017` → 1.1、`SDD-001` → 1.11（新增 §3.16 `report` schema） |
| 1.11 | 2026-09-22 | **逐支實作第一支：2.3.4 `C-6` dispute ✅**（#A-82：3 端點＋`CR-017` **雙軸拆分**——`DISPUTE_REASON` 原因軸／`WORKFLOW_STAGE` 作業階段軸；`DISPUTE_TYPE` 回歸程序類型、`STAGE` 保留組織階段並以 `orgStage` 回傳；單測 19 例；真機 e2e 6 項含**雙軸同列獨立**之 DB 複核）；`CR-017` → 1.2、`SCS-012` → 1.2、`SDD-001` → 1.10 |