2 Commits

Include renames

Author	SHA1	Message	Date
jiantw83andClaude Opus 5	feaf40ab78	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 15:54:27 +08:00
jiantw83andClaude Opus 5	4655a30f47	feat(wp-extract): 建立工作包的抽取契約 ... 實作階段的指令給一個議題編號就拿得到它需要的一切，不必吞下整份議題全文。 輸出與議題 #1 的契約一致：待辦與它自己的驗收是巢狀的，每一項都帶未經修改的 `raw`， 下游靠它只改那一行、不重寫整份 body。 body 說不出的三個活狀態另外現查：相依走 dependencies／blocks 兩個端點並逐頁讀完 （半份清單會讓下游把實作順序排錯，那比直接報錯更難發現）、領取人看 assignee、碼錶 走 /user/stopwatches。碼錶那一項受限於 Gitea 只讓人讀自己的錶，真正的語意是「我的錶 正跑在這顆議題上」，這是議題 #1 已接受的取捨；領取鎖看的仍是 assignee。 同樣只讀 body 不讀留言，但回報未處理留言數。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-17 06:30:23 +00:00