上一篇提到，PM／SA 和工程師各自留下了規格，卻還沒有接在一起。如果 PM／SA 繼續使用團隊 AI Agent，工程師也留在熟悉的開發工具裡，能不能讓兩邊讀寫同一份內容，不必再重新整理一次呢？
為了試試這個想法，我開始替 Speclink 加入 Remote：把 discussion、change 與正式 specs 保存在 server，再讓 Speclink Desktop 與 CLI 連線讀寫。工程師要修改的 code，仍然留在本機工作目錄。
這篇先看看我目前試到哪裡，再說明接下來想怎麼接回團隊系統。目前還沒有完成整套整合，文中的示範與接下來的構想會分開說明。
想讓不同角色共用規格以前，我先回頭看了 OpenSpec 原本怎麼讓團隊一起維護規格。OpenSpec 的團隊協作文件寫得很清楚：openspec/ 裡是普通的 Markdown，工具不會替我們建立 branch、commit、push 或 pull。規格、進行中的 changes 與 archive 都可以和 code 一起進 Git，再沿用團隊原本的 pull request 與 review 流程。
對平常就用 Git 協作的工程師來說，這是很熟悉的方式。一份 change 可以跟著同一條 branch 前進，reviewer 先看 proposal 與 delta spec，再確認 code 是否真的做到；合併後再把 change archive，正式 specs 也跟著 Git 歷史一起留下來。
如果規劃的範圍跨過好幾個 repos，寫這篇鐵人賽文章時，OpenSpec 也提供了 Stores Beta。它會把 planning 獨立成另一個 Git repo，仍然保留熟悉的 openspec/specs/ 與 openspec/changes/；不同 code repos 再指向這份 store，共用跨服務或跨團隊的規格。
不過，Stores 的分享方式仍然是 Git。每位成員要自行 clone、commit、push 與 pull，OpenSpec 不會在背景替大家同步，也不是一套放在 server 上、打開就能共同編輯的服務。我想嘗試的團隊使用方式，則是讓 PM／SA 能透過客製化系統查看規格、討論需求，由工程師繼續處理 repo 與實作。因此，除了規格保存在哪裡，我還需要考慮每個角色從哪裡進入、怎麼更新內容。
所以，我想讓規格直接進入團隊原本的系統，沿用既有的介面、帳號與權限。不過，要怎麼接進去，還得先看 Agent 是在使用者的本機，還是在團隊 server 裡執行。
前面使用 OpenSpec 時，我曾透過 Copilot SDK 操作 workflow。到了團隊的客製化系統，我考慮了兩種安排：目前使用 Pi Agent 的方向，是讓 Agent 在使用者的本機執行；另一種則是先前使用 Copilot SDK 時的 client／server 設計，把 Agent 放在團隊 server。
這是我的部署選擇： Copilot SDK 會透過 JSON-RPC 呼叫 Copilot CLI 的 server mode，但這個程序也能跑在本機，不代表一定需要遠端 server。這裡比較的是我怎麼安排系統，不是兩套 SDK 各自只能用在哪裡。
如果 Agent 在本機，透過 Speclink CLI 操作就很自然。需要實作時，可以處理本機的 code；規格如果保存在團隊系統裡，CLI 就透過 Remote 模式連線讀寫。Remote CLI 仍然是同一套 CLI，只是規格的讀寫位置從本機改成 server。
但如果 Agent 在團隊 server 執行，規格也存在同一套後端裡，就可以考慮不同的接法。若先啟動 Speclink CLI，再讓 CLI 透過 HTTP 呼叫這套系統自己的 Remote API，最後才讀寫規格，就會像下圖一樣繞出去又回來：
如果同一套後端能直接呼叫 Speclink Engine，我就希望讓 Agent 透過 Tool 使用它，省去這一圈。本機 Agent 則可以繼續使用 CLI，不需要為了共用規格而改掉原本的操作方式。
不論 Agent 最後放在哪裡，只要規格保存在團隊系統裡，我都得先確認：原本的 workflow 還能不能正常讀寫這些內容。因此，我先用熟悉的 CLI 接上 Remote，等這條路能正常運作，再處理 Agent 的整合。
如果一開始就把 Speclink 接進團隊系統，帳號、權限、資料庫和 Agent 都一起動，出了問題就很難知道是哪裡沒接好。
所以，我在遠端協作的規劃裡，決定先做一套 Demo server，讓它保存規格，並處理登入、權限與文件更新，再用原本熟悉的 CLI 連上去。先確認規格改放在 server 後，原本的 workflow 還能繼續使用，接著才把同樣的操作接進 Speclink Desktop。
下面就用這套 Demo server，看看規格不放在本機時，實際操作起來會是什麼樣子。
Speclink Desktop 目前已經可以在新增 Workspace 時，選擇本機資料夾或 Server：
選好已登入的 server 與 Project／Repo 後，接著可以決定要不要連接本機工作目錄。如果只是想查看或整理規格，可以直接選擇「略過（規格模式）」；需要把 Remote 規格和本機 code 放在一起使用時，再選擇對應的 Git working tree。
為了示範看板上的狀態，我請 Codex 在本機 Demo server 準備了一份示範用的 discussion，以及一份已經認領、完成 2／4 tasks 的 change。用規格模式開啟後，Speclink Desktop 一樣看得到兩邊目前走到哪裡：
點進 change 後，proposal、specs 與 tasks 也能直接從 server 讀取。下面這張圖裡沒有連接本機工作目錄，右側仍然可以打開完整 proposal：
Speclink Desktop 能打開這份 proposal，那麼回到工程師平常使用的 CLI，能不能讀到同一份內容呢？
我請 Codex 準備了一個沒有 openspec/ 的暫存 repo，裡面有 Git 與連線設定檔 .speclink.yaml，再連到同一個 Project／Repo，讀取剛才的 proposal：
兩邊讀到的是同一份 proposal。這樣，從介面查看規格，或回到 CLI 繼續操作，都不必另外複製一份文件。
前面的示範使用我準備的 Demo server，但團隊已經有自己的帳號、介面與資料庫。我希望接回去時，這些東西能繼續使用，也不用重新寫一套 Speclink workflow。
因此，列出 changes、建立 change、archive 這些操作，仍然交給同一套 Speclink Engine 處理。文件要從哪裡讀、更新後存到哪裡，則透過 Store 這層介面接到團隊的資料庫。Store 可以理解成 Engine 讀寫文件的方法，真正的內容仍然保存在檔案或資料庫裡。
把目前的示範與接下來想試的方向放在一起，大概會像下面這樣：
第一條就是前面截圖使用的組合。第二條則是讓 Speclink Desktop／CLI 改連團隊自己的後端，沿用既有的帳號與資料庫。
第三條，就是前面提到讓 server 裡的 Agent 透過 Tool 直接呼叫 Engine 的方向。目前 Speclink 已有 Node SDK 可以使用，但還需要把它接進團隊 Agent，確認每次操作使用誰的權限，以及對話時該怎麼取得與更新規格。後面這兩條路，都還需要繼續完成整合。
所以，目前先確認的是 Speclink 能提供哪些操作；真正接回團隊系統後，還得繼續確認大家實際使用時，這些安排是不是合適。
這次嘗試 Remote，讓我想的事情又多了一點。自己用 Speclink 時，我比較在意流程順不順；準備讓 PM／SA 也一起使用後，才發現還得考慮：大家從哪裡操作、談好的內容放在哪裡，以及工程師接手時能不能繼續用。
回頭看，剛接觸 SDD 時，我連每個指令該在什麼時候用，都還要邊查邊試。後來用得多了，才慢慢開始問：這一步為什麼要這樣安排？如果不適合我的工作方式，又可以怎麼改？
寫到這裡，也差不多該回來回答【Day - 1】留下的問題了：會跑 workflow，真的就等於懂 SDD 嗎？
最後一天，就來聊聊這一路用下來、也自己動手做過之後，我對 SDD 有了哪些不同的想法吧！
iThome鐵人賽
看影片追技術
看更多
