第一輪講的是使用者出門時，一組 Claude Code Session 怎麼重構 Clawdline。2026 年 10 月 18 日的第二輪不一樣：使用者回來了，小隊在做事的同時，使用者也一直拿著手機在用這個產品。
這讓工作變了樣。bug 會在重構做到一半時冒出來，來源是一張截圖、一句說明。小隊的進度沒有因此變慢，而且沒有任何一個修正，是只憑某個 Session 自己說了算就送到手機上的。
一張截圖變成待辦，待辦變成一個 Session
使用者在手機截圖上圈出問題、送出來，Clawdline 就把它掛到負責協調的 Session 上，成為一筆待辦。協調者先回到原始碼確認，把查證過的事實寫成 brief，再交給一個新的 Session 去修。
同一個下午，這件事發生了四次：
| 使用者看到的 | 實際的問題 |
|---|---|
| Plan 轉成工作後，多了一堆不是工作的步驟 | Plan 裡的分析被當成待辦清單解析 |
| child Session 有時沒有縮排在 root 底下 | 任務清單最久四分鐘才重讀一次 |
| 排程頁說在線的 Mac 離線了 | 頁面自己在重連，卻把這件事算成 Mac 離線 |
| 明明有 Session，卻說「沒有可用的 Session」 | 清單還沒載入，對話框就先畫了空清單 |
每個修正都從一個「在舊程式上會失敗」的測試開始。重構照常在旁邊進行，因為每個 Session 都在自己專用的 checkout 裡工作，互不干擾。
一次審查，擋下了比 bug 更糟的修正
縮排問題的第一版修正，測試全部通過。接著獨立審查者試著把它弄壞，結果真的弄壞了：root 的分頁關掉、新的 Session 又用到同一個終端機編號時，child 會被掛到錯的 Session 底下。
child 掛錯地方，比沒有縮排更糟，所以這個修正沒有合併。另一個 Session 接手這份審查、審查附上的探測測試和原本的分支，把三個問題都修好，再由第二位審查者逐一確認。上線後，協調者在有 child 執行的情況下看了十分鐘 daemon log：沒有任何一個 child 找不到 parent。
這種模式一整天都沒變：審查者自己設計會弄壞程式的改動，只要有一個沒被測試抓到，合併前就先補上測試。使用者不需要自己去讀 diff。
刪掉舊程式之前，先把它的答案錄下來
這一輪最大的改動，是把大約 2,600 行手寫的解碼程式，換成由一張表自動產生的程式。手機上的每一個操作都會經過這裡。
刪除任何東西之前，先有一個 Session 把舊程式對 142,267 種輸入的回答全部錄下來，新程式必須給出一模一樣的答案。之後審查者再把新舊兩版都送進真正的訊息橋接層，比對了 303,581 行輸出，每一個位元組都相同。
舊程式刪掉之後才寫的測試，只能描述新程式。先錄下來，舊的行為才能留下來當尺。
不用請使用者截圖，也能診斷手機
使用者也回報手機無法直連 Mac。從手機上問網路細節又慢又不可靠，所以小隊做了一個自己看得到的方法。
現在每一次直連嘗試，兩端各會留下一行紀錄，用同一個 id 對起來：各自提供了哪幾類網路候選、過濾掉幾個、連線檢查什麼時候開始，以及最後卡在哪一步。不寫任何位址、埠號或憑證。安全審查者試了十五種刻意設計的候選格式，想讓它洩漏，結果一個都沒有成功。
部署後不到一分鐘，第一批紀錄就進來了，而且已經看出一條線索：手機有提供 IPv6 候選，Mac 卻把自己的 IPv6 候選全部丟掉了。接下來的設計，會以選項的形式交給使用者決定，不會替使用者直接改掉。
工作可以來自別的 Session，範圍仍由使用者決定
另一個正在調查同一個連線問題的 Session，傳了一個看板項目給協調者，後來又請它多加一個修正，兩則訊息都說使用者已經同意。
協調者兩次都還是直接問了使用者，用的是手機上一個簡短的選項提問。別的 agent 傳來的訊息是資訊，不是授權。回答只花了幾秒，看板上的範圍就是使用者自己選的那一個。
小隊也遇到一件不是自己造成的事：另一個 Session 的 commit 讓主分支的 CI 變紅，推送被擋下。協調者先在本機重跑失敗的測試，再只重跑 CI 上失敗的那個 job，轉綠之後才推送。
第二輪多證明了什麼
第一輪證明了小隊做得了事，這一輪證明它禁得起打斷：從手機回報的新 bug，跟重構平行變成有人負責的工作；審查抓到測試漏掉的東西；刪程式之前先把行為釘住；使用者把時間花在做選擇，不用盯進度。
項目、步驟與待辦的操作在看板指南；派工、審查與落地的順序在工作流程指南；為什麼沒有 Session 能自己蓋「已落地」的章，可以讀「做完了」其實有四種意思。