修一個失敗的測試
這是 CoS 最日常的使用場景：CI 紅了，測試失敗，你把「跑測試、看錯誤、改程式、再跑一次」的迴圈交給 ChatGPT。這篇範例完整走一遍，並說清楚 apply_patch 與 exec_command 的幾個關鍵行為。
情境
修一個失敗的測試同一個專案：receipt-cli 的 tests/tax.test.ts 紅了，錯誤是 expected 108, received 100——課稅商品應該加 8% 稅，看起來稅沒被套用。Core 連線正常，寫入與命令執行已開啟。
目標
找出稅沒套用的原因、用最小的修改修好，並用同一個對話把測試跑到全綠。
步驟：給 ChatGPT 的 prompt
The test tests/tax.test.ts is failing with "expected 108, received 100"
for the 8% tax case.
1. Read the failing test and the implementation it exercises.
2. Run just that test file to see the real output.
3. Fix the bug with the smallest possible edit.
4. Re-run that test, then the full suite, and report the exact commands
you ran and their results.
Don't touch anything unrelated to tax calculation.預期的工具呼叫序列
1. read(paths: ["tests/tax.test.ts", "src/tax.ts"])
2. exec_command(cmd: "npm test -- tax")
3. apply_patch(patch: "<V4A 信封：修改 src/tax.ts 的回寫>")
4. exec_command(cmd: "npm test -- tax")
5. exec_command(cmds: ["npm test", "npm run lint"])
→ 一次批次：兩個帶標籤的輸出區段，各自的 exit code第 2 步的輸出會確認問題：applyTax() 算完稅額卻忘了回寫到總計。第 4、5 步先跑單一測試再跑全套，確認沒有波及其他案例。
認識 apply_patch
apply_patch 是 CoS 的文字修改基本工具，行為和一般「工具直接覆寫檔案」不同：
- 使用 V4A patch 信封：修改以 patch 描述，而不是整檔覆寫。
- 多檔 patch 會先預檢再寫入：任何一個檔案對不上目標內容，就不會寫入。
- 建立、編輯、移動、刪除檔案的權限各自獨立檢查。
- 目錄刪除與任意二進位寫入刻意不是 patch 能順手完成的操作。
所以如果 patch 被拒絕，通常是它手上的檔案內容過期了——請它重新 read 再產生一次 patch，而不是叫它「硬改」。
認識 exec_command 的批次
第 5 步一次帶了兩條指令，這值得展開：
exec_command只能二選一：單一cmd，或最多 20 條cmds。- 批次在同一個 shell session 依序執行：變數、環境變更、工作目錄都會延續到下一項。
- 每一項有帶標籤的輸出區段與自己的 exit code；普通非零結果不會中斷後續項目；整個呼叫的 exit code 取第一個非零。
- 批次存在的理由是省連接器回合，不是省時間。
- 單一指令的呼叫才有
apply_patch攔截與「良性非零結束」的分類；批次呼叫不套用這兩項。
驗收方式
- 單檔測試先綠，再全套綠；ChatGPT 回報的指令與你手動重跑一次一致。
git diff只看得到稅金邏輯的改動。
注意事項
- 節奏是「
read讀懂 →exec_command驗證 →apply_patch修改 → 再驗證」，幾乎適用所有小型修復。 - 工具回
TOOL_DISABLED時，先檢查 Read-only 模式與被點名的那個能力；它不代表命令執行被全域關閉。若 ChatGPT 端說它被安全機制擋下：本機權限不等於 provider 同意，沒有工具結果就是執行未確認，不要重放可能已執行的操作。 - 長指令（完整 e2e、大建置）不會一直等下去，會回傳
session_id；改用write_stdin續接，見長指令與開發伺服器。 - Provider 的使用上限與政策決定不可繞：被限制時停掉該工作流，不要換對話、換 worker 或換連接器重試。