Fleet brief
平行代理者會在共享地雷上失敗——兩個工作線編輯同一個檔案。這份簡報的目的就是在調度前讓這種衝突不可能發生。請根據實際的檔案對映來推導邊界，切勿假設。
按此順序建構簡報
1. 先對映檔案
在定義工作線之前，列出每個提案變更會觸及的檔案。讀取它們。未讀取檔案就定義的工作線，是等待發生的衝突。
2. 指定獨佔所有權
每個檔案恰好有一個擁有它的工作線。產出這個表格：
| 工作線 | 擁有（寫入） | 僅讀取 |
|---|---|---|
| W1 — <名稱> | path/a.ts, path/b.ts | path/shared.ts |
如果兩個工作線需要寫入同一個檔案，你有三個選項——明確選定其中一個，切勿留下模糊空間：
- 排序它們（W2 等待 W1 合併）
- 合併它們成一個工作線
- 接合它：一個工作線新增擴充點，另一個消費它
3. 命名共享地雷
列出每個被超過一個工作線讀取的檔案，並說明誰可以寫入它。
根據你面前的程式碼庫推導此清單——不要搬移另一個專案的清單過來。值得檢查的常見模式：
- 即時入站路徑。 接收網頁鉤子或使用者流量的任何東西。這裡的並行編輯會在生產環境失敗，而非測試環境。
- 引擎與調度器模組，多個功能會呼叫它們。
- 僅附加的清單——部署配置、路由表、函式列表。平台會施加限制（函式數量、檔案大小）；兩個工作線獨立附加可能會突破其中一個。
- 廣泛匯出的匯出。 附加性地擴展；重新命名會波及每個呼叫者。
- 產生或供應的檔案，任何工作線都不應手動編輯。
一個曾造成衝突的檔案將永久視為共享地雷。將其記錄在簡報中，以便下一個 fleet 繼承此知識。
4. 推導出禁止事項清單
每個禁止事項指定一個檔案或行為以及原因。沒有理由的禁令會被忽略；有根據的才能成立。
跨多數程式碼庫適用的項目：
- 在衝突解決期間絕對不要執行
git add -A——它會暫存衝突標記與其他工作線的成果。 - 工作者不應在連結的工作樹中提交；由協調者提交。
- 如果測試套件全域模擬資料庫，則通過的單元測試對資料庫完全沒有證明力。明確說出這一點。
- 未附上一行理由之前，不要新增相依套件。
- 不要從工作線內部執行資料庫架構遷移。將其延後到一個經審查的步驟。
- 注意會靜默失敗的 CLI 呼叫——例如
gh pr create需要明確的--base，而鏈結的 heredoc 可能吞掉錯誤。
然後加入專案特定的禁止事項。每個曾經讓你熬夜的事故都應該在這裡，附上原因。
5. 設定閘道
為每個工作線明確說明：「完成」的定義、哪些證據可以證明、以及合併前由誰審查。
值得保留的預設是上線前審查——建置、然後獨立逐行審查、然後必須修正的回合、然後合併。絕不能僅憑工作線作者自己的說法就合併。作者的代理者是自己差異的最差審查者。
6. 標記保留事項
一個「刻意未完成——需要人類介入」章節。為明確的目標而保留的項目，是刻意保留的。不要讓工作線因為看起來準備就緒就執行其中任何一個。
隔離
在 git 工作樹中執行建置，而非主要檢出目錄——共享一個工作目錄的 fleet 會交錯編輯。如果工作線儘管有對映仍變更重疊的檔案，請為每個工作線提供各自的工作樹。
規模
工作線應該可以獨立合併。如果一個工作線無法在沒有另一個工作線的 PR 的情況下合併，它就不是工作線——它是階段。對階段進行排序；對工作線進行平行化。
輸出
將簡報寫到專案存放計劃的任何位置，並用「驗證，切勿假設」的警告來開啟它。任何來源文件中的狀態行都是檢查點，而非權威——在據以調度之前，請重新檢查即時提交、資料庫狀態、PR 檢查以及工作樹的首部。