feat(sdlc-analyze): 加入第三段，把工作包排上時程與看板

先算後寫：schedule 算出截止日，再由 issue-link、issue-update、project-add 逐顆
補上相依、時程與看板。三支都先試跑再實跑，三支都是冪等的。

另立一節寫明人天估算的 API 限制，而不是把它藏在行文裡——estimate 只寫得進 body，
sdlc-report 之後讀的也是那一行，這件事踩到才知道就太晚了。

邊界改成三段各自列：哪一段不做什麼講清楚，兩顆工作包才不會互相踩。

Closes #8

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

prompts/sdlc-analyze.md

@@ -1,12 +1,13 @@
 name: sdlc-analyze
-description: 僅由 /sdlc-analyze 指令叫用。對一顆需求議題執行可行性檢查，逐題問到共識後產生工作包議題。
+description: 僅由 /sdlc-analyze 指令叫用。對一顆需求議題執行可行性檢查，逐題問到共識後產生工作包議題並排上時程。
 
 # sdlc-analyze
 
 對一顆需求議題執行可行性檢查，把疑點一題一題問到雙方有共識，再把共識變成一批工作包議題。
 
-分成兩段：**可行性分析**到共識摘要為止，完全不寫入 Gitea；使用者看過摘要點頭之後，
-才進入**產生工作包**，那一段才會建立議題。
+分成三段：**可行性分析**到共識摘要為止，完全不寫入 Gitea；使用者看過摘要點頭之後，
+才進入**產生工作包**建立議題；最後**排上時程與看板**，把相依、截止日、Milestone、
+看板與人天估算補上。
 
 這份檔案是流程正本。各平台的轉接檔只是指回這裡，不要把規則抄過去。
 
@@ -128,8 +129,68 @@ no-op」。確認無誤後拿掉該旗標再跑一次。
 
 列出每顆工作包的編號、標題與網址。不要把議題內容再貼一次。
 
-## 架構圖的限制
+## 第三段：排上時程與看板
 
+工作包建好之後，把它們之間的關係與時程補上。做完這一段，看板上呈現的才是真實的
+開發順序，而不是一堆平鋪的議題。
+
+### 9. 算出截止日
+
+把每顆工作包的編號、人天估算與先決關係寫成一份計畫檔：
+
+```json
+{
+  "startDate": "2026-09-21",
+  "workPackages": [
+    { "index": 12, "title": "建立共用函式庫", "days": 3 },
+    { "index": 13, "title": "建立抽取契約", "days": 2, "depends": [12] }
+  ]
+}
+```
+
+```
+node scripts/schedule.js --plan-file <計畫檔>
+```
+
+它依相依關係做拓撲排序，保證**任一工作包的截止日都不早於它的先決**——人工排時程
+最常見的矛盾就是前置工作比後續還晚到期。相依成環時它會直接報錯並指出環上的成員，
+那代表拆法有問題，回頭改拆法，不要硬排。
+
+日期以日曆日累加，不跳週末也不扣假日。要跳的話自己把 `startDate` 或人天調整過再算。
+
+### 10. 逐顆補上關係與時程
+
+對每一顆工作包，依序：
+
+```
+node scripts/issue-link.js --repo <owner/name> --index <編號> --depends <先決編號清單>
+node scripts/issue-update.js --repo <owner/name> --index <編號> \
+  --milestone "<既有 Milestone 名稱>" --due-date <schedule 算出的日期> --estimate-days <人天>
+node scripts/project-add.js --repo <owner/name> --index <編號> --project "<看板名稱或網址>"
+```
+
+三支都先用 `--dry-run` 看過再實跑。三支都是冪等的：相依已存在就跳過、已在看板上就不重發、
+估算沒變就不改 body。
+
+**Milestone 與看板都只掛既有的。** 指到不存在的 Milestone 會中止並列出可選項目；
+看板名稱靠掃最近 50 筆議題反查 id，反查不到就會請你直接貼專案網址（結尾即 id）。
+本流程不建立 Milestone，也不建立專案。
+
+### 11. 回報
+
+列出每顆工作包的編號、標題、截止日與所屬 Milestone，並指出**相依鏈最長路徑**上的那幾顆
+——那條路徑決定整體交期。
+
+## 已知限制：人天估算只寫得進 body
+
+Gitea 1.27 的 API 沒有任何請求定義接受 `time_estimate`，該欄位只出現在議題的回應裡。
+也就是說**議題的估算欄位無法由 API 寫入**，只能靠人在網頁上填。
+
+因此 `issue-update --estimate-days` 只把估算寫成議題 body 裡人類可讀的一行
+（`估算人天：N`，放在「關聯」段落）。之後 `sdlc-report` 要比對估算與實際工時時，
+讀的也是這一行。
+
+## 架構圖的限制
 依工作包的性質選圖：
 
 - **`sequenceDiagram`** — 重點在「誰呼叫誰、順序為何」時用。
@@ -146,8 +207,8 @@ no-op」。確認無誤後拿掉該旗標再跑一次。
 ## 邊界
 
 - **共識摘要之前不對 Gitea 產生任何寫入**：不建議題、不改描述、不貼標籤、不留留言。
-- 第二段只建立工作包議題。不建相依、不掛 Milestone、不加看板、不寫人天估算——那是後續流程的事。
-- 不自行建立標籤、Milestone 或專案看板。
+- 第二段只建立工作包議題。不建相依、不掛 Milestone、不加看板、不寫人天估算——那是第三段的事。
+- 第三段只掛既有的 Milestone 與看板。不自行建立標籤、Milestone 或專案看板。
 - 不修改使用者的專案檔案。查證既有功能時只讀不寫。
 - 不替使用者決定他沒回答的事。問不到答案就進「仍然未決的事」。
 - 不關閉或刪除任何既有議題。