Project

General

Profile

Download (6.71 KB)

CR #495 » CR-050_需求評定揭露之契約與追溯對映兩處漂移（待裁定）.md

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

 

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 初版：評定揭露兩處漂移，候選方案待裁
(2-2/2)