 jiantw83
|
a944141109
|
fix(留言分頁): 改用 timeline 分頁讀取留言
Gitea 議題留言端點無法可靠處理分頁；改由 timeline 逐頁篩選 comment 事件並去重，讓抽取、整併與 PR 留言流程取得完整集合。
|
2026-09-22 14:37:38 +08:00 |
|
|
jiantw83
|
7f723adff8
|
feat: 移除計時並停用報表預覽
|
2026-09-21 17:41:44 +08:00 |
|
 jiantw83andClaude Opus 5
|
03ce382220
|
refactor(issue-body): 工作包的歸屬判準收成一個函式
wp-extract 與 wp-list 都在問「這顆工作包掛在哪顆需求底下」。規則寫兩份，
某天只會有一邊被改到，而分岔的樣子是「清單裡看得到、抽取卻說不是」。
順手把測試裡兩種取段落的寫法統一，並刪掉沒有人傳過的參數。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 18:19:33 +08:00 |
|
|
jiantw83andClaude Opus 5
|
c1ab712afd
|
feat(議題解析): 換掉一個段落的內容，標題與其餘段落一字不動
整併留言裡的決策時用它。不整份重寫的理由跟 upsertLineInSection 一樣，只是代價更大：
重寫會把別人在其他段落的編輯一起蓋掉，而議題的編輯紀錄沒有人會去比對。
三件事照著同檔既有的規矩做：圍欄裡的假標題不算段落；同名標題出現不只一次時交回 ambiguous
而不賭第一個（蓋掉的是一整段，猜錯的代價比 tickLine 更高）；換行沿用 body 原本的那一種，
CRLF 的 body 裡混進 LF 會讓抽取契約交出的 raw 對不上原文，之後就勾不動那幾行。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:19:08 +00: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 |
|
|
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 |
|