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>

prompts/sdlc-analyze.md

@@ -5,9 +5,9 @@ description: 僅由 /sdlc-analyze 指令叫用。對一顆需求議題執行可
 
 對一顆需求議題執行可行性檢查，把疑點一題一題問到雙方有共識，再把共識變成一批工作包議題。
 
-分成三段：**可行性分析**到共識摘要為止，完全不寫入 Gitea；使用者看過摘要點頭之後，
-才進入**產生工作包**建立議題；最後**排上時程與看板**，把相依、截止日、Milestone、
-看板與人天估算補上。
+分成三段：**可行性分析**到共識摘要為止，除了起錶之外完全不寫入 Gitea；使用者看過摘要
+點頭之後，才進入**產生工作包**建立議題；最後**排上時程與看板**，把相依、截止日、
+Milestone、看板與人天估算補上。
 
 這份檔案是流程正本。各平台的轉接檔只是指回這裡，不要把規則抄過去。
 
@@ -15,6 +15,17 @@ description: 僅由 /sdlc-analyze 指令叫用。對一顆需求議題執行可
 
 一個需求議題編號。
 
+## 計時範圍
+
+錶起在**它分析的那顆需求議題**上：在「起錶」那一步起，在「停錶並回報」那一步停，
+涵蓋整道 /sdlc-analyze。
+
+起點放在第一段開頭，因為分析最耗時的正是共識之前那一段——四類疑點逐題問到收斂。
+從第二段才起錶的話，那段時間永遠是零，而報表上「分析不花時間」會直接餵給下一次估算。
+
+錶已經跑在同一顆議題上時起錶什麼都不做，所以 plan 接著跑 analyze 不會把累積的時間
+切成兩段。**錶不跨階段跑**，也**不碰別顆議題上的錶**。
+
 ## 第一段：可行性分析
 
 ### 1. 讀議題
@@ -33,7 +44,22 @@ node scripts/issue-extract.js --repo <owner/name> --index <編號>
 
 使用者選擇不整併就繼續，但要記下這件事，並在共識摘要裡註明「分析基於未整併留言前的描述」。
 
-### 2. 對四份清單列出疑點
+### 2. 起錶
+
+議題確認存在之後，在**這顆需求議題**上起錶：
+
+```
+node scripts/timer.js --repo <owner/name> --index <需求議題編號> --dry-run
+```
+
+確認無誤後拿掉 `--dry-run` 再跑一次。錶已經跑在同一顆上時它什麼都不做，重跑不會把
+已經累積的時間切成兩段。
+
+錶跑在別顆議題上時會被擋下（`STOPWATCH_ON_OTHER_ISSUE`）。**照實告訴使用者是哪一顆，
+請他自己去停**，不要代勞：那一段時間該記在哪顆議題上只有他知道。順帶說明停錶不會動到
+任何既有的工作樹——碼錶只管時間、工作樹只管檔案。
+
+### 3. 對四份清單列出疑點
 
 依序讀這四份規則正本，逐條對照議題內容：
 
@@ -45,7 +71,7 @@ node scripts/issue-extract.js --repo <owner/name> --index <編號>
 每一條檢查若在議題裡找不到答案，就轉成一個問題。**能在程式碼裡查證的就自己去查，
 不要拿去問使用者**——把問題留給只有人能回答的事。
 
-### 3. 逐題問到共識
+### 4. 逐題問到共識
 
 **一次問一題。** 問完等使用者回答，再問下一題，讓他能看著前一題的答案回答下一題。
 不要一次丟出五個問題，也不要把多個問題包成一題的多個選項。
@@ -60,7 +86,7 @@ node scripts/issue-extract.js --repo <owner/name> --index <編號>
 
 問題本身要具體到能用一句話回答。問不出收斂答案的問題，多半是問題本身太大，拆開再問。
 
-### 4. 輸出共識摘要
+### 5. 輸出共識摘要
 
 全部問完後，輸出一份摘要讓使用者做最後確認，內容包含：
 
@@ -75,7 +101,7 @@ node scripts/issue-extract.js --repo <owner/name> --index <編號>
 
 **使用者對共識摘要點頭之後才開始。** 摘要沒有經過確認就不要往下走。
 
-### 5. 切出工作包
+### 6. 切出工作包
 
 把需求切成幾顆工作包。一顆工作包是**開發者拿了就能動手、做完有明確結果**的單位：
 它有自己的驗收標準，做完能單獨被檢視，不必等別的工作包一起才看得出成果。
@@ -86,7 +112,7 @@ node scripts/issue-extract.js --repo <owner/name> --index <編號>
 **禁止流水編號與任何無意義代號**（`WP-01`、`任務三`、`第一階段`）：命名本身就要說明用途，
 看標題就知道這顆在做什麼，不必點進去。
 
-### 6. 組出每顆工作包的內容
+### 7. 組出每顆工作包的內容
 
 套用 `templates/work-package-issue.md`，依序填滿九個段落：
 
@@ -111,7 +137,7 @@ node scripts/issue-extract.js --repo <owner/name> --index <編號>
 8. **repo 列表** — 這顆會動到哪些 repo。
 9. **關聯** — 至少要有一行 `需求議題：#<編號>` 指回來源。阻擋、先決與人天估算由後續流程補上。
 
-### 7. 先試跑，再寫入
+### 8. 先試跑，再寫入
 
 每顆工作包各寫一個暫存檔，然後逐顆：
 
@@ -128,16 +154,18 @@ no-op」。確認無誤後拿掉該旗標再跑一次。
 中斷後重跑不會產生重複工作包：`issue-create` 以標題查重，發現同名議題就回傳既有那一顆
 並把 `created` 設為 `false`。
 
-### 8. 回報
+### 9. 回報
 
 列出每顆工作包的編號、標題與網址。不要把議題內容再貼一次。
 
+**這裡不停錶**——指令還沒跑完，第三段還要排時程。停錶在最後的「停錶並回報」那一步。
+
 ## 第三段：排上時程與看板
 
 工作包建好之後，把它們之間的關係與時程補上。做完這一段，看板上呈現的才是真實的
 開發順序，而不是一堆平鋪的議題。
 
-### 9. 算出截止日
+### 10. 算出截止日
 
 把每顆工作包的編號、人天估算與先決關係寫成一份計畫檔：
 
@@ -161,7 +189,7 @@ node scripts/schedule.js --plan-file <計畫檔>
 
 日期以日曆日累加，不跳週末也不扣假日。要跳的話自己把 `startDate` 或人天調整過再算。
 
-### 10. 逐顆補上關係與時程
+### 11. 逐顆補上關係與時程
 
 對每一顆工作包，依序：
 
@@ -179,7 +207,7 @@ node scripts/project-add.js --repo <owner/name> --index <編號> --project "<看
 看板名稱靠掃最近 50 筆議題反查 id，反查不到就會請你直接貼專案網址（結尾即 id）。
 本流程不建立 Milestone，也不建立專案。
 
-### 11. 產生分析版的圖解總覽
+### 12. 產生分析版的圖解總覽
 
 用同一份 `templates/overview-artifact.html` 再產一份，但這一份要多出**工作包全景**：
 把工作包之間的相依與截止日畫成一張圖，讓開發者看得出自己這一項在整體中的位置。
@@ -205,7 +233,16 @@ node scripts/issue-update.js --repo <owner/name> --index <需求議題編號> --
 **重跑會就地更新同一行**，不會在議題上留下兩個連結。規劃階段產生的那一份會被這一份取代，
 這是預期行為——同一顆需求議題只掛一個總覽網址。
 
-### 12. 回報
+### 13. 停錶並回報
+
+回報之前先停錶，這一段計時到此為止：
+
+```
+node scripts/timer.js --repo <owner/name> --index <需求議題編號> --stop
+```
+
+它**只停這一顆**上的錶，與「起錶」那一步起的是同一顆。錶本來就沒在跑不算失敗
+（`碼錶已停` 會是 `false` 並附一句說明），回報照樣做完。
 
 列出每顆工作包的編號、標題、截止日與所屬 Milestone，並指出**相依鏈最長路徑**上的那幾顆
 ——那條路徑決定整體交期。
@@ -236,9 +273,13 @@ Gitea 1.27 的 API 沒有任何請求定義接受 `time_estimate`，該欄位只
 
 ## 邊界
 
-- **共識摘要之前不對 Gitea 產生任何寫入**：不建議題、不改描述、不貼標籤、不留留言。
+- **共識摘要之前不對 Gitea 寫入任何內容**：不建議題、不改描述、不貼標籤、不留留言。
+  **碼錶除外**——它記的是工時，不是內容；而分析最耗時的正是共識之前那一段，不從那裡
+  起錶，那段時間就永遠是零。
 - 第二段只建立工作包議題。不建相依、不掛 Milestone、不加看板、不寫人天估算——那是第三段的事。
 - 第三段只掛既有的 Milestone 與看板。不自行建立標籤、Milestone 或專案看板。
 - 不修改使用者的專案檔案。查證既有功能時只讀不寫。
 - 不替使用者決定他沒回答的事。問不到答案就進「仍然未決的事」。
+- 計時只動這顆需求議題：在它上面起錶、在它上面停錶。**不停別顆議題上的錶**，
+  被別顆的錶擋下時交還給使用者決定，不繞過去。
 - 不關閉或刪除任何既有議題。