分析：{計畫名稱}

{PLAN 頁絕對網址}、{REPO 頁絕對網址} 由 jsc-gitea/tools/gitea.sh wiki-url 取得。跨頁型連結一律用絕對網址：不同頁型可能落在不同存取庫，[[頁名]] 只在同一個 wiki 內解析。

頁名：ANALYZE_{HASH}
HASH：{HASH}
對應計畫：[PLAN_{HASH}]({PLAN 頁絕對網址})
存取庫：{owner}/{repo}
來源分支：origin/{使用者確認的分支}（head sha：{sha}，取自遠端）
狀態：未完成
建立時間：{yyyy-MM-dd HH:mm:ss}

現況摘要

工作目錄：{關鍵檔案與結構摘要}
複用來源：[REPO_{HASH}]({REPO 頁絕對網址})（commit sha：{sha}）
複用決策：{複用哪些方法、端點、為什麼；不複用的原因}

未決項

項目	影響	預設處理	待決定者
{項目}	{不決定會怎樣}	{暫定做法}	{誰}

工作分解結構（WBS）

WP-01 固定是交付、交接工作包，獨立成一包，不與實作合併；用到它規格的實作工作包相依於它。交付型別於實作階段開工時確認（API 文件、由使用者輸入）。資料來源欄記錄範例資料的出處：真實：{source} 或 推論：無來源。 PR 欄記錄該工作包的 PR 連結與編號；一個工作包的 PR 未合併前，擋的是相依於它的工作包，不是整份分析——跟它無關的工作包可以平行進行，不必等它合併。相依欄只寫本頁的 WP-NN 編號，多個用頓號分隔（例：WP-01、WP-03）；沒有相依填 -。implement 挑包時靠 wp-gate.sh check-deps 活查這一欄逐一核對，寫成別的格式（自然語言、別份計畫的敘述）它查不出來，只會被列成「需人工確認」。跨頁的相依（例如依賴另一份計畫的產出）本來就查不了，允許寫成文字，但盡量也帶出可辨識的來源（頁名、HASH）方便人工核對。

編號	工作包名稱	交付	交付型別	相依	工時(h)	天數	資料來源	狀態
WP-01	{交付、交接：規格與介面定義}	是	API 文件	-	{h}	{d}	真實：{source}	未完成
WP-02	{實作類名稱}	否	-	WP-01	{h}	{d}	真實：{source}	未完成
WP-03	{實作類名稱}	否	-	WP-01	{h}	{d}	推論：無來源	未完成

關鍵路徑：{WP-01 → WP-02 → ⋯⋯}，總天數 {d}
實作候補：{WP-02、WP-03、⋯⋯}

關鍵路徑（CPM）

甘特圖語法固定照 references/cpm-chart.md：dateFormat YYYY-MM-DD 配任意錨點日期、每個工作包一個 id、時長用整數小時、除第一個外全部 after {上一個id} 串接。不得用 dateFormat X 或把工時換算成小數天數填進圖裡，會炸出 Invalid date。

gantt
  title 關鍵路徑（單位：小時；錨點日期非真實排程，僅供相對呈現）
  dateFormat YYYY-MM-DD
  axisFormat %m-%d %H:%M
  section 關鍵路徑
  WP-01 {名稱} :crit, wp01, 2000-01-01, {h}h
  WP-02 {名稱} :crit, wp02, after wp01, {h}h

使用者故事驗收計畫

每個使用者故事都要列出驗收情境。驗收方式只能填 真實資料 或 邏輯推論。簡單故事至少 1 個情境；中等故事至少 2 個情境，含主要流程與邊界或錯誤流程；複雜故事至少 3 個情境，含主要流程、邊界流程與失敗流程。資料來源要寫可查證來源；沒有外部來源時填 邏輯推論：{推論依據}。

使用者故事	複雜度	情境	驗收方式	輸入	預期結果	資料來源	對應工作包
{故事名稱}	簡單	主要流程：{情境名稱}	真實資料	{輸入資料}	{可驗收結果}	真實資料：{來源}	WP-02
{故事名稱}	中等	邊界流程：{情境名稱}	邏輯推論	{輸入資料}	{可驗收結果}	邏輯推論：{推論依據}	WP-02
{故事名稱}	複雜	失敗流程：{情境名稱}	邏輯推論	{輸入資料}	{錯誤狀態或拒絕原因}	邏輯推論：{推論依據}	WP-03

測試計畫（TDD）

每個實作工作包都要列出完整 TDD 循環。每個待辦都要寫出受測接縫、對應驗收情境、測試斷言行為、最小實作範圍、綠燈驗證方式。不要把紅燈測試、最小實作、綠燈驗證拆成不同待辦。交付、交接工作包也要列出規格審查、範例資料驗證、相依工作包可用性證據。

WP-01 {交付、交接工作包名稱}

規格接縫：盤點 {對象} 的端點、參數、回應與錯誤狀態，覆蓋驗收情境 {情境名稱}
範例資料驗證：產出真實與推論來源標籤，確認相依工作包能直接使用
交付證據：與使用者確認交付內容並產出交付文件

WP-02 {工作包名稱}

TDD 循環：驗收情境 {情境名稱}；接縫 {接縫}；先寫會失敗的測試，斷言 {預期行為}；最小實作範圍 {實作範圍}；重跑 {測試指令或測試集合} 確認綠燈；必要時重構並保持綠燈

5.2 KiB Raw Blame History Unescape Escape