  jiantw83andClaude Opus 5
|
0154cf59d4
|
fix(claim): 被碼錶擋下時明說停錶不會動到既有的工作樹
議題 #38 的使用者故事第 30 條：使用者常以為停錶等於放棄那顆工作包，於是寧可
不停——工時就記到別顆議題去了。碼錶只管時間、工作樹只管檔案，兩者互不相干，
這件事要在擋下來的當下就講，不能指望使用者自己推論。
領取與起錶會撞到同一個擋路理由，訊息收進 lib 只寫一份。順手收掉 review 指出的
三處：planWorktree 沒用到的 repo 參數、與 path.resolve 同名而誤導的區域函式、
以及只有 lib 自己用得到卻對外 export 的兩支路徑函式。
回滾補上最後一道：git 清不掉時把目錄本身也刪掉。那條路徑在這次執行之前不存在
（不存在正是建立的前提），裡面不可能有使用者的東西，而留著它下一次重跑會直接
撞上 WORKTREE_PATH_TAKEN——一次失敗的建立不該讓人從此開不了工。
議題 #40
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 16:29:12 +08:00 |
|
|
jiantw83andClaude Opus 5
|
4ae097f1e1
|
fix(腳本契約): 長輸出不再被截斷，查重翻頁加上上限
process.stdout.write 之後立刻 process.exit 會截斷輸出——stdout 接到 pipe 時
寫入是非同步的。改為等 write 的 callback 回來再退出。實測舊寫法在約 83KB 處
被切斷，新增的回歸測試以 8000 筆標籤覆蓋這條路徑。
findIssueByTitle 的翻頁原本沒有上限，Gitea 若持續回滿一頁就會無限打下去。
加上 200 頁上限，超過即以 DEDUPE_LIMIT 報錯而非無聲回 null——無聲回 null 會
讓呼叫端把既有議題再建一次，正好是冪等查重要防的事。
parseFlags 取值時不再於三元運算式內遞增迴圈變數，改為獨立敘述。
測試工具的 maxBuffer 調高到 64MB：預設 1MB 會在長輸出時砍掉子行程，那是測試
工具的限制而非腳本的問題。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 04:26:51 +00:00 |
|
|
jiantw83andClaude Opus 5
|
28dec83498
|
test(腳本契約): 以子行程與 stub server 驗證契約與四層前置檢查
測試一律以子行程執行腳本、比對 stdout 的單行 JSON 與 exit code，因為那正是
七個平台共用的實際呼叫方式，不會因內部重構而破碎。
Gitea 以本機 stub server 替身並錄下每一筆請求，藉此斷言「腳本到底發了哪些
請求」——包含 --dry-run 不得發出任何請求、前一層檢查沒過就不再往下打、
寫入權探針不得挾帶任何要寫入的欄位。git 則在 .tmp/ 下的臨時 repo 跑真實
指令，比 mock 可信且成本低。
lib-exports.test.js 是唯一直接 import lib 的例外：冪等查重與 git 執行點在
CLI 邊界上還沒有消費者，檔頭已註明等 #4 與 #10 落地後即可縮小或移除。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 04:26:51 +00:00 |
|