# CR-050　需求評定揭露之「契約 ↔ 追溯對映」兩處漂移（已裁定並執行）

| 項目 | 內容 |
|---|---|
| 文件編號 | CR-050 |
| 版本 | **1.2** |
| 狀態 | **已裁定並執行＋後續開立 CR-051／CR-052**（2026-10-17） |
| 觸發 | `#A-273` 需求落地狀態評定（`ops/redmine/req_assess.py`，145 筆逐項以「服務＋契約路徑＋測試」可證偽評定） |
| 需求依據 | `GOV-004 §5`（追溯矩陣）、`BRD-002`（FR 追蹤）、`SDD-006`（契約）、RFP `FR.md §2.4／§4.3`（原文證據） |
| 影響模組 | 文件（`BRD-002 v1.1`／`GOV-004 v1.2`，經 `gen_traceability.py`）＋評定器（`req_assess.py` GAPS 機制）——**契約與程式零變更** |

---

## 1. 問題陳述

以**可證偽**方式評定 145 筆需求之落地狀態時，揭露 2 筆 FR 之「追溯對映所載 API」
與「契約實際路徑」不一致：

| FR | 追溯對映所載 API | 服務 | 契約實際 |
|---|---|---|---|
| `ACQ-4.3` | `GET /api/v1/merchant-statements` | `merchant-service` | 僅有 `/api/v1/merchants`、`/api/v1/merchants/{merchantId}`、`/api/v1/merchant-settlements` |
| `ISS-2.4` | `GET /api/v1/cards/{id}/limits` | `limit-service` | 帳戶層級 `/api/v1/accounts/{accountId}/limits`、`/special-limits`、`/special-limit-policies`…；**無卡片級**路徑 |

## 2. 裁定結果（2026-10-17）

### 2.1 `ACQ-4.3`——**拒絕方案 A 之「改對映 merchant-settlements」**；採「對映誠實化＋缺口揭露」

**證據（RFP `FR.md` 原文）**：

* `ACQ-4.2`＝**§4.2 商店請款**（EDC／非 EDC 請款處理、商店多批請款）→ 契約 `POST /api/v1/merchant-settlements`（「商店請款」）**語意吻合**。
* `ACQ-4.3`＝**§4.3 商店對帳單**——需求描述：①列印週期（每日／兩日／月結）②種類（全額發票／全收據(自然人)）③郵寄方式（掛號／限時／平信）④**補印** ⑤**電子發票**。

**裁定**：`merchant-settlements`（請款）≠ `merchant-statements`（對帳單）——兩者為**不同業務域**。
若改對映，等於把「請款」謊報為「對帳單」，正是本專案最忌之「**有 API、沒有需求語意**」型假綠；
且對帳單含列印／發票／郵寄／電子發票完整業務域，**不是單一 GET 端點可承載**，貿然補端點（方案 B）
違反「規格先行」鐵則。

**→ 處置**：追溯對映**誠實化**——`ACQ-4.3` 之「主要 API」欄改記 `—（未涵蓋：商店對帳單待另立 CR，CR-050）`、
驗收測試欄改 `—`（原 `UT-ACQ-003` 為虛構，測試檔實際不存在）；
需求狀態＝**In Progress（真實缺口）**，待 SA/SD 語意凍結後另立 CR。

### 2.2 `ISS-2.4`——對映改指向**實際已交付**之帳戶級端點；卡片級維持缺口

**證據**：

* 原對映 `GET /api/v1/cards/{id}/limits` 為 `CR-043` 已清除之 **stale 路徑**（`CR-043 §10.5` 判例：**禁止恢復**）。
* 帳戶級端點 `GET /api/v1/accounts/{accountId}/limits` **契約＋limit-service 實作＋測試三重證據齊備**。

**→ 處置**：對映改為 `GET /api/v1/accounts/{accountId}/limits`（如實反映已交付部分）；
「卡片級」調額／查詢之缺口以 `GAPS` 機制揭露——**即使三重證據齊備仍記 In Progress**，
待額度多維度與共享池分攤語意凍結後另立 CR（`GOV-006 2.4.4` 追蹤）。

## 3. 執行紀錄（2026-10-17）

| # | 動作 | 結果 |
|---|---|---|
| 1 | `tools/gen_traceability.py`：M 兩列誠實化＋新增 **`GAPS`** 缺口登錄（單一真實來源）；BRD-002 §3 表下印缺口註記；GOV-004 §7 評定節／§8 修訂記錄 | ✅ |
| 2 | ★ GOV-004 原**手工加註**之內容（§3 `dispute-service` 列與註記、§6 檢核列、修訂記錄、評定節）**全部移植入產生器**——重跑不再遺失（產生器紀律：文件為單一真實來源） | ✅ |
| 3 | 重生 `BRD-002 v1.1`／`GOV-004 v1.2`（FR=68 斷言通過；diff 驗證手工內容零遺失） | ✅ |
| 4 | `ops/redmine/req_assess.py`：`assess_fr` 增 **GAPS 優先**——已揭露缺口即使三重證據齊備亦記 In Progress（反假綠） | ✅ |
| 5 | 重跑評定並 `--apply`：**145 筆判定依據 note 已更新**；分佈 **Closed 51／In Progress 79／Feedback 15**（不變——修正的是**理由**，不是狀態） | ✅ |
| 6 | 關卡：`verify_contract_dto.py` **不符 0／需確認 0**（契約與程式零變更，符合預期） | ✅ |
| 7 | Redmine 議題 320（`FR-ACQ-4.3`）／327（`FR-ISS-2.4`）note 實查確認已帶新判定依據 | ✅ |

## 4. ★ 執行中之新發現（已裁定——BEAM PMO 2026-10-17 核准）

**RFP `FR.md §2.4`（信用卡額度管理）第 1 點原文為「歸戶、持卡人、卡片調額／查詢」**——
即「卡片級查詢」**白紙黑字列於 RFP**。此前 `CR-045`／`GOV-006 2.4.4` 將卡片級可用額度查詢
定性為「**預期需求（未列 RFP）**」，與 RFP 原文**不符**。

**BEAM PMO 裁定與執行（2026-10-17）**：

1. ✅ **定性更正**：`GOV-006 2.4.4` → **1.77** 更正為「**RFP 已列需求：卡片級額度調額／查詢**
   （RFP `FR.md §2.4(1)` 明列；語意待凍結 `CR-052`）」。
2. ✅ **開立 `CR-051`**：商店對帳單（RFP FR §4.3）語意凍結清單 **S-1～S-7**（含 RFP §4.4
   「衛星系統供料」邊界線索）。
3. ✅ **開立 `CR-052`**：卡片級額度調額與查詢語意凍結清單 **C-1～C-6**（含 ACL 實查：
   `card-service` 僅允許 authorization、`limit-service` 允許清單不含 card/party——同步直呼
   路徑不存在，投影為既有先例）。
4. 兩 CR 均為**規格先行、不動程式、不補端點**；`GAPS` 已改指向 CR-051／CR-052。

## 5. 驗收

1. ✅ 裁定後重跑 `python3 ops/redmine/req_assess.py --apply` → 145 筆 note 更新、狀態由事實推導（不變：51/79/15）；
2. ✅ `verify_contract_dto.py` 0 不符（契約未動）；
3. 兩筆缺口之**閉合**各自待：`ACQ-4.3` 另立 CR（SA/SD 語意凍結後）、`ISS-2.4` 卡片級另立 CR（`GOV-006 2.4.4` 依賴閉合後）。

## 6. 修訂紀錄

| 版本 | 日期 | 內容 |
|---|---|---|
| **1.2** | 2026-10-17 | **BEAM PMO 裁定**：§4 定性更正核准（`GOV-006 2.4.4 → 1.77`：RFP 已列、語意待凍結）；兩筆缺口**開立 `CR-051`**（商店對帳單 S-1～S-7）／**`CR-052`**（卡片級 C-1～C-6）；`GAPS` 改指向新 CR |
| 1.1 | 2026-10-17 | **裁定並執行**：`ACQ-4.3` 對映誠實化（拒絕混用請款語意）、`ISS-2.4` 改對映帳戶級端點＋`GAPS` 缺口機制；GOV-004 手工內容移植入產生器；145 筆 Redmine note 更新；揭露「卡片級查詢實為 RFP 已列」（§4，待覆核） |
| 1.0 | 2026-10-17 | 初版：評定揭露兩處漂移，候選方案待裁 |