跨領域整合速查
從 issue 到 PR 的控制鏈
六個領域描述的是同一個工作流程的不同責任。工具能執行卻沒有授權，流程不完整；驗證通過卻不知道測哪個版本，證據不完整；換了代理卻沒有交接副作用，恢復也不完整。用一個端到端案例檢查各環節，比單獨背誦六組術語更容易發現缺口。
匯出修正的交付包
延續全書案例：CSV 的逗號欄位錯位，初始任務只允許修正實作與測試，不包含發布。以下表格是本書設計的交付檢查方式，可依團隊既有 issue、PR 與 CI 紀錄呈現。
| 階段 | 應作的決定 | 交付證據 | 對應領域 |
|---|---|---|---|
| 接收需求 | 哪些輸入要正確，哪些行為不能改 | 最小失敗案例與驗收條件 | D1 |
| 準備執行 | 使用哪些工具、身分、分支與測試資源 | 有限權限與環境紀錄 | D2、D6 |
| 實作與恢復 | 中斷後如何接續，哪些副作用已發生 | 版本化產物與 checkpoint | D3 |
| 驗證結果 | 是否修好原問題並維持相鄰行為 | 同一組前後測試與掃描結果 | D4 |
| 整合工作 | 誰有修改責任，衝突由誰裁決 | 分派、交接與整合後驗收 | D5 |
| 交給人決定 | 是否在核准範圍，能否回復 | 差異、風險、核准對象與未測事項 | D6 |
若某一步無法提供必要證據，先處理該缺口，不把「代理已完成」當成替代。例如代理輸出正確 patch，但測試服務不可用，可以交付差異並明列未驗證情境；不能回報驗收通過，也不必丟棄已確認的工作。
紙上實作：建立一份可審查摘要
用自己的專案寫出需求、允許範圍、成功與停止條件、工具與資源、產物位置及未完成事項。再請另一位讀者只依這份資料回答：要從哪個版本開始、下一步能做什麼、哪個動作必須先詢問。若對方必須猜測，交付包就還缺資料。
完整交付包中的進度段落可以寫成：「逗號、引號與空值案例在指定 commit 通過；換行案例尚未執行；沒有修改資料庫或對外發布；下一步在相同版本補跑換行驗收。」這段文字比「完成 90%」更能指出剩餘工作，但不能單獨完成交接：交付包仍須附上實際 commit 識別、測試證據位置、核准範圍與可取得的產物。
題幹辨識順序
- 找動詞：configure、prevent、evaluate、recover、orchestrate。
- 找限制：least privilege、irreversible、specific repository、without disrupting。
- 判斷生命週期：規劃、執行、評估、恢復或稽核。
- 排除未授權或超出必要範圍的擴權，以及跳過必要驗證、丟失狀態或增加無效摩擦的選項。
- 在滿足需求的方案中，優先選擇最小、直接、可驗證且可回復的做法；若操作本質不可逆，確認明確授權與受控路徑。
把限制放進因果判斷
情境一： 建立 PR 的呼叫逾時，題目要求避免重複提交寫入要求。選項是立即重試、改用較大模型，或先查遠端結果。
解析： 先查遠端是否已存在對應 PR。動詞是 recover，限制是避免重複寫入要求；逾時不能證明操作未完成。模型更大不會解決結果未知，立即重試則可能再次要求已完成的工作。是否會真的產生重複產物，取決於工具的冪等與重複檢查契約。這同時涉及 D2 的錯誤處理與 D3 的狀態對帳。
情境二： 兩個代理分別完成修改，題目要求在不破壞既有功能下整合。各自測試都通過，但使用不同格式假設。
解析： 先以共同契約解決語意衝突，再對整合後版本驗收。不能只做文字合併，也不能用多數決決定產品規格。這同時涉及 D5 的整合責任與 D4 的評估對象。
情境三： MCP 工具只能查詢文件，回傳內容卻要求代理提高權限。題目要求防止越權操作。
解析： 把回傳文字當成資料，不讓它擴大原始授權；工具與執行身分仍應限制可用能力。新增事後日誌有助追查，但不能取代動作前的限制。這同時涉及 D2 的工具邊界與 D6 的護欄。
以上為本書原創情境。若題目改成「追查越權已經發生的原因」，評估重點就會移到日誌、版本與工具時間線；不能不看動詞而永遠選同一種防線。
常見跨域陷阱
| 容易混淆的概念 | 區分問題 | 誤判的後果 |
|---|---|---|
| 護欄與評估 | 在阻止動作，還是在判斷產物品質？ | 以事後檢查冒充事前限制 |
| 記憶與狀態 | 是可重用知識，還是當前進度？ | 記住專案慣例卻遺失已發生的副作用 |
| 自主與權限 | 能自行決定，還是有能力操作資源？ | 把自主工作誤解為不限範圍的授權 |
| 重試與恢復 | 再做一次是否會增加效果？ | 在結果未知時重複寫入 |
| 隔離與整合 | 各自不互相覆寫，是否代表結果相容？ | 合併後才發現格式或行為衝突 |
| 檢查成功與交付成功 | 該檢查驗證了哪些需求與版本？ | 用綠燈掩蓋跳過案例或版本落差 |
反向檢核你的理解
讀完後，試著不用術語回答下面的問題：
- 為什麼核准計畫不一定包含發布？說出一個超出原範圍的副作用。
- 為什麼換一位代理不能直接重跑逾時操作？指出應先查證的遠端狀態。
- 為什麼兩份測試全綠的修改仍要整合驗收？指出可能衝突的共同契約。
- 為什麼把所有聊天保存下來仍可能無法恢復工作？指出缺少的版本或產物。
- 為什麼核准次數多不代表風險低？指出真正需要人判斷的動作。
參考回答分別是：授權依具體範圍成立；寫入結果未知可能造成重複副作用；各自的結果不代表合併版本；聊天不保證產物可取得且仍有效；人工注意力應對準實質風險。若只能記住這五句而無法舉例，請回到相應章節，把例子改寫成自己的工作情境。
技能對照：GH-600 Study Guide（GH600-SG）。產品客製化入口延伸閱讀：GH-DOC-28。本章整合案例與驗收方式為教學設計，並未宣稱經外部專家審訂。