  jiantw83andClaude Opus 5
|
46c6db8c70
|
feat(time-log): 對既有議題重跑時補到當下，每一輪各記一筆
原本的終點一律是議題的建立時間，所以對既有議題重跑時相減為負，補登直接 no-op——
那一輪的規劃時間就這樣掉了，而那正是這顆議題要修的毛病，只是換個位置出現。
終點改成看議題是不是這一輪建立的：是就補到議題建立那一刻（第一次跑），不是就補到
補登的當下（重跑）。回報多出 `迄` 與 `依據` 兩個欄位，讓人一眼看出這一筆補的是哪一段。
「這顆議題上已經有工時就跳過」這條規則拿掉了，它與累計互斥。防重複只剩一條：錶已經
跑在這顆議題上——那一段已經有錶在記，補下去會與錶涵蓋的區間重疊。連帶把 lib 的
listIssueTimes 一起移除，沒有人再用它。
實跑驗過（議題 #57）：補登 121 秒、起錶、停錶 7 秒，兩筆都進得了週報，驗完刪除。
議題 #57 的規格同步更正，另外兩處過期的敘述也一併改掉。
議題 #57
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-18 08:46:27 +08:00 |
|
|
jiantw83andClaude Opus 5
|
7ee050de2f
|
docs(sdlc-plan,sdlc-analyze): 兩份正本各自起停自己的錶
起錶與停錶寫在同一份正本裡成對出現，讀的人一眼看得出這段計時涵蓋到哪；兩份各加一節
「計時範圍」把兩端指出來。
sdlc-plan 記兩段：議題建立之前那段在第一步記下開始時間、議題建立之後以補登記上去；
之後起錶，回報那一步停錶。補登排在議題建立之後、起錶之前，順序反過來的話補登會被
time-log 當成「這一步做過了」而跳過。
sdlc-analyze 在它分析的那顆需求議題上起錶，起點放在第一段開頭——分析最耗時的正是
共識之前那一段，從第二段才起的話那段時間永遠是零。因此「共識摘要之前不對 Gitea
產生任何寫入」改寫成「不寫入任何**內容**」，並把碼錶明文除外、寫上理由：它記的是
工時，不是內容。這一條與 repo 擁有者確認過。
sdlc-feat 的「碼錶一律由使用者自己停」收斂成「**別顆議題上的**錶一律由使用者自己停」
——它原本讀起來像全域規則，而現在每道指令都會停自己起的那一支。
正本之間改以步驟**名稱**互指，不用編號：編號會整批位移，名字不會。測試跟著改用新的
promptStep 輔助函式，以名字框出某一步的內容，別人插一步時不會無聲地框到另一段上。
議題 #57
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 19:32:37 +08:00 |
|
|
jiantw83andClaude Opus 5
|
81d02bffcf
|
feat(timer,time-log): 起錶配上停錶，並補登議題建立之前的時間
碼錶只在領取工作包時起動，所以工時報表上規劃與分析永遠是零。久了會讓人以為
規劃不花時間，而那正是估算失準最常見的來源。
timer 加上 --stop，而且**只停 --index 指的那一顆**。每個階段停掉自己起的那一支，
錶就不會跨階段跑——跑完就去開會而錶跑一整天，報表當場失真。反過來，別顆議題上的錶
一律不碰：Gitea 在別顆議題上起新錶會靜默地停掉並記錄前一顆，那種靜默結算正是領取鎖
那條規則當初要擋的，不能在這裡反過來製造它。錶本來就沒在跑不算失敗，這一步多半排在
回報之前，報成失敗只會讓人以為前面那件事沒做成而重跑一次。
time-log 補登議題建立之前那一段——讀齊輸入、逐項詢問、組出議題內容，往往是整個 plan
最耗時的部分，而那時候議題還不存在，沒有標的可起錶。長度由腳本自己算（議題的建立時間
減掉 --since），交給 agent 做減法等於讓兩邊的時鐘各算一次，而算錯了報表上看不出來。
**不設時間上限、照實補登**：中途去開會的兩小時會一起算進去，換來這個流程不必為此
多長一題出來問使用者。
補登不是冪等的動作，所以兩種情況跳過不補：錶已經跑在這顆議題上（補登排在起錶之前，
錶在跑就代表這一段補過了），以及這顆議題上已經有工時（整個流程跑完過一次）。工時記
重複比記不到更難在報表上被發現，所以判斷偏向不補。
時間追蹤在現有環境下可能是關著的，真實路徑跑不起來；兩支都靠 --dry-run 與 stub
server 測，共 27 條。
議題 #57
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 19:32:20 +08:00 |
|
|
jiantw83andClaude Opus 5
|
5638593c4c
|
refactor(lib): 停錶與議題工時清單下沉到 lib
停錶原本只長在 pr-create 裡，而規劃與分析接下來也要停自己的錶（議題 #57）。
那段容錯邏輯——「錶沒在跑」的狀態碼隨站台版本而異，認的是狀態碼在 409/500
這一組**且**訊息說的是碼錶——各寫一份遲早會在某一邊漏掉一種狀態碼，而它漏掉的
症狀正是「事情做完了卻回報失敗」。
順手把簽章改成與同伴一致的 (login, repo, index)：fetchIssue、listIssueTimes、
stopwatchOnIssue 都這樣收，只有它收一條手組的路徑字串。
新增 listIssueTimes 供補登判斷「這顆議題上已經有工時了嗎」。它在議題讀得到卻
404 時報 TIME_TRACKER_OFF，與四層前置檢查第四層說同一句話——試跑不跑前置檢查，
那句話得由它自己說，否則試跑看到的是一句看不懂的 404。
議題 #57
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 19:32:01 +08:00 |
|