jiantw83
f4e489ceb4
取消 [[頁名]] 與 [[顯示文字|頁名]] 兩種同 wiki 寫法，不再分「同存取庫」與 「跨存取庫」兩條規則。那種寫法只在自己那個 wiki 內解析，寫錯不報錯，畫面上 看起來像普通文字或死連結，巡不到也修不了。 連結寫進頁面前先過 jsc-gitea 的 link-check.sh，結束碼 0 才寫。驗證一律走 API， 不看網頁狀態碼：私有存取庫的網頁網址對未登入請求一律回 404，拿狀態碼判會把 好連結判成壞的。認證失敗回 7，與死連結的 1 分開，免得金鑰一過期就把還在的頁 整批判死。
87 lines
5.9 KiB
Markdown
87 lines
5.9 KiB
Markdown
# 分析：{計畫名稱}
|
||
|
||
> {PLAN 頁絕對網址}、{REPO 頁絕對網址} 由 `jsc-gitea/tools/gitea.sh wiki-url` 取得。
|
||
> 連結寫法：一律寫成 `[{文字}]({連結})`，連結一律用絕對網址，不自行組路徑，也不用 `[[頁名]]` 或 `[[顯示文字|頁名]]`：後者只在同一個 wiki 內解析，寫錯不會報錯，畫面上看起來像純文字或死連結，巡不到也修不了。
|
||
> 寫入前驗證：要放進本頁的每一個連結先交給 `jsc-gitea/tools/link-check.sh`，結束碼 0 才寫入。有一筆 DEAD 就不寫，把連不到的清單回報給呼叫端。驗證走 API，不看網頁狀態碼：私有存取庫的網頁網址對沒帶金鑰的請求一律回 404，照狀態碼判會把還活著的頁判成死連結。結束碼 `1`=至少一筆連不到、`2`=一個網址都沒給、`3`=`GITEA_HOST` 未設定、`7`=金鑰失效，停下回報金鑰問題，不得當成連不到。
|
||
|
||
- 頁名：`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) | 天數 | 資料來源 | 工作證 | PR | 狀態 |
|
||
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||
| 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`。
|
||
|
||
```mermaid
|
||
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 循環：驗收情境 {情境名稱}；接縫 {接縫}；先寫會失敗的測試，斷言 {預期行為}；最小實作範圍 {實作範圍}；重跑 {測試指令或測試集合} 確認綠燈；必要時重構並保持綠燈
|