【Day - 16】把討論留下來後，下次就能接著談。不過，已經談妥的內容，還得帶進 change，才能繼續準備規格與 tasks。
如果同一場 discussion 裡，只有其中一個主題先談好，也不一定要等其他問題全部談完。我希望能先替它建立 change，剩下的繼續留著討論；如果談的是原本就在做的功能，則把新結論補回那份 change。這篇就來看看這幾種情況怎麼處理。
例如，一開始只是想討論「登入流程還可以怎麼調整」，最後可能拆出三個方向：
圖中的 MFA 與錯誤訊息已經談妥，可以先各自建立 change；session 過期時間還沒有結論，就繼續留在原本的 Rounds。這樣不需要為了先做其中一項，就把整場 discussion 提早結束。
實際記錄時，第一輪的 Open 會先列出還沒處理完的主題。某一項談妥後，AI 會先確認要把它接到 change，還是繼續討論其他內容。如果決定先分出去，這一輪的 Position 會記下它去了哪個 change，下一輪的 Open 則只保留尚未處理的項目。
建立 change 後，discussion 會在 promoted_to 記下它的名稱；change 則在 from_discussion 記下來源 discussion。這樣從任何一邊，都能找到另一邊。
from_discussion 就放在【Day - 7】介紹過的 .openspec.yaml 裡。Speclink 沿用這份檔案記錄 change 的基本資料，再加上討論來源。以前面的登入流程為例，大概會像這樣：
# openspec/discussions/login-flow.md
status: promoted
promoted_to: add-mfa, improve-login-errors
# openspec/changes/add-mfa/.openspec.yaml
from_discussion: login-flow
# openspec/changes/improve-login-errors/.openspec.yaml
from_discussion: login-flow
所以下次回到 discussion 時，我不只看得到還有哪些問題沒談完，也能知道前面談妥的內容分別去了哪些 changes；從 change 往回看，也找得到最初是在哪一場 discussion 做出決定的。
打開同一份 discussion 的「衍生變更」頁籤，就能直接看到它分出去的兩個 changes：
要不要把談妥的主題建立成 change，還是由我們決定，不會每談一個主題就自動建一份。
不過，已經建立 change，不表示整場 discussion 都談完了。只要還沒寫下 Conclusion，就能繼續新增 Rounds。Speclink Desktop 也會把它留在進行中的討論區，標示「已轉出・尚無結論」。
畫面上會像下面這樣：discussion 仍然留在左側的討論區，已經分出去的 add-mfa 則進入提案中。
知道討論與 change 怎麼互相找得到之後，接著來看實際怎麼建立 change：整場談完再規劃，和只把其中一項先分出去，操作上有什麼不同？
我平常最常走的路其實很單純：先把整場 discussion 談完，確認每個 change 的範圍，再從 discussion 進入 propose，把規劃需要的 artifacts 建立起來。只有某個主題已經談妥、其他內容還想留在原本的 discussion 繼續談時，才需要先用 promote 把它分出去。
當時和 AI 討論這套設計時，我們整理出的路徑大致可以分成三種：
| 當下的情況 | 使用的作法 | 這一步會做到哪裡？ |
|---|---|---|
| 整場 discussion 已經有 Conclusion，也準備開始規劃 | propose from discussion | 讀取 Conclusion 與前面的 Rounds，建立 change，並依照 schema 準備實作前需要的 artifacts |
| 只有其中一項先談妥，其他主題還要繼續 | promote | 先替這一項建立 change 骨架並記住來源，原本的 discussion 可以繼續新增 Rounds |
| 其中一項先談妥，而且現在就想把它規劃完整 | promote → propose | 先用 promote 把這一項分成明確的 change，再對同一個 change 執行 propose 補齊 artifacts；其他主題仍然留在原本的 discussion |
propose from discussion 適合整場討論已經收斂的情況。它會直接從 Conclusion 建立 change，再把 schema 要求的規劃文件一起準備好。至於 promote，目的則是先把某一項從還沒結束的 discussion 裡分出去。這時候建立的 change 大概只有下面這些內容：
openspec/changes/<change>/
├── .openspec.yaml # schema、建立資訊與 from_discussion
└── proposal.md # 先填入 Why，其他段落仍待後續補齊
這時候只有 change 的基本資料，以及還沒寫完整的 proposal，所以還不能開始 apply。要繼續實作，得先透過 propose 補齊 schema 要求的規劃文件；原本還沒談完的主題，則繼續留在 discussion。
不過，我後來很少先用 promote。除了個人習慣，也因為分出去後還是要再跑 propose，所以我通常會先談完、確認各個 change 的範圍，再開始規劃。只有某一項真的想先做，才會用到這個流程。
上面三種情況都是建立新的 change。如果 discussion 談出的結論，是要調整一份正在實作的 change，又該怎麼接回去？
如果討論的結果是要修改原本的 change，我平常就會請 AI 把新結論補進原本的規劃。不過，這中間曾經遇到一個問題：文件還沒更新，discussion 卻先顯示成「已轉出」了。
當時留下的設計討論記錄了這個情況。AI 先把 discussion 和 change 的關係記下來，但 session 在執行 ingest 前就停了。結果 change 裡還是舊內容，畫面卻讓人以為新的結論已經補進去了。
所以，我後來把「記下來源」和「更新完成」分開。先記住這次修改來自哪場討論，等文件真的更新好了，再標示完成。discuss Skill 會依序執行三個動作：
| 動作 | 這一步在做什麼？ |
|---|---|
| link | 先在 change 記下這次決定來自哪一場 discussion。 |
| ingest | 把新的結論補進 proposal、specs、design 或 tasks。 |
| seal | 更新完成後，再把 change 加進 discussion 的 promoted_to，標示這份結論已經轉入。 |
這樣就算 session 中途停下來，也不會把「已經記下來源」當成「文件已經更新完成」。
更新完後，討論也可能繼續。如果後來又改了 Conclusion，之前照著舊結論規劃的 changes，要不要跟著改呢？Speclink 會先把仍在進行中的相關 changes 標成「待重新反映」，提醒我們確認。有影響就透過 ingest 更新，完成後清掉提醒；沒有影響，確認後就不用改。
建立新 change、先把其中一個主題分出去，以及更新原本的 change，這幾種作法放在一起，就會像下面這張圖：
同一場 discussion 可以建立新的 change，也可以更新既有 change。那麼，一次談了 5～10 個主題，到底該分成幾個 changes 呢？
一場 discussion 談了幾個主題，不一定就要建立幾個 changes。幾個想法可能是在解決同一件事，也可能談到後來，才發現其實是彼此獨立的功能。
我會先把想到的問題一起提出來，讓 AI 依序和我討論。這時候很多事情還沒確定，不需要一開始就決定要怎麼拆。等方向比較清楚後，再一起確認：哪些內容適合放在同一個 change？哪些應該分開做？還沒談清楚的，就留著繼續討論。
到了這一步，才會回到【Day - 6】提過的原則：規格的範圍要清楚，也要能一起驗證。如果幾個主題是在完成同一個目標，而且適合一起實作與驗證，就可以放進同一個 change；如果各自是獨立的功能，就分開處理。
一次要談多少主題？ 5～10 個是我自己的使用習慣。如果一次只談一兩個比較好掌握，也不需要刻意增加。
這樣，我就不用在開始討論前先把所有需求分好，也不用為了先做其中一項，就把其他問題一起塞進 change。談好的部分可以往下做，還沒談完的也留得住；下次回來，還能查到各個主題後來去了哪裡。
討論怎麼保存、談好的內容怎麼接進 change，到這裡都有了作法。至於討論正在進行時，AI 怎麼帶著我把問題問清楚，當時仍然沿用 Spectra discuss。我平常遇到的幾乎都是先列假設的 Assumptions，很少進入一次問一題的 Interview。為什麼會這樣選，這個問法又適合我的需求嗎？接下來，我們就看看我後來怎麼調整 Speclink 的提問方式吧！
iThome鐵人賽
看影片追技術