CR #201 » GOV-006_任務追蹤清單_WBS.md

內容更新：內部稱謂去識別化（2026-10-18） - Redmine Admin, 10/18/2026 05:39 AM

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 ✅
性質	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 複核） ✅ #A-148（2026-10-02：`CR-034`／`SCS-016 §7.13`——SureNotify（電子豹）SMS／Email 真實通道接入，通過真實 API 往返驗證）→ 「實際發送」已解阻塞（SMS／Email）；★ 資安：外部通道不得用 `ServiceClientHttpClient`（會洩漏內部 Bearer 權杖）→ 獨立客戶端、只帶 `x-api-key`；★ 零破壞（無金鑰時自動退回 Log 通道）；★ 收件人抽出 `RecipientResolverPort`（預設誠實失敗、不假造） ✅ #A-149（2026-10-02：★★★ 真實簡訊發送成功——`<手機已遮蔽>`／`<手機已遮蔽>` 皆 `delivery` 送達（3～4 秒），收件人實機確認收到）→ SMS 完全打通 ✅ #A-151（2026-10-02：SureNotify Webhook 接收端完成——簽章驗證／退信與投訴停用名單／寄送前攔阻；真機驗證 8 項） ⚠️ 仍阻塞：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`
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
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. 維護規則

狀態異動只寫 HANDOVER（含實測證據）；本文件僅在 WBS 結構變更（新增／拆分／排序調整）時升版。
葉任務完成時：HANDOVER 移列 §3.A（取得 #A-xx）→ 本文件之狀態欄改 ✅ 並回指該編號。
新需求一律先入 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」）。 ① ★★ `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 條。 ② ★★ 揭露「幽靈待辦」根因（以 `git show 9937bd0` 取 `CR-030` 前之 `SAD-004 §5.2` 為證）：該 8 條係依 `CR-030` 之前之清單盤點；`CR-030 §2 #5` 將該清單重寫為唯一權威時已移除／改判這些消費邊，惟未回寫 `CR-029` → 仍顯示為待辦。教訓：重寫權威清單後，必須回寫「以舊清單為基礎之盤點」。 ③ 逐條理由（`#13`／`#18`／`#20`／`#21` 皆「查無事件消費語意」）：`#13` 自扣屬未實作功能（`SCS-008 §10`）且其執行為寫入（P2：命令不走事件）；`#18` `SDD-003 §13` 為同步呼叫且在寫事件之前（`#16`）；`#20` `§5.2` 已標「不做消費端」（批次對帳）；`#21` `SDD-003 §15` 屬結案路徑。 ④ ★ 併揭露「同步整合缺口」（真缺口，非事件流）：`SDD-003 §13／§14／§15` 之 Rewards／Clearing／Dispute → Posting 同步呼叫未實作（僅 TODO 註解）。不實作——分錄之科目與借貸方向未定義（`SCS-013 §10` 自載需會計科目設計）→ 實作即臆造會計；且 `clearing → posting` 不在 `posting` 之 ACL。留待外部輸入。 ⑤ ★ 併修 8 處程式註解與規格不一致（`grep -rn '消費者：'` 全庫掃描而得，遠多於初判之 3 處）：`rewards`／`dispute`／`clearing`／`merchant`／`payment`／`posting`／`product`／`limit`——純註解、零行為變更。僅 `notification` `NotificationService:232` 主動指出清單不一致者正確保留。 ⑥ 文件批：`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。 ⑦ `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 類真阻塞之一「通知發送通道（僅發送）」。 ① 憑證：`~/.config/cardcore/notify.env`（repo 之外、600）＋ `ops/local/env.sh` 若存在才載入 → 不進版控。金鑰驗證：錯金鑰 → 403 `Forbidden`；正確 → 認證通過（唯讀端點，未發送）。 ② ★★ 資安硬性規定：外部通道不得使用 `ServiceClientHttpClient`——該共用客戶端一律附加出站 Bearer 權杖（`CR-010`），用於外部呼叫即對第三方洩漏本專案 Keycloak 權杖。→ 改用獨立 `java.net.http.HttpClient`、只帶 `x-api-key`；`SCS-016 §7.13` 明令日後不得以「統一改用共用客戶端」為由改動；單測釘住「無 `Authorization` 標頭」。 ③ 實作：`RecipientResolverPort`（新埠）／`ConfiguredRecipientResolver`／`SureNotifyChannel`（SMS `POST /v1/sms/messages`＋Email `POST /v1/messages`）／`@Order`（SureNotify 10、Logging 100 fallback）。 ④ ★ 零破壞：`supports()` 需 enabled 且 api-key 非空 → 無金鑰時 SMS／EMAIL 自動退回 Log 通道（真機：`SURENOTIFY_ENABLED=false` → `SENT`）。 ⑤ ★ 收件人（誠實失敗、不假造）：`recipientRef` 為 `party:{uuid}` 參照；`party` 無聯絡資訊端點（`CR-030 §4.2`）→ 抽埠解耦「地址從哪來（產品決策）」vs「怎麼呼叫閘道（技術）」，預設回 `empty` → 誠實失敗；`test-recipient` 僅供本地／驗證、預設為空、啟動記 WARN。 ⑥ ★ 真機驗證三項（真實 API）：無收件人 → `FAILED`「收件人聯絡資訊不可得…」（重試 1→2）；真實往返（負樣本） → `test-recipient=abc` → 廠商回 `invalid address` → `failReason = SMS：SureNotify 拒絕：abc：invalid address`（原文保留）——證明「服務→適配器→真實廠商→回應解析」全鏈路，且未實際發送；零破壞 → 退回 Log 通道 `SENT`。 ⑦ ★ 實測揭露（文件與實況不符）：官方文件示例之 `failure` 為物件 `{}`，真實回應為陣列 `[{"abc":"invalid address"}]` → 實作同時容忍兩者（已回寫 `SCS-016 §7.13`／`CR-034 §1.4`）。 ⑧ ★ 併修掃描器偽陽性：`scan_scaffold` 將 `@FunctionalInterface` 判為「空殼」——該標註由編譯器保證恰一抽象方法，屬刻意之可注入接點（`SureNotifyChannel.HttpTransport`）。依「修正掃描器須以人工樣本回測」紀律新增負樣本並豁免 → `--selftest`：正樣本 5／漏判 0、負樣本 14／誤判 0；全庫掃描 0 命中。 ⑨ 測試／關卡：`notification-service` 86 測 0 失敗（新增 20）；掃描器 3 支（全庫）0 命中；`validate_mermaid` 0 錯誤。 ⑩ ★ 併記兩處實作陷阱：(i) YAML 重複鍵 `cardcore`（`application-local.yml` 已存在）→ 啟動失敗，改為合併進既有區塊；(ii) 兩建構子（正式＋測試）致 Spring `No default constructor found` → 主要建構子須標 `@Autowired`。 ⑪ ⚠️ 仍阻塞（如實揭露）：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 提供測試門號 `<手機已遮蔽>`／`<手機已遮蔽>`（「我立刻完成最後一哩」）。 ① 真實簡訊 ×2（完整端到端）：　`<手機已遮蔽>`：通知 `SENT`（`sentAt` 03:30:20Z）→ `messageId=20261002033020-0-…` → SureNotify 事件 `accept` 03:30:20 → `delivery` 03:30:23（3 秒）。　`<手機已遮蔽>`：通知 `SENT`（`sentAt` 03:31:54Z）→ `messageId=20261002033153-0-…` → `accept` 03:31:53 → `delivery` 03:31:57。　★ 收件人（BEAM PMO）實機確認收到：「已收到您的繳款【BEAM 測試】300元，收到請忽略，謝謝。」　★ 每一環皆有證據：DB 狀態（`SENT`）＋服務日誌（`messageId`）＋廠商事件紀錄（`delivery`）＋人工確認——非「單測過了」而已。 ② 為何訊息含「【BEAM 測試】」（判斷，非疏漏）：種子 SMS 模板為「已收到您的繳款 {amount} {currency}，謝謝。」，對真實手機送出易被誤認為真帳務通知 → 以模板變數帶入明確測試標記，仍走完整生產路徑（模板→渲染→通道→閘道）。 ③ ⚠️ Email 卡在外部前置條件（不在本服務）：`<信箱已遮蔽>` → `SureNotify HTTP 400：Invalid: sender domain unverified`。程式／請求組裝／錯誤呈現皆已完備；缺的是 SureNotify 帳號側「寄件人網域驗證」（需自有網域＋ DNS 控制權：`POST /v1/domains/{domain}` → 設 DNS → `PUT`）。→ SMS 已完全打通；Email 仍阻塞。 ④ ★ 併修（由 Email 失敗驅動）：非 2xx 之失敗原因原為原始 JSON → 改為優先取 `error` 欄文字，維運無須自行挑重點；已補單測釘住（並斷言不得夾帶 `{"error"`）。 ⑤ ⚠️ NCC 實名制（既有缺口）：種子 SMS 模板（`PAYMENT_RECEIVED`／`AUTH_APPROVED`）皆未含實名制字樣；含網址者另需網域白名單（5–7 工作天）。→ 上線前必須補（業務文案，`CR-030 §4.2`）。 ⑥ 測試／關卡：`notification-service` 87 測 0 失敗（`SureNotifyChannelTest` 16）。規格回寫：`SCS-016 §7.13`（真實發送實測結果表）／`CR-034 §4.1`。 ⑦ ★ 阻塞盤點：SMS ✅ 完全打通；Email ⚠️ 待寄件人網域驗證（外部）；Push／LINE ⚠️ 廠商不支援；收件人來源 ⚠️ 待產品決策。
1.54	2026-10-02	★★ SureNotify Webhook 接收端完成——簽章驗證、退信／投訴停用名單、寄送前攔阻（`#A-151`）——BEAM PMO「同意選 (a)」（先實作、後驗證）並提供完整 Webhook 文件（欄位型別表＋簽章範例）。 ① 規格先行：`SCS-016` 1.7（§7.14 由「規格先行」轉為「已實作並真機驗證」）。 ② 實作：`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` 於解析地址後、呼叫閘道前查停用名單。 ③ ★★ 回應碼裁定（安全考量）：簽章不符 → 401——若回 200，「金鑰設錯」將表現為「所有回報悄悄消失」（靜默資料遺失）；已驗章但內容異常（含未知事件型別）→ 200 ＋ WARN（避免重試風暴）。 ④ ★★ 冪等鍵裁定：`mail.id`＋`event`＋`timestamp`——⚠️ 必須含 `timestamp`：`open`／`click` 可合法重複發生，僅以 `mail.id`＋`event` 去重會把第二次開信誤判為重送而丟失（已補單測）。 ⑤ ★ 廠商文件型別不一致：欄位表載 `bounce.type` 為 number、範例為字串 `"1"` → 兩者皆容；只認一種則真實事件可能判不出永久退信（→ 該地址永不被停用＝退信處理形同虛設）。 ⑥ 安全：未設 API Key 一律拒收（fail-closed）；`MessageDigest.isEqual`（常數時間）；Hex 大小寫正規化；★ 失敗原因不含地址（`FAIL_REASON` 會呈現於介面）。 ⑦ ★★ 真機驗證 8 項（自簽 HMAC 模擬廠商 POST；真實 HTTP）：正確簽章 200（未帶 JWT → `permit-all` 生效）／錯誤簽章 401／無簽章 401／重送 200 `DUPLICATE`／`bounce` 字串與數字型別皆正確解析並寫入停用名單／暫時退信不停用／`complaint` 冪等／★★ 寄送前攔阻（通知 `FAILED`「收件人已停用…」、未呼叫閘道）。★ 第 8 項為目的所在：停用名單真的會擋下寄送。 ⑧ ⚠️ 誠實揭露：廠商無法 POST 至本地 `localhost` → 以自簽 HMAC 驗證全鏈路；真實廠商事件仍待公開可達之 URL。 ⑨ 測試／關卡：`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 小節分成「可本地驗證／需外部環境／需客戶參與」三類，標出可立即做的）」）。 ① 完整性檢查 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 錯誤。 ② ⚠️ 服務行程因視窗重啟而停止（非檔案毀損）：8081／8083／8087 皆無 LISTEN——背景 `java -jar` 隨 session 結束。已列入交接注意。 ③ ★★ `TRP-002`：`BRD-003` 之 60 小節／874 項分三類——Ａ可本地驗證 39 小節（689 項／78.8%）／Ｂ需外部環境 13 小節（137 項／15.7%）／Ｃ需客戶參與 8 小節（48 項／5.5%）；每小節載明驗證方法／現有工具資產／可否立即做；Ｂ類逐列附「本地替代」。 ④ ★★ 關鍵洞察：「未驗證」不等於「都要等外部」——近 8 成（689 項）素材在本機已齊備（17 服務＋1096 單測＋Oracle／PG／Redis／Kafka／Keycloak／OTel 三支柱／Garage 全在 compose）→ 過去一律記「未驗證」＝自我設限（同 `GOV-007` 鐵則）。 ⑤ ★★ 兩項工具缺口（新發現，且從未量測）：(i) 覆蓋率——`backend` 完全未配置 JaCoCo → `TRP-001 §6.2` 第 1 條「行覆蓋 ≥80%／分支 ≥70%／Mutation ≥75%」目前無法判定；(ii) 前端零測試框架（`devDependencies` 僅 `typescript`＋`vite`）。 ⑥ 可立即做 8 項（不需新工具）＋需補工具 6 項（`TRP-002 §7.1／§7.2`）；執行順序 N1～N5。 ⑦ 與 `TRP-001 §6.2` 8 項準出對照：2 已達成／4 可先做或部分先做／2 非等外部不可。 ⑧ ⚠️ 併發現帳務缺口：`HANDOVER §1` 之「已實測 2/60」未在 `BRD-003` 標明是哪 2 小節 → 不臆測，列 `TRP-002 §7.4` 收尾項。 ⑨ 文件批：`TRP-002`（新）；WBS 新增 5.4 ✅／5.5 ⬜。
1.59	2026-10-02	★★ 8-6 之「繳款截止日」精確化（`CR-036`，`#A-157`）（BEAM PMO：「「精確的繳款截止日」<- 是的，麻煩您直接執行！」）。 ① 問題：`CR-035 §2.4` 之迄日為推算值（入帳日＋帳單週期＋7）；真正的繳款截止日＝「該筆稅款所屬帳單之帳單日＋ 25」，取決於「入帳日是否已過帳單日」→ 最長可高估近一個帳單週期。而帳單日（`ACCOUNTS.STATEMENT_DAY`）在 `CC_PARTY`，本服務 schema 為 `CC_LIM`——跨 schema 讀取為架構級禁止（`SAD-003`／`SQL-07`）。 ② ★★ 關鍵洞察：在帳單出帳之前，「該筆稅款屬於哪一期帳單」尚未確定 → 任何在請款當下算出的值都是猜測。→ 正解不是「算得更準」，而是「在精確值出現時校正」。 ③ 裁定：兩階段——① 請款時調高（迄日先給推算值 `DERIVED`）；② 帳單出帳時（`statement.statement.issued.v1`）以權威 `paymentDueDate` 覆寫 `raise_until = paymentDueDate + 7`，標記 `STATEMENT`，並同步 `account_limits.temp_end_date`。 ④ ★ 校正之歸屬條件（避免套錯期別）：僅 `status='OPEN'` 且 `due_date_source='DERIVED'` 且 `raised_on ≤ 出帳日`——只有「在該筆調高之後才出帳」的帳單才承載該筆稅款。「出帳日」取信封之 `occurredAt`，不由 `paymentDueDate − 25` 反推（避免把 25 天慣例硬編進程式）。校正後標記 `STATEMENT` → 冪等。 ⑤ ★ 契約無需變更：`statement.statement.issued.v1` payload 早已包含 `accountId`／`paymentDueDate`（`SCS-011 §7.2`）→ 不升版、不增欄。架構變更僅 `SAD-004 §5.2` 之消費者 `notification` → `notification` ＋ `limit`（`SAD-002 §3.2` 同步）。不新增同步呼叫、不開放任何 ACL。 ⑥ ★ `temp_end_date` 同步取「所有 OPEN 紀錄之最晚迄日」——不得因校正某一筆而縮短另一筆之窗口。 ⑦ ★★ 真機驗證 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。 ⑧ 測試／關卡：`limit-service` 69 測 0 失敗（新增 5）。 ⑨ 文件批：`CR-036`（新）；`SCS-002` → 1.11（新增 §7.13 ＋真機表）；`SAD-004 §5.2`／`SAD-002 §3.2`（新增訂閱）。 ⑩ ⚠️ 仍為推算值之情形：該歸戶長期不出帳時迄日將停留 `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）」）。 ① 生產端（契約缺口之補正）：`posting.transaction.posted.v1` payload 補可選 `authorizationId`——`limit-service` 需據以判定「該筆請款是否用了專用額度」。來源 `CC_POSTING.TRANSACTIONS.AUTHORIZATION_ID` 早已存在（不需臆造）；依 `SAD-004 §5.3` 不升版。⚠️ 缺該欄之舊事件 → 正常略過（不臆測）。 ② 消費端（8-6）：新增 `PostingTransactionPostedListener`（★ 本服務原已列為該事件之消費者（`SAD-002 §3.2`），惟從未實作）＋ `SpecialLimitTempAdjustmentService`：依 `authorizationId` 查 `hold_type='SPECIAL'` → 釋放佔用（請款比對）→ 調高臨時額度 → 落串動紀錄。 ③ 消費端（8-7）：併入既有之繳款消費端（窄埠 `TempAdjustmentRecoveryPort`）→ 依紀錄先進先出回收。 ④ ★★ 兩項關鍵設計：(i) 8-7 必須逐筆扣回，不得將 `temporary_amount` 歸零——該欄可能同時承載「人工核准之臨時額度」，歸零會誤砍客戶經核准之額度；(ii) `raiseTemporary` 為相對增量（非 `applyAdjustedAmount` 之絕對值，混用會覆蓋人工設定）。 ⑤ ★ 更正 `CR-035 §2.4` 之原設計：原載「以 `CC_STMT.STATEMENTS.payment_due_date` 為準」——跨 schema（`SAD-003`／`SQL-07` 禁止），不可行 → 改以「入帳日＋帳單週期(25) ＋ 7 日」推算並標記 `due_date_source=DERIVED`（不臆造為「帳單之繳款截止日」）。 ⑥ ★★ 真機驗證 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`。 ⑦ 測試／關卡：`limit-service` 64 測（新增 `SpecialLimitTempAdjustmentServiceTest` 9）＋ `posting-service` 35 測（新增 2，★ 併修原「恰 8 欄」斷言為 9），皆 0 失敗。 ⑧ 文件批：`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 ✅。 ⑨ ★★ 里程碑：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」）。 ① ★★ 折衷之處理（本輪重點）：初版設計把「角色」與「客層」都推給請求帶入並承認是折衷。動工前查證後兩者處置不同：(i) 角色 → 折衷移除——`common-spring` 已有 `JwtRoleConverter`（抽 Keycloak `realm_access.roles`）→ 改為由伺服器自「已驗證之權杖」決定，不接受請求帶入（防提權）；(ii) 客層 → 折衷保留但附四項證據（`CC_LIM` 無產品欄位／`card` 與 `party` 之 ACL 皆不含 `limit-service`／`ACCOUNTS` 無客層欄位）→ 自動取得需同時開放兩個 ACL，與 8-2 之價值不成比例；故定位為「政策查詢鍵而非授權判斷」並列後續。 ② ★★ 真機揭露之陷阱（第一版實作即踩）：M2M 權杖之 `realm_access.roles` 實為 `["default-roles-cardcore","offline_access","uma_authorization"]`——皆為無區辨力之預設角色。若先取 realm roles，角色會被解析為 `offline_access`（荒謬）→ 政策永遠查不到（真機兩次回 422「查無適用政策」）。修法：改以 `azp` 以 `cc-` 開頭（與 `ServiceCallerAclManager` 同一判準，避免兩套定義）優先判定服務權杖；使用者權杖則取 realm roles 並排除預設／雜訊角色。已補 9 支單元測試釘住。 ③ 實作：`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——政策屬稽核相關設定）。 ④ ★ 兩個 fail-closed 設計：(i) 查無適用政策 → 拒絕（`CC-LIM-1002`）；(ii) 認證停用時角色為 `UNVERIFIED` → 須顯式設定該角色之政策才會通過（不會「因為沒認證所以放行」）。★ *不設 `('','')` 萬用列——那會使「忘了設定」與「刻意全域放行」無法區分。 ⑤ 真機驗證 6 項：★ 角色解析為權杖之 `azp`（非 `offline_access`）；申請 200,000 ≤ 上限 300,000 → 201；申請 400,000 > 300,000 → 422 `CC-LIM-1002`「超過可設定上限…（角色 cc-payment-service／客層）」；★ 上限調高至 500,000 → 同一請求即通過（證明為活值）；另設他角色之政策不影響本次。 ⑥ 測試／關卡：`limit-service` 55 測 0 失敗（新增 `SecurityContextCallerIdentityTest` 9 ＋政策檢核 5）；契約 96 端點 0 錯誤。 ⑦ 文件批：`SCS-002` → 1.9（新增 §7.11 ＋ §7.11.6 真機表）；`SDD-001` → 1.17（§3.4 新增 `special_limit_policies` 之變更交付說明）。WBS 2.2.3d ✅。 ⑧ ⚠️ 仍未實作：`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`」）。 ① 動工前事實查證（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 之客層自動取得）。 ② 立 `CR-035`（四項設計與裁定＋三階段計畫＋契約變更全為非破壞＋五項已知限制）。 ③ 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 → 退回卡人額度；不建本地投影以免兩份定義漂移）。 ④ ★★ 兩個關鍵設計裁定：(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` 並造成雙重佔用。 ⑤ ★ 需求語意之裁定：8-4 明訂「未設定」才回歸卡人額度、8-5 為「> 額度 → 拒絕」——本實作採三段式含回退，理由「設定專用額度不得使客戶之交易能力反而下降」。已明載為解釋而非隱含假設。 ⑥ ★★ 真機驗證 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。 ⑦ 測試／關卡：`limit-service` 41 測（新增 `SpecialLimitPoolTest` 13）＋ `authorization-service` 65 測（新增 5），皆 0 失敗；掃描器 3 支 ×2 服務 0 命中；`validate_sql` 0 違規；`validate_mermaid` 0 錯誤；`verify_contract_dto`（limit）0 不符。 ⑧ 文件批：`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 ⬜。 ⑨ ⚠️ 環境操作之揭露：授權端之 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選項，謝謝您！」）。 ① ★★ 重大更正（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）。 ② 逐欄位裁定：沿用既有值域即權威（`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`）。 ③ 實作：`V6__special_limits_currency_and_index.sql`；`SpecialLimit`／`SpecialLimitRepository`／`JdbcSpecialLimitRepository`；`apply()` 之 SPECIAL 基準額度改取專用額度池（原誤取主檔永久額度 → 覆核門檻會算錯）、`applyToMaster()` 之 SPECIAL 分支、`revoke()`（不得走 `applyAdjustedAmount`）、查詢端點改讀 `special_limits`、到期排程併入既有排程、`purpose` 值域檢核（沿用 `CC-LIM-1003`，不新設錯誤碼）；移除已無呼叫者之 `findByAccountAndType`（死碼）。 ④ ★ 契約破壞性變更（已裁定）：`SpecialLimitItem`（調整視角）→ `SpecialLimitView`（定義視角），並收斂掉契約中無端點引用之孤兒 schema；消費端為零（前端無引用）→ 直接修正 schema、不另立 `v2`（`CR-030` P4）。 ⑤ ★ 併同修正真機揭露之契約缺陷：`POST /limit-adjustments` 之實作欄位原為 `targetAmount` 而契約宣告 `amount` → 依契約送件一律 400（`CC-PLT-4002`）；且實作之 `applicantId` 為必填而契約漏列（→ `CC-PLT-4003`）。已一併修正（實作改名 `amount`；契約補 `applicantId`（必填）／`currency`）。★ 揭露工具缺口：`verify_contract_dto` 只核對回應 DTO、不涵蓋請求 DTO → 此類漂移編譯／啟動／單測皆不會錯。 ⑥ 真機驗證 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` 全程未變）。 ⑦ 測試／關卡：`LimitAdjustmentServiceSpecialTest` 15 測 0 失敗；`LayeringTest` 通過；`scan_scaffold`／`scan_mockdata`／`scan_faketest` 各 0 命中；`validate_sql` 0 違規；`verify_contract_dto`（limit-service）0 不符；`validate_mermaid` 117 區塊 0 錯誤。 ⑧ 文件批：`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 網域驗證之聯絡管道 `[email protected]`）。 ⑨ 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
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
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

(65-65/67)

Project

General

Profile

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

CR #201 » GOV-006_任務追蹤清單_WBS.md

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

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

2. 工作包明細

WP1　平台與基礎建設

WP2　領域服務

WP3　WebUI

WP4　橫切關卡

WP5　測試與驗收

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

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

5. 維護規則

6. 修訂記錄

Project

General

Profile

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

CR #201 » GOV-006_任務追蹤清單_WBS.md

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

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

2. 工作包明細

WP1 平台與基礎建設

WP2 領域服務

WP3 WebUI

WP4 橫切關卡

WP5 測試與驗收

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

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

5. 維護規則

6. 修訂記錄

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

WP1　平台與基礎建設

WP2　領域服務

WP3　WebUI

WP4　橫切關卡

WP5　測試與驗收