Project

General

Profile

Download (11.6 KB)

CR #234 » CR-033_批次C之C-5其餘8條目逐條結案與幽靈待辦之根因揭露.md

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

 

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 之同步呼叫未實作（真缺口但非事件流，阻塞為會計科目設計，留待外部輸入）。★ 零程式行為變更（僅文件與註解）。
    (1-1/1)