# GOV-005　To-Be Scope 與交付範疇

| 項目 | 內容 |
|---|---|
| 文件編號 | GOV-005 |
| 版本 | 1.1 |
| 狀態 | 已核定 |
| 撰寫者 | SA / Tech Lead |
| 審查者 | BA / PM |
| 對應需求 | 客戶 RFP 之 FR 68 項、NFR 874 項（60 小節）、POC 17 項 |
| 關聯文件 | `BRD-001`～`BRD-004`、`GOV-004`、`SCS-000` |

---

## 0. 為何需要本文件（問題陳述）

2026-09-19 BEAM PMO 指出：**現有文件只有架構層級（Conceptual Design），
沒有服務／程式層級的 Coding Spec，等於邊做邊想，追溯性會斷裂。**

經盤點確認，缺口不在「需求端」也不在「程式端」，而在**中間的設計規格層**：

| 層級 | 文件 | 狀態 |
|---|---|---|
| 需求 | `BRD-002`（FR 68）、`BRD-003`（NFR 60 小節）、`BRD-004`（POC 17） | ✅ 完整 |
| 追溯模型 | `GOV-004`（服務×FR、POC×服務） | ✅ 完整 |
| 架構設計 | `SAD-001`～`006`、`SDD-000`～`007` | ✅ 完整 |
| **服務程式設計規格** | **`SCS`（Service Coding Spec）** | **❌ 完全空白** |
| 程式碼 | `backend/services/*` | ✅ 部分（3 服務） |
| 測試 | `TRP-001`、`TRR-001` | ✅ 部分 |

**結論：BEAM PMO 的批評成立。** 本文件據此調整交付方法。

---

## 1. 什麼是 To-Be Scope

**To-Be Scope ＝ 我方對客戶 Proposal（RFP）之正式回覆內容**，也就是「我們承諾要建置的系統樣貌」。

它不是願景，而是**可追溯、可驗收的承諾清單**，包含兩大部分：

| 部分 | 內容 | 來源 |
|---|---|---|
| **功能性（Functional）** | 系統應提供的業務能力（發卡、授權、入帳、帳單、分期、點數、爭議、清算、報表…） | 客戶 FR 68 項，我方於建議書逐項回覆 |
| **非功能性（Non-Functional）** | 效能、容量、可用性、資安、個資、維運、監控、備援、批次時效… | 客戶 NFR 874 項（60 小節），我方於建議書附錄 B 逐項回應 |

> ⚠️ **To-Be Scope 的邊界由「我方回覆」界定，不是由客戶 RFP 全文界定。**
> 客戶要求若我方回覆為「部分符合」或「替代方案」，則以我方回覆之範圍為準，
> 並於 `BRD-002`/`BRD-003` 註記差異，避免驗收時被以 RFP 全文究責。

---

## 2. 追溯模型（五層，補足缺口）

任一需求必須能回答**五問**；缺任一問視為追溯斷裂：

| # | 問題 | 回答文件 | 狀態 |
|---:|---|---|---|
| 1 | 客戶要求什麼？ | `BRD-002`/`BRD-003`（對應建議書章節） | ✅ |
| 2 | 由哪個服務承作？ | `GOV-004 §3`、`SAD-002` | ✅ |
| 3 | **這支程式如何設計？** | **`SCS-00x`（本文件新增）** | **❌→施工中** |
| 4 | 由哪支程式／類別實作？ | `SCS-00x §「程式結構」` + `backend/` | ⚠️ 待 SCS 補齊 |
| 5 | 如何驗證？ | `TRP-001`（計畫）、`TRR-001`（結果） | ✅ 部分 |

```mermaid
flowchart LR
  RFP["客戶 RFP<br/>FR 68 / NFR 874"] --> PROP["我方建議書<br/>proposal_v2（To-Be Scope 源頭）"]
  PROP --> BRD["BRD-002/003<br/>需求追蹤"]
  BRD --> SAD["SAD/SDD<br/>架構設計"]
  SAD --> SCS["SCS-00x<br/>服務程式設計規格"]
  SCS --> CODE["backend/services<br/>程式碼"]
  CODE --> TRR["TRR-001<br/>測試結果"]
  BRD --> GOV4["GOV-004<br/>追溯矩陣"]
```

---

## 3. To-Be Scope 清單（功能性）

> ### ⛔ 本節之「狀態」欄已於 2026-09-19 **廢止**
>
> 本節建立於 2026-09-19 11:58，其狀態欄（🟢／🟡／⚪）**自建立後即未再更新，已全面過時**
> （例如仍記載 `party-service`「未開發」，實則當日 14:27 已完成）。
>
> **任務與進度之追蹤，一律以 `cardcore/HANDOVER.md` 之
> 「`§📊 任務追蹤總表（Task Tracker）`」為單一真實來源。**
>
> 本節**僅保留「服務 × FR 承作關係」**作為範疇界定之用；**狀態請勿引用本節**。
> 保留而非刪除之原因：本節記錄了 11:58 當下的認知，是「文件分層調整」之歷史證據。

依 `GOV-004 §3` 之服務×FR 對照，並標註**目前實作狀態**（2026-09-19 **11:58 快照，已過時**）：

| 服務 | 承作 FR | 狀態 | SCS |
|---|---|---|---|
| `authorization-service` | AUT-1.1、AUT-1.2、AUT-1.3 | 🟡 部分（授權主線完成，13 項檢核僅 6 項） | `SCS-001` |
| `card-service` | ISS-2.2、DEB-3.1 | 🟡 部分（狀態查詢、生命週期轉換完成；發卡／快發快綁未做） | `SCS-003` |
| `limit-service` | ISS-2.4 | 🟢 大部分（佔用／釋放／調整申請完成） | `SCS-002` |
| `party-service` | ISS-2.1 | ⚪ 未開發 | 待編 |
| `product-service` | COM-6.1、COM-6.2 | ⚪ 未開發 | 待編 |
| `posting-service` | ACQ-4.5、ISS-2.3、ISS-2.12、DEB-3.2、DEB-3.5 | ⚪ 未開發 | 待編 |
| `payment-service` | ISS-2.6、ISS-2.9 | ⚪ 未開發 | 待編 |
| `statement-service` | ISS-2.8 | ⚪ 未開發 | 待編 |
| `pricing-service` | ISS-2.5、DEB-3.3 | ⚪ 未開發 | 待編 |
| `installment-service` | ISS-2.7 | ⚪ 未開發 | 待編 |
| `rewards-service` | RWD-5.1～5.3 | ⚪ 未開發 | 待編 |
| `notification-service` | ISS-2.10 | ⚪ 未開發 | 待編 |
| `report-service` | SYS-1、ACQ-4.4、ISS-2.11、DEB-3.4 | ⚪ 未開發 | 待編 |
| `migration-service` | SYS-2.8、SYS-3 | ⚪ 未開發 | 待編 |
| `clearing-service` | ACQ-4.6、ISS-2.13、DEB-3.6 | ⚪ 未開發 | 待編 |
| `dispute-service` | （見 GOV-004） | ⚪ 未開發 | 待編 |
| `merchant-service` | ACQ-4.1～4.3 | ⚪ 未開發 | 待編 |
| `platform/common` | SYS-2.1～2.6、2.9～2.12、SYS-5、SYS-6、SYS-9.14～9.15 | 🟡 部分（值物件、例外、事件、批次、Saga 完成） | 待編 |
| `platform/gateway` | SYS-4、SYS-7、SYS-8 | ⚪ 未開發（骨架） | 待編 |
| `cardcore-web` | 授權作業台、額度調整申請 | 🟡 部分（2 頁） | `SDD-007` |

**圖例**：🟢 大部分完成｜🟡 部分完成｜⚪ 未開發

---

## 4. To-Be Scope（非功能性）

NFR 以**小節層級**（60 小節）追蹤，歸屬與驗證方式詳見 `BRD-003`。
與程式直接相關者，須於 `SCS` 中說明「如何滿足」：

| NFR 主題 | 涉及設計 | 驗證方式 | 狀態 |
|---|---|---|---|
| 交易一致性 | `SDD-004`（Saga／Outbox） | `TRR-001` 閉環測試 | 🟡 部分（Saga 引擎完成，未上線驗證） |
| 個資保護 | `SAD-005`（遮蔽／加密） | 單元測試 + 資料抽檢 | 🟢 已完成（`common-security`） |
| 可觀測性 | `CSP-004` | 日誌／追蹤碼 | 🟡 部分（追蹤碼完成，監控未接） |
| 錯誤處理 | `CSP-003`（錯誤碼） | 契約測試 | 🟢 已完成 |
| 批次時效 | `common-batch` | 批次測試 | 🟡 部分（框架完成，排程僅臨時額度到期） |
| 效能／容量 | 未設計 | 待壓測 | ⚪ 未處理 |

---

## 5. 新的開發節奏（據此調整，不再邊做邊想）

自 2026-09-19 起，任何服務／功能開發**必須依序產出**：

```
① 確認需求（BRD-002/003 之 FR/NFR 編號）
② 撰寫/更新 SCS-00x（服務程式設計規格）  ← 新増，必備
③ 依 SCS 實作程式
④ 撰寫/更新測試（TRP-001）
⑤ 執行測試並更新 TRR-001
⑥ 更新追溯矩陣（GOV-004）
```

**無 SCS 不寫程式**——這是 Coding Gate 的一環（納入 `GOV-003`）。

---

## 6. SCS（Service Coding Spec）文件規範

`SCS-00x` 為**服務／程式層級**設計規格，命名 `SCS-<NNN>_<服務名>服務程式設計規格.md`，
存放 `docs/07-scs/`（新增目錄）。

**必備章節**：

| § | 章節 | 內容 |
|---:|---|---|
| 1 | 對應需求 | FR/NFR 編號、建議書章節 |
| 2 | 服務職責與邊界 | 承作什麼、不做什麼（bounded context） |
| 3 | 領域模型 | 聚合、值物件、狀態機（含轉換表） |
| 4 | 程式結構 | 套件／類別清單與職責（對應實際檔案） |
| 5 | 資料模型 | 表、欄位、約束（實測值） |
| 6 | API 設計 | 端點、請求／回應、錯誤碼 |
| 7 | 關鍵邏輯 | 演算法、檢核順序、交易邊界 |
| 8 | 外部依賴與降級 | 呼叫誰、失敗怎麼辦（Stand-in） |
| 9 | 測試案例 | 對應 TRP-001 之編號 |
| 10 | 已知限制 | 誠實揭露未實作範圍 |

---

## 7. 已完成 vs 待補（追溯補正計畫）

> **本節已於 2026-09-19 更新完畢**——原表所列「待編」項目**皆已完成**。

| 項 | 說明 | 狀態 |
|---|---|---|
| 盤點缺口 | 確認缺 SCS 層 | ✅ 完成 |
| 定義 To-Be Scope | 本文件 | ✅ 完成 |
| `SCS-000`（總覽與模板） | 定義 SCS 寫法 | ✅ **已完成** |
| `SCS-001`～`003` | 已開發服務補規格（授權／額度／卡片） | ✅ **已完成**（程式先行、規格後補，已標示） |
| `SCS-004`～`021` | 其餘領域與跨域服務 | ✅ **已完成**（**22 份全數開齊**，2026-09-19 11:59–19:37） |
| `GOV-003` 納入 SCS 為 Coding Gate | 流程調整 | ✅ **已完成**（條件 9「**無 SCS 不寫程式**」） |
| `GOV-004` 加入程式檔案層追溯 | 追溯補正 | ✅ **已完成**（追加程式層說明） |

**後續追蹤**：範疇之**執行進度**請見 `cardcore/HANDOVER.md` →「`§📊 任務追蹤總表`」。
本文件自此**只管範疇界定與追溯模型**，不再承載進度資訊。

---

## 8. 修訂記錄

| 版本 | 說明 |
|---|---|
| 1.0 | 初版：依 BEAM PMO 2026-09-19 之指摘，盤點追溯斷裂並調整開發方法 |
| 1.1 | 2026-09-19：①**§3 狀態欄廢止**——該欄自 11:58 建立後未再更新、已全面過時，進度追蹤改由 `HANDOVER.md`「任務追蹤總表」承擔（避免兩處各說各話）；②**§7 更新**——原「待編」項目皆已完成（SCS 22 份全數開齊、Coding Gate 已納入、GOV-004 已補程式層）；③檔頭狀態由「草案」改為「已核定」 |