bcp-finish
真正工作的完成步驟。一個模型建構了它；另一個不同的模型攻擊它；操作員做出決定。基於建構者-挑戰者協議 v1.7 (https://github.com/heithmurray/builder-challenger-protocol，CC BY 4.0，Heith Murray)。
使用時機
- 執行時機： 在要求對任何超出快速變更範圍的工作進行完成核准之前。不要等到被要求才做。
- 跳過時機： 對於快速工作：顯而易見、微小且易於復原。專注的驗證已足夠。
- 每次執行只處理一個主題：你即將提交的變更。
角色
- 建構者： 你，執行工作的代理。你修復或回答每一個異議。
- 挑戰者： 一個不同的模型，以唯讀模式執行。它發現問題；它從不編輯檔案或編寫可交付的文字。
- 操作員： 擁有該工作的人類。只有操作員可以核准、接受風險、延長回合限制、發出事實覆寫或 REFRAME，或裁定範疇。你在建構者與挑戰者之間進行轉達，並且僅針對格式違規可以發出標準的
RESET — [指示]。
誰挑戰誰
- 挑戰者必須是與建構者不同的模型家族，以無頭模式在唯讀狀態下啟動。配對方式和確切命令在
references/tools.md中。 - 使用每個工具已配置的預設模型；不要自行挑選。
- 每次呼叫都是一個全新的會話，沒有共享的歷史記錄。每次都要提供完整的回合輸入（見交接）。
- 每次呼叫最多允許 10 分鐘。每回合通常需要 1 到 5 分鐘。
交接（挑戰者收到的內容）
每一輪，撰寫一個包含以下部分的提示，按順序排列：
references/challenger-prompt.md，完整檔案（角色、規則和格式）。ROUND [n] — BUILDER OUTPUT — v1.[n-1]。- 主題： 一句話說明此變更必須達成什麼，如果有的話請使用操作員的措辭，加上接受標準。
- 檢視位置： 儲存庫路徑、基礎和頭部提交、檢視差異的命令（例如
git diff <base>..<head>），以及相關的檔案。 - 建構者的證據： 你執行的驗證及其結果。
- 從第 2 回合開始：你的建構者回應（下方建構者回應格式）和挑戰者上一次的異議記錄表，逐字呈現。
沒有其他內容。不要附加評論，除了記錄表之外，不要包含先前的回合。
挑戰者可以讀取檔案並執行唯讀命令來證明其觀點。證據層級很重要：執行程式碼或數學計算優於引用來源，而引用來源又優於個人意見。
循環流程
回合限制為 5 輪，除非操作員在第 1 輪之前設定了其他數字。當達到限制而仍未 APPROVED 時，停止並詢問操作員。操作員可以延長一次，並附上理由：EXTEND — [目前回合] 到 [新限制]。原因：[仍然待完成的具體工作]。沒有第二次延長；再次達到限制即為死結。
-
第 1 輪： 發送交接內容。將挑戰者的回覆逐字儲存為第 1 輪。
-
裁決為 REVISE 或 FAIL： 使用建構者回應格式回覆：
- 對於裁決的回應。
- 已接受的異議（按 ID）：你更改了什麼。對於每一個：「異議 [ID] 是第 [X] 層級。我的修正更改了 [Y]。比例是適當的，因為 [Z]。」
- 已拒絕的異議（按 ID）：理由，附上同等或更高層級的證據。
- 弱異議挑戰。
- 假設回應。
- 已進行的修正。
- 剩餘的未解決問題。
進行修正並提交到分支。然後發送下一輪的交接內容。
-
會改變範疇、行為或設計的異議 不是你可以默默修復的。停止並將其作為一個決定事項提交給操作員，並附上挑戰者的完整文字。
- 你自己撰寫的規格或計畫不能解決範疇爭議。不要透過指向它來拒絕異議。只有操作員的言論或操作員核准的規格才算數。如果範疇是拒絕的唯一理由，則回報為「需要操作員範疇裁決」。
-
裁決為 PASS 只有在完成簽收檢查表且開放計數為零且最終裁決為 APPROVED 時才算數。否則視為 REVISE 處理。
-
達到回合限制而未 APPROVED： 停止並將開放的記錄表提交給操作員。如果操作員延長（一次），則繼續。否則，或在延長限制達到時，即為死結：要求挑戰者提供一段總結性的最終立場聲明，撰寫你自己的聲明，然後將兩者提交給操作員。
-
SELF-FAIL： 如果方法本身有缺陷，請說出三個必要部分：(a) 什麼地方有缺陷，(b) 為什麼需要挑戰才浮現，(c) 什麼樣的不同方法會有效。將其提交給操作員。
絕不編輯、修剪或淡化挑戰者的回覆。絕不聲稱異議已解決；只有挑戰者的記錄表可以將其標記為已解決。
記錄存放位置
- 如果工作有一個變更資料夾或任務記錄，請將各輪內容以
BCP-LEDGER.md的名稱儲存在那裡：依序儲存每個挑戰者回覆和每個建構者回應。 - 否則將它們儲存在儲存庫外部的臨時資料夾中，並在報告中包含最終的記錄表。
- 不要為此建立新的頂層資料夾。
向操作員報告（完成核准）
- 用於建構者和挑戰者的模型，以及回合數。
- 最終版本和挑戰者的最終裁決。
- 最終的異議記錄表，逐字呈現。
- 挑戰者的讓步及其未提出的風險自我審計，逐字呈現。
- 你的驗證證據。
- 你對請求中任何不明確之處所做的每一項解釋（例如「第 6–29 天不收費」），以便操作員可以確認或更正。
- 任何需要操作員決定的事項：死結、SELF-FAIL、範疇裁決、改變範疇的異議、需接受的風險。
- 然後詢問准許或否決。推送、合併和發布都要等待操作員的准許。
如果挑戰者無法執行
- 重試一次。如果模型錯誤提到不支援的模型，請回報；不要默默地切換模型。
- 如果另一個工具仍然不可用，請使用你自己工具的無頭唯讀命令作為挑戰者來執行相同的循環（見
references/tools.md）。這是一個全新的會話，沒有共享的上下文。 - 在報告中將整個結果標記為 SELF-CHALLENGE，並說明第二個模型為何不可用。自我挑戰會分享建構者的盲點，因此操作員應降低其權重。
- 絕不默默地跳過此步驟。