principle-sequence-verifiable-units | 每個工作單位都以檢查收尾
本頁以 pstack-claude 0.9.126 為基準。原文設定 user-invocable: false，通常由 poteto-mode 按需讀取。它規範工作與交付順序，不是批次修改指令。
定位與適用情境
適用於掃描式修正、遷移及連續相似編輯。每個單位都從已知狀態開始，做一項變更，執行檢查，再決定是否前進。若所有檔案改完才驗證，失敗原因會埋在整批差異中。
例如購物車、優惠券及退款模組都使用舊金額捨入函式。要修正半分邊界的處理，應先用可重現案例定位差異，再逐模組移轉，避免一次更換後才發現退款金額錯誤。
準備
- 提供三個模組的呼叫端、金額規格與現有測試入口。
- 取得最新乾淨主線的基準結果。原文要求先重定基底（rebase）到乾淨主線；共用或有他人變更的分支須先確認，不直接改寫。
- 指定需求決定的金額案例與預期值，以及每個模組可獨立執行的檢查。不能只用舊函式的輸出當答案。
操作步驟
- 記錄乾淨基準與已知失敗。新增一個精準表達捨入缺陷的測試，確認它因金額差異而失敗，不是匯入錯誤或環境缺失。
- 將最小修正安排在測試之後，確認該案例由失敗轉為通過。把這組前後證據視為一個可說明因果的單位，不把無關重構混入。
- 依序處理購物車、優惠券、退款。每次只移轉一個模組，執行該模組與共用金額檢查。當前單位未通過時，停在該單位定位問題，不繼續堆修改。
- 完成後執行跨模組整合檢查。若任務包含提交或拉取請求（Pull Request），讓審查者能依「缺陷案例、修正、逐項遷移」重播證據；實際提交與合併另依授權及主線政策安排。
可直接使用的提示詞
套用 principle-sequence-verifiable-units，規劃購物車、優惠券、退款的金額函式遷移。
先取得乾淨主線基準與規格中的邊界金額案例。
將工作切成已知起點、單一變更、可執行檢查的單位。
先證明缺陷案例確實失敗，再安排修正，之後逐模組驗證，不通過不前進。
列出交付順序、每單位的檢查及整合驗收。這次只規劃，不 rebase、不提交、不改程式。預期結果與驗收
- 每個單位都能指出起點、唯一主要變更、檢查內容與結果。
- 缺陷測試在修正前因預期金額不符而失敗，修正後通過，形成可重播證據。
- 任一模組檢查失敗時，能直接定位在最近一個單位，不須回溯整批修改。
- 最終紀錄包含跨模組結果。交付順序說明因果，而非依檔案字母順序拆出任意片段。
限制與權限
常見誤用是把一個變更切得極碎，卻沒有任何單位能獨立檢查；或因為使用自動修改工具，就省略逐項驗證。工具便宜地批改，不代表每項結果自然正確。
測試先失敗是受控的證明步驟，不代表應把紅燈版本直接合併到要求全綠的主線。原文的交付順序不取代團隊政策，也不授權 rebase、commit、push 或合併。本頁僅新增教學，沒有實際執行遷移或 Git 操作。