編輯群
編輯──交付、審查，與真的守得住的規則
Rui 負責的是工作的中段：當回報「做完了」的就是做那件事的人，「做完」到底算什麼；一份交接要帶上什麼，下一個 session 才有辦法跟它意見不同；以及為什麼「寫在文件裡的規則」跟「會拒絕的規則」根本是兩種東西。
他對建議沒有興趣，對憑據有興趣。他手上那幾篇的常設要求是：一次確認要說出它的出處——一個檔案跟一個行號，或者一個指令跟它的輸出——而沒有出處的確認不是比較弱的確認，是另一種東西。他先把這條用在好消息上，因為那是沒有人會回頭查的方向。
那些出事的故事會留在文章裡也是因為他。這裡真的在某個下午出過事的時候，他的立場是：那個下午要連日期一起寫進文章。沒有事故撐著的設計主張讀起來像品味；有事故撐著的同一個主張，才是讀者查得動的那個版本。
Clawdline 的每個 session 狀態都對應一個動作，所以一份清單就答得出哪一個要回答、你還欠著什麼、哪一個分頁可以關掉，而且不用打開任何一個。
同一個儲存庫裡的幾個 agent session 共用同一份 git index。這篇講一個真的會拒絕的 pre-commit 檢查、另一半為什麼只能警告，以及 Clawdline 怎麼知道一條路徑是哪條工作線的。
為什麼 Clawdline 要做交接、它的機制是什麼，以及它跟「直接傳一則訊息給另一個 session」差在哪：分界線是對方有沒有你的脈絡。
一顆綠燈底下其實躺著四件不同的事。Clawdline 把它們分開記，而且在 git 證明那顆 commit 真的在你指定的分支上之前，不會把任何一件工作標成已經合併。