為規劃與分析階段計時並補登規劃時間 #57

New Issue

2026-09-17T10:00:45Z

jiantw83 commented

2026-09-17 10:00:45 +00:00

母議題

#56 — 補上六個指令走通後浮現的四個缺口

要做出什麼

規劃與分析的時間不再憑空消失。/sdlc-report 產出的數字裡，規劃、分析、實作三段都在，估算的落差看得出來源——目前碼錶只在領取工作包時起動，所以報表上規劃永遠是零，久了會讓人以為規劃不花時間，而那正是估算失準最常見的來源。

/sdlc-plan 在需求議題建立之後起錶（在此之前議題不存在，沒有標的可起），回報那一步停錶。議題建立之前那段——讀齊輸入、逐項詢問、組出議題內容，往往是整個 plan 最耗時的部分——以手動加時間的方式補登上去。補登不設上限、照實補登：中途去開會的時間會被算進去，換來這個流程不必為此多長一題出來問使用者。

補登的終點看議題是不是這一輪建立的：是就補到議題建立那一刻；對既有議題重跑時就補到補登的當下——那一輪的規劃時間照樣要進報表，拿舊的建立時間當終點會算出負數，等於把那一輪的工夫丟掉。重跑是累計不是覆蓋，每一輪各記一筆。唯一不補的情形是錶已經跑在這顆議題上，那一段已經有錶在記，補下去會與錶涵蓋的區間重疊。

/sdlc-analyze 在它分析的那顆需求議題上起錶，回報那一步停錶。錶已經跑在同一顆議題上時什麼都不做——中斷後重跑不會把已經累積的時間切成兩段。

plan 與 analyze 各記各的：plan 在自己的回報那一步就停了錶，所以同一顆需求議題上會有兩筆工時，加總起來才是它到目前為止花掉的時間。這是刻意的——「每個階段停掉自己起的錶」與「兩段合成一筆」無法同時成立，而錶跨階段跑的代價（跑完就去開會，錶跑一整天）比多一筆紀錄大得多。

每個階段停掉自己起的錶，不讓錶跨階段跑。跑完就去開會而錶跑一整天，報表當場失真。也不在領取鎖上開自動停錶的後門：Gitea 在別顆議題上起新錶會靜默地停掉並記錄前一顆，那種靜默結算正是領取鎖那條規則當初要擋的，不能在這裡反過來製造它。

起錶與停錶在同一份正本裡成對出現，讀的人一眼看得出這段計時涵蓋到哪。

注意（2026-09-18 更正）：原先記載「所有 repo 的時間追蹤都是關閉的」已不成立——plugins/tea-sdlc 的 enable_time_tracker 是 true，真實路徑在這顆議題上實跑驗過：補登 121 秒、起錶、停錶 7 秒，兩筆都進得了 /sdlc-report 的週報，驗完已刪除。自動化測試仍靠 --dry-run 與 stub server，不依賴真實站台。

驗收標準

sdlc-plan 在需求議題建立之後起錶，在回報那一步停錶
sdlc-plan 將「指令開始到議題建立」的時間以手動加時間 API 補登至該需求議題
補登不設時間上限，不因時長而改為詢問使用者
對既有議題重跑時補到當下，每一輪各記一筆而不是覆蓋前一輪
補登發生在議題建立之後、起錶之前，兩者指向同一顆議題
sdlc-analyze 在它分析的需求議題上起錶，在回報那一步停錶
錶已經跑在同一顆議題上時不重新起錶，不把累積時間切成兩段
不修改領取鎖的規則，不新增任何自動停掉他顆議題碼錶的行為
兩份正本中起錶與停錶成對出現，各自的範圍在正本上讀得出來
--dry-run 下補登與起錶輸出將發出的請求而不實際執行
測試涵蓋：補登時長等於指令開始到議題建立的差值；重跑時補到當下且累計；補登與起錶的先後順序；起停成對性

阻擋於

無，可立即開始

## 母議題 #56 — 補上六個指令走通後浮現的四個缺口 ## 要做出什麼規劃與分析的時間不再憑空消失。`/sdlc-report` 產出的數字裡，規劃、分析、實作三段都在，估算的落差看得出來源——目前碼錶只在領取工作包時起動，所以報表上規劃永遠是零，久了會讓人以為規劃不花時間，而那正是估算失準最常見的來源。 `/sdlc-plan` 在需求議題建立之後起錶（在此之前議題不存在，沒有標的可起），回報那一步停錶。議題建立之前那段——讀齊輸入、逐項詢問、組出議題內容，往往是整個 plan 最耗時的部分——以手動加時間的方式補登上去。補登**不設上限、照實補登**：中途去開會的時間會被算進去，換來這個流程不必為此多長一題出來問使用者。補登的終點看議題是不是這一輪建立的：是就補到**議題建立那一刻**；對**既有議題重跑**時就補到**補登的當下**——那一輪的規劃時間照樣要進報表，拿舊的建立時間當終點會算出負數，等於把那一輪的工夫丟掉。**重跑是累計不是覆蓋**，每一輪各記一筆。唯一不補的情形是錶已經跑在這顆議題上，那一段已經有錶在記，補下去會與錶涵蓋的區間重疊。 `/sdlc-analyze` 在它分析的那顆需求議題上起錶，回報那一步停錶。錶已經跑在同一顆議題上時什麼都不做——**中斷後重跑**不會把已經累積的時間切成兩段。 plan 與 analyze 各記各的：plan 在自己的回報那一步就停了錶，所以同一顆需求議題上會有兩筆工時，加總起來才是它到目前為止花掉的時間。這是刻意的——「每個階段停掉自己起的錶」與「兩段合成一筆」無法同時成立，而錶跨階段跑的代價（跑完就去開會，錶跑一整天）比多一筆紀錄大得多。 **每個階段停掉自己起的錶**，不讓錶跨階段跑。跑完就去開會而錶跑一整天，報表當場失真。也**不在領取鎖上開自動停錶的後門**：Gitea 在別顆議題上起新錶會靜默地停掉並記錄前一顆，那種靜默結算正是領取鎖那條規則當初要擋的，不能在這裡反過來製造它。起錶與停錶在同一份正本裡成對出現，讀的人一眼看得出這段計時涵蓋到哪。 **注意**（2026-09-18 更正）：原先記載「所有 repo 的時間追蹤都是關閉的」已不成立——`plugins/tea-sdlc` 的 `enable_time_tracker` 是 `true`，真實路徑在這顆議題上實跑驗過：補登 121 秒、起錶、停錶 7 秒，兩筆都進得了 `/sdlc-report` 的週報，驗完已刪除。自動化測試仍靠 `--dry-run` 與 stub server，不依賴真實站台。 ## 驗收標準 - [x] `sdlc-plan` 在需求議題建立之後起錶，在回報那一步停錶 - [x] `sdlc-plan` 將「指令開始到議題建立」的時間以手動加時間 API 補登至該需求議題 - [x] 補登不設時間上限，不因時長而改為詢問使用者 - [x] 對既有議題重跑時補到當下，每一輪各記一筆而不是覆蓋前一輪 - [x] 補登發生在議題建立之後、起錶之前，兩者指向同一顆議題 - [x] `sdlc-analyze` 在它分析的需求議題上起錶，在回報那一步停錶 - [x] 錶已經跑在同一顆議題上時不重新起錶，不把累積時間切成兩段 - [x] 不修改領取鎖的規則，不新增任何自動停掉他顆議題碼錶的行為 - [x] 兩份正本中起錶與停錶成對出現，各自的範圍在正本上讀得出來 - [x] `--dry-run` 下補登與起錶輸出將發出的請求而不實際執行 - [x] 測試涵蓋：補登時長等於指令開始到議題建立的差值；重跑時補到當下且累計；補登與起錶的先後順序；起停成對性 ## 阻擋於無，可立即開始

jiantw83 added the ready-for-agent label 2026-09-17 10:00:45 +00:00

jiantw83 added a new dependency 2026-09-17 10:00:45 +00:00

#58 以能力描述表達委派並標記可委派步驟

jiantw83 referenced this issue

2026-09-17 10:00:45 +00:00

以能力描述表達委派並標記可委派步驟 #58

jiantw83 added spent time 2 minutes

2026-09-18 00:44:48 +00:00

jiantw83 started working 2026-09-18 00:44:49 +00:00

jiantw83 worked for 7 seconds

2026-09-18 00:44:56 +00:00

jiantw83 deleted spent time 2026-09-18 00:45:10 +00:00