refinement

refinement — 第一關：凍結 assertion

這一站只做一件事：把成功的定義變成人簽得下去的 assertion，鎖起來。

鎖起來之後，做法怎麼變都不用回來問人；只有成功的定義本身錯了才需要回到這裡重簽。

要不要立案的判斷不在這裡，在 driving-work-to-done。走到這一站表示那個判斷已經做過 而且說出來了。

手上正在做別的事、但長出了一個不能消失的東西時，不要走完這一整站。 開一張種子單， 記下前因後果就好，然後回去做原本那張：

bash .claude/skills/refinement/scripts/open-seed-issue.sh \
  --issues issues --namespace <命名空間> --slug <名字> --note '<前因後果>'

它建目錄、寫下前因後果、記一個「還沒簽 assertion」的狀態、commit，然後就結束——不簽 assertion、 不決定領域、不開 worktree。那些是接手的人在這一站要做的事，而那時候才有人真的想過怎麼 算成功。種子單會出現在 next --across-issues 的答案裡（標成 seed:），所以它拿得給另一個 session 開工。

接手一張種子單就是從這一站的第一步開始走，走到 init——init 認得它身上那個種子狀態， 會把它升級成真的輪次並說出來，不需要先手動刪掉任何東西。

單的形狀

一張單是一個目錄：

issues/                              你自己的 git repo，框架 repo 忽略它
  {命名空間}/                        自己的框架工作、某家公司、某個專案——你決定怎麼分
    {格}/
      {單號}/
        index.md                     正文含凍結塊 fence，其餘是可以改的部分
        .spine/loop-state.json       輪次
        .spine/measurement-ledger.json 量測命令登錄
        .spine/placement.json        它現在該在哪一格——流程算出來寫在這裡，不搬目錄

命名空間叫什麼不影響任何判定——流程逐個走過去，不從名字推導行為。開一張新的單時， 放進它該屬於的命名空間；不確定放哪就開一個新的，命名空間本身沒有註冊表要維護。

issues/ 不歸框架版控。 它記的是你在做什麼、為什麼這樣定義成功；換一個人用同一套 框架，這裡的內容完全不一樣。空殼由這一站自己帶著——它在這支 skill 的 templates/issues/ 底下，跟 skill 一起搬走。第一次使用時：

R=.claude/skills/refinement
mkdir -p issues
cp $R/templates/issues/README.md issues/README.md
cp $R/templates/issues/gitignore.example issues/.gitignore
git -C issues init
git -C issues add . && git -C issues commit -m "issues: 開始"

它仍然必須是一個 git repo——理由見下方〈凍結 ＝ commit〉。verify 從檔案自己的路徑解析 repo，會自動跟著 issues/ 進它自己的歷史，不需要告訴它。

凍結塊與可以改的那部分同檔——一個工作被迫產生的東西是這一份與 code，純文件類的只有這一份。這是 設計意圖，不是一個被量的門檻：那幾個檔案是流程自己寫的，數量恆定，對常數設門檻只會是儀式。 交付時被真的判定的是「舊層還撐著沒有」，見 verify-ac。

問出只有人知道的事

assertion 簽的是「怎麼算成功」。但有幾件事同樣只有人回答得出來，而且它們決定assertion 本身寫得對 不對：這一版到底要做什麼、什麼時候要、提出的人真正想解決什麼、拿什麼測。

單裡寫的「這一層不用改」「維持現狀」「out of scope」是待證主張，不是事實。 那是提單的 人當時的推測，而範圍抄錯的代價要到判定那一站才看得到。定範圍之前實跑一次去驗它——證實了就 寫進去並註明驗過，證偽了就把它拉回範圍內。直接抄進 assertion 等於把別人的假設簽成自己的定義。