jiantw83
b7b1d8bb01
What
- `skills/plan`、`skills/analyze`、`skills/implement`、`skills/maintain`：目錄頁的讀取敘述改成從 H2 區塊取值，寫入敘述從「單列 upsert」改成單一 H2 區塊 upsert，鍵補上內容頁頁名這個引數，並註明第四個引數是區塊檔。
- `skills/maintain`：讀寫的鍵改成該存取庫的 `{owner}/{repo}`，因為這個型別沒有內容頁。
- `references/behaviors.md`：四支技能的關鍵步驟、外部呼叫與可驗證跡象同步，跡象從「留下那一列」改成留下那一個 H2 區塊。
- `references/consensus.md`：查已答問題那一條補上問答目錄頁也是條列式版面、要從區塊取值而不是表格列。
- `references/stage-report.md`：目錄頁也算寫入那一段補上「改動一個區塊也算寫過那一頁」，並統一用 `CONTENTS` 這個型別餵進去。
- `README.md`：四支技能的流程敘述與 wiki 規則段同步，並補上五個目錄頁的版面規則、鍵的落點與各頁鍵欄的正確序號。
Why
- 範本已經改成條列版面，技能內文還寫著「那一列」，執行時就會照舊敘述組出表格列，跟工具的單一區塊 upsert 對不上。
- 讀取端的敘述沒跟著改，技能會拿表格的解析方式去讀一頁條列，既有紀錄一筆都認不出來。
- 呼叫少帶鍵這個引數，工具無從判斷要換掉哪一個區塊，同一筆會被當成新的附加上去。
- 行為清單是稽核與驗證的比對基準，敘述沒跟上，稽核會拿舊描述判合規。
How
- 四支技能的呼叫一律寫成 `wiki-contents.sh upsert {TYPE} {鍵欄} "{鍵}" {區塊檔} [{範本}]`，各頁的鍵欄序號照線上那一頁實際的欄位排法寫定。
- 完成條件與可驗證跡象改用區塊的說法，連結範例改成 `- {欄位名}：[{頁名}]({連結})` 的形態。
- 只改敘述與說明，不動任何腳本；轉檔與 upsert 的實作在別的存取庫。
Who
- 本存取庫四支階段技能，以及讀這幾份說明檔決定共識判定與階段回報寫法的流程。
- 稽核與驗證流程改拿新的行為清單比對。
2.1 KiB
2.1 KiB
共識判定 — 規劃與分析階段的提問規則
plan 與 analyze 都靠提問把需求問清楚。兩個階段共用本規則，各自不再重寫一份。
一輪不算問完
- 每個回答都要生出下一個問題：從使用者的答案往下推，找出它新暴露的未知，繼續問。答完一輪就收工是最常見的失敗。
- 問題一次只問一件事，選項一律標明影響範圍（依
jsc-ask:ask）。 - 問過的別再問：先查 wiki 的
QUESTION_CONTENTS與QUESTION_{HASH}，已答的直接沿用。目錄頁QUESTION_CONTENTS是條列式版面，一個 H2 區塊一筆，標題就是對應的QUESTION_{HASH}頁名，欄位在標題底下逐條列出，不是表格的一列。
達成共識的兩個條件
同時滿足才算共識，缺一不可：
- 沒有未知會改變產出——任何還沒問清楚的細節，都不足以改變使用者故事、工作包切分或工時估算。
- 使用者明確確認——把整理過的結論讀回去，使用者明確表示同意。
每輪都要讓共識可見
提問前先攤開現況，不要讓使用者自己記：
| 區塊 | 內容 |
|---|---|
| 已達成共識 | 已確認的項目與結論 |
| 尚未釐清 | 還開著的項目，以及它會影響什麼 |
| 本輪要問 | 這一輪要解決哪一項 |
不可以做的事
- 不得用自己的假設補洞。缺資訊就問，不能先寫下去再說。
- 不得把沉默或「都可以」當成答案——只要該項會改變範圍或切分，就要追問到具體選項。
- 不得在還有開著的項目時往下走（規劃不得產出使用者故事，分析不得開始 WBS）。
- 使用者確實不想決定時：把它當未決項寫進頁面，註明影響與預設處理方式，並問使用者要不要接受那個預設值。未決項不得靜默消失。
收尾
- 共識達成後，把「問了什麼、答了什麼」依
jsc-ask:ask規則回存 wiki，讓下一階段不必重問。 - 頁面上的未決項要能追：誰要決定、什麼時候決定、不決定會怎樣。