# CR-033　批次 C `C-5` 其餘 8 條目之逐條結案（含「幽靈待辦」之根因揭露）

| 項目 | 內容 |
|---|---|
| 文件編號 | CR-033 |
| 版本 | **1.0** |
| 提出日 | 2026-10-02 |
| 提出者 | WorkBuddy AI（開發團隊） |
| 緣起 | BEAM PMO 2026-10-02：「**請先執行 `C-5` 其餘 8 條目**（鐵律：擬定計劃、規格先行、任務追蹤清單）」 |
| 依據 | `CR-029 §5`／`CR-030 §2 #5`／`§2 #16`／`§4.1`／`§4.2`；`SAD-004 §5.2`；`SDD-003 §13`／`§14`／`§15`；`SCS-008 §10`／`SCS-010 §10`／`SCS-013 §10` |
| 範圍 | `CR-029 §5` 之 **`C-5`**：`#1`／`#3`／`#7`／`#9`／`#13`／`#18`／`#20`／`#21` |
| 結論 | **8 條全數結案；其中「需新增實作」者 0 條** |

---

## 0. 一句話結論

> **`C-5` 之 8 條目是「幽靈待辦」。**
> 它們係依 **`CR-030` 之前**之 `SAD-004 §5.2` 盤點而得；`CR-030 §2 #5` 已將該清單
> **重寫為唯一權威**並**移除／改判**這些消費邊，惟**未回寫 `CR-029`** → `C-5` 仍顯示為待辦。
> **唯一真實待辦（`#3`）已於 `#A-143` 完成。**

> ⚠️ 此為 `MEMORY-RULES` 已記載之型態：**「未查證的『待辦』可能是幽靈」**——本次為又一實例。

---

## 1. 逐條結案總表

| # | 事件 → 消費者 | `CR-030` 後之狀態 | 結案依據 |
|---:|---|---|---|
| **1** | `authorization.approved.v1` → posting | **不做** | `CR-030 §4.1`——`#16`「同步已做」（auth 已**同步呼叫** limit 佔用） |
| **3** | `card.status-changed.v1` → **party** | **✅ 已完成** | `#A-143`（`CR-031 §2`；`SCS-004 §7.5`）——**唯一真實待辦** |
| **7** | `posting.posted.v1` → clearing | **不做** | `CR-030 §4.1`——清算為**批次對帳**，批次讀取為正解 |
| **9** | `posting.reversed.v1` → statement | **不做** | `CR-030 §4.1`——結帳時**同步查詢**即為正解（批次一致性優於事件最終一致） |
| **13** | `statement.issued.v1` → payment | **不做（非事件消費邊）** | 見 §2.1 |
| **18** | `rewards.points.redeemed.v1` → posting | **不做（非事件消費邊）** | 見 §2.2 |
| **20** | `clearing.batch.matched.v1` → posting | **不做（非事件消費邊）** | 見 §2.3 |
| **21** | `dispute.case.opened.v1` → posting | **不做（非事件消費邊）** | 見 §2.4 |

**→ `C-5` 結案：實作 1 條（已完成）、裁定不做 7 條、**待實作 0 條**。**

---

## 2. 逐條理由（`#13`／`#18`／`#20`／`#21`）

> 四條皆**逐條查證**（規格文件 ＋ 程式碼），結果一致：**「事件消費後做什麼」在任何文件中都沒有定義**。

### 2.1 `#13`　`statement.statement.issued.v1` → `payment`

| 查證 | 結果 |
|---|---|
| `SAD-004 §5.2`（**唯一權威**） | 消費者僅 **`notification`**——**payment 不在列** |
| `SCS-011 §7.2` | 自載「**payment 之消費端尚未實作，屬 `CR-029 §4 #13` 待裁定**」 |
| `SCS-008 §10` | 自載「**自扣執行流程尚未實作**」 |
| 程式 | `payment-service` **無** statement 事件之 Listener |

**裁定：不做。** 理由：
**(i)** 權威清單未列其為消費者；
**(ii)** 「出帳後觸發自扣」屬**未實作功能**（`SCS-008 §10`），**非事件消費缺口**；
**(iii)** 自扣之**執行**是一筆真實付款（**寫入**）——依 **P2**，**命令不得走事件**，須走 API。

### 2.2 `#18`　`rewards.points.redeemed.v1` → `posting`

| 查證 | 結果 |
|---|---|
| `SAD-004 §5.2` | 消費者僅 `notification`——**posting 不在列** |
| `SDD-003 §13` | 載 `Rewards->>Posting: 產生點數帳務（點數帳／商店帳／發卡帳）`——**同步呼叫**，且**在寫事件之前** |
| 程式 | `rewards-service` **無** posting client（僅一行 TODO 註解） |

**裁定：不做。** 理由：**`CR-030 §2 #16`**——事件**不得重做同步已做之寫入**（否則重複分錄）。

### 2.3 `#20`　`clearing.batch.matched.v1` → `posting`

| 查證 | 結果 |
|---|---|
| `SAD-004 §5.2` | 消費者欄為「**—**」，並明載「**不做消費端**（清算為批次對帳，`CR-030 §4.1`）」 |
| `SCS-013 §10` | 自載「**結算不觸發 `posting-service` 入帳**——入帳串接未實作（**需 `posting` 側之應收／應付科目設計**）」 |
| `SDD-003 §14` | `Clearing->>Posting: 產生會計分錄`——**同步**，且在寫事件之前 |

**裁定：不做。** ★ 併指出：該缺口之**真正阻塞是會計科目設計**（**業務／會計輸入**），
**不是事件流**——屬 `CR-030 §4.2`「留待外部輸入」之類。

### 2.4 `#21`　`dispute.case.opened.v1` → `posting`

| 查證 | 結果 |
|---|---|
| `SAD-004 §5.2` | 消費者僅 `notification`——**posting 不在列** |
| `SDD-003 §15` | 「Dispute→Posting：帳務調整（暫付或扣回）」屬**結案**（`case.closed`）路徑，且為**同步** |
| `SCS-012 §10` | 已揭露「**無結案端點**」等限制；**未**載「受理即需 posting 動作」 |

**裁定：不做。** 理由：**(i)** 權威清單未列；**(ii)** 帳務調整屬**結案**路徑（非受理）；
**(iii)** 若日後要「**受理即暫停計息**」，屬**新功能**，需**業務定義**。

---

## 3. ★ 查證揭露（本次之三項副產物）

### 3.1 ★★ 根因：**清單重寫後未回寫盤點** → 幽靈待辦

`CR-030 §2 #5` 裁定 `SAD-004 §5.2` 為**唯一權威**並**重寫**該清單，**但未回寫 `CR-029`**。

**證據**（`git show 9937bd0:cardcore/docs/02-sad/SAD-004_整合架構與API治理.md`，即 `CR-030` 之前）：

| 事件 | `CR-030` **前**之消費者 | `CR-030` **後**（現行） |
|---|---|---|
| `authorization.authorization.approved.v1` | **posting**, limit, notification | notification |
| `posting.transaction.posted.v1` | statement, rewards, **clearing**, limit | rewards |
| `posting.transaction.reversed.v1` | **statement**, rewards | rewards |
| `payment.payment.posted.v1` | limit, **posting**, notification | notification |
| `statement.statement.issued.v1` | **payment**, notification | notification |
| `rewards.points.redeemed.v1` | **posting**, notification | notification |
| `clearing.batch.matched.v1` | **posting** | —（**不做消費端**） |
| `dispute.case.opened.v1` | **posting**, notification | notification |

→ **`C-5` 之 8 條目，逐條對應上表之「粗體消費者」**——皆已於 `CR-030` 被移除或改判。
→ **教訓（已寫入 `MEMORY-RULES`）**：**重寫權威清單後，必須回寫「以舊清單為基礎之盤點」**，
否則產生**幽靈待辦**，後續批次將花工在不存在的工作上。

### 3.2 程式註解與規格**不一致**（**共 8 處**）

以 `grep -rn '消費者：'` 掃全庫程式註解，逐一比對現行 `SAD-004 §5.2`——**8 處與規格矛盾**：

| # | 檔案 | 原註解 | 問題 |
|---:|---|---|---|
| 1 | `rewards` `RedemptionService:173` | 消費者：**posting**／notification | 現行 `§5.2` 未列 posting |
| 2 | `dispute` `DisputeService:89` | 消費者：**posting**／notification | 同上 |
| 3 | `clearing` `ClearingRunService:136` | 消費者：**posting** | 同上（且 `§5.2` 已標「不做消費端」） |
| 4 | `merchant` `MerchantSettlementService:89` | 消費者：**clearing** | 現行 `§5.2` 消費者欄為「**—**」 |
| 5 | `payment` `PaymentService:79` | 消費者：limit、**posting**、notification | `posting` 已非消費者（同步已做） |
| 6 | `posting` `PostingService:103` | 消費者：**statement／rewards／limit／pricing** | 現行僅 **`rewards`** |
| 7 | `product` `ParameterService:134` | 消費者：**全體服務** | `CR-031 §3.1` 已更正為「**可呼叫 `product` 之 9 服務**」（ACL 所限） |
| 8 | `limit` `LimitApplicationService:95` | 「**`CR-027 §5 #2` 待裁定**」 | 該項**已由 `CR-028` 化解** → 註記過期 |

→ **8 處全數修正**（程式註解不得與規格矛盾——否則下一個人又會被誤導，且**幽靈待辦**正是這樣產生的）。

> ⚠️ **僅 1 處為「正確且有價值」之註解**：`notification` `NotificationService:232` 主動記載
> 「消費者：party（`SAD-002 §3.15`）——尚未實作；**且 `SAD-004 §5.2` 未列本事件**」
> ——**主動指出兩份清單不一致**，正是應該的寫法。**保留不動。**

### 3.3 ★ `SDD-003 §13／§14／§15` 之**同步呼叫未實作**（**真缺口，但非事件流**）

`SDD-003` 載明 Rewards／Clearing／Dispute → Posting 之**同步**呼叫（產生分錄），
惟**實作僅有 TODO 註解**（見 §3.2 三處）。

| 序列圖 | 所載同步呼叫 | 實作 |
|---|---|---|
| `SDD-003 §13` | `Rewards → Posting`：產生點數帳務（點數帳／商店帳／發卡帳） | ❌ 無 |
| `SDD-003 §14` | `Clearing → Posting`：產生會計分錄 | ❌ 無（`SCS-013 §10` 已自載） |
| `SDD-003 §15` | `Dispute → Posting`：帳務調整（暫付／扣回） | ❌ 無 |

**裁定：登記為「同步整合缺口」，不屬 `C-5`，本 CR 不實作。** 理由：
**(i)** 分錄之**科目與借貸方向未定義**（`SCS-013 §10` 明言「需 `posting` 側之應收／應付科目設計」）
→ 實作即**臆造會計**；
**(ii)** `clearing → posting` **不在 `posting-service` 之 ACL**（`cardcore-service-acl.yml`），需一併改 `SAD-002 §5`；
**(iii)** 屬**功能缺口**（新整合），須另立 CR 並取得**會計科目輸入**後方可動工。

---

## 4. 執行（本 CR 之文件與程式修正）

| 項 | 內容 |
|---|---|
| `CR-029 §5` | `C-5` 標記 **結案**（含 8 條逐條狀態） |
| `SAD-002 §3.9～3.17` | 「主要相依」欄加註——該欄為**同步**相依，**非事件訂閱**（避免再次被誤讀為消費邊） |
| `SAD-002 §3.6`／`§3.7` | 「事件（訂閱）」欄加註「**非權威**；`posting`／`payment` 已非消費者（`CR-030`／`CR-033`）」 |
| `SCS-010 §7.1`／`§10` | 更新「尚未實作」→「**已裁定：非事件消費邊**（`CR-033`）」 |
| `SCS-011 §7.2` | 同上（並註明「自扣屬**未實作功能**，`SCS-008 §10`」） |
| `SCS-012 §7`／`§10` | 同上（並註明「帳務調整屬**結案**路徑」） |
| `SCS-013 §7`／`§10` | 同上（並註明「入帳串接之阻塞為**會計科目設計**」） |
| `SAD-004 §5.2` | 加註「`C-5` 已結案（`CR-033`）」 |
| 程式 | **8 處** stale 註解修正（§3.2；`rewards`／`dispute`／`clearing`／`merchant`／`payment`／`posting`／`product`／`limit`）——**純註解，零行為變更** |

---

## 5. 明確不做／留待外部輸入（延續 `CR-030 §4`）

| 事項 | 性質 |
|---|---|
| `SDD-003 §13／§14／§15` 之同步呼叫（→ posting 分錄） | **留待外部輸入**：**會計科目與借貸方向**（業務／會計） |
| 「出帳後觸發自扣」 | **新功能**（`SCS-008 §10` 已載未實作），非事件流 |
| 「爭議受理即暫停計息」 | **新功能**，需業務定義 |

---

## 6. 修訂記錄

| 版本 | 日期 | 說明 |
|---|---|---|
| 1.0 | 2026-10-02 | 初版：依 BEAM PMO 指示逐條執行 `C-5` 其餘 8 條目。★ **結論：8 條全數結案、「需新增實作」0 條**——其中 1 條已完成（`#A-143`）、7 條裁定不做。★★ **揭露根因**：`C-5` 為**幽靈待辦**（`CR-030 §2 #5` 重寫 `SAD-004 §5.2` 後**未回寫 `CR-029`**；已以 `git show` 取 `CR-030` 前之清單為證）。★ 併揭露 **8 處程式註解與規格不一致**（已修；`grep -rn '消費者：'` 全庫掃描而得——遠多於初判之 3 處）與 **`SDD-003 §13/§14/§15` 之同步呼叫未實作**（**真缺口但非事件流**，阻塞為**會計科目設計**，留待外部輸入）。★ **零程式行為變更**（僅文件與註解）。 |