2 Commits

Include renames

Author	SHA1	Message	Date
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	74b4ca130e	feat(timer): 碼錶移出領取，等工作樹建成之後才起 ... 原本的順序是「放行 → 設 assignee 與標籤 → 起錶 → 處理分支」，而工作樹建立 失敗會中止整個領取——錶已經起了才失敗，使用者會被計一段什麼都沒做的時間， 而工時要準正是工時報表的立足點。 claim 只留領取鎖的兩件事（assignee 與標籤），起錶交給新的 timer.js，由流程 正本排在 branch-prep 之後。timer 已經跑在這顆議題上時什麼都不做：中斷後重跑 是它最常見的處境，重新起錶會把已經累積的時間切成兩段；跑在別顆上則照舊擋下， 不代勞停錶。 三支腳本讀碼錶的那段各留一份，趁這次收進 lib。 議題 #40 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 16:27:43 +08:00