merttcetn/pev-loop

PEV 循環

圍繞一個持續目標執行無狀態的規劃者-執行者-驗證者循環。將主要代理作為一個輕量級控制器：維護標準狀態、調度隔離的角色、執行限制，並報告結果，但不參與產品本身的規劃、實施或評分。

不可協商的保證

• 需要明確的 $pev 呼叫。將該呼叫視為授權，以創建或重用匹配的原生目標，並調度 P、E 和 V 子代理。
• 讓控制器遠離產品工作。不要在主要上下文中檢查原始碼主體、實施變更、解讀原始測試日誌或決定評分量規的滿意度。
• 每個 P、E 和 V 代理都必須以全新的上下文啟動。使用 fork_turns="none" 或執行環境中最強的等效設定。
• 絕不讓任何代理評分自己的工作。
• 向驗證者隱藏規劃者和執行者的推理過程、摘要以及預期結果。
• 只允許驗證者的證據改變評分量規的滿意度。
• 所有運行狀態儲存在一個唯一命名的 OS 暫存目錄中。絕不在儲存庫、工作區、家目錄或技能目錄下建立運行狀態。
• 運行結束時，保留確切的暫存目錄。不要將其中的內容暫存、提交、推送、發佈或複製到專案的可持久化檔案中。
• 將 PEV 機制排除在產品評分量規之外。透過控制器的機械式稽核來強制執行迭代限制、模型路由、角色隔離和僅限暫存的狀態。
• 不要為了獲得通過而刪除、跳過、削弱或改寫現有的測試。僅當使用者目標要求時才允許合法的測試變更，然後讓驗證者仔細審查它們。
• 絕不繞過最終的完整評分量規驗證。

解析呼叫

接受 $pev 之後的一個目標以及以下可選控制項：

• max=N 或 --max N：允許 1..10；預設為 6。
• using=$skill-name：在每個相關的角色中獨立載入指定的技能。在評分量規中使用其要求，要求執行者遵循它，並要求驗證者獨立評估它。

如果呼叫省略了目標，則讀取活躍的原生目標。如果兩者都不存在，則要求提供目標並停止。

當原生目標工具可用時：

1. 在創建目標之前先讀取當前目標。
2. 僅當活躍目標與請求的目標相符時才重複使用它。
3. 當沒有目標時創建一個。除非使用者明確提供了代幣預算，否則不要設定預算。
4. 如果存在一個不同的未完成目標，則停止並要求使用者先解決該目標，而不是取代它。

當原生目標工具不可用時，繼續作為有界限的 PEV 運行，並說明自動延續功能不可用。

啟動暫存狀態

執行：

python3 <skill-directory>/scripts/init_run.py --max-iterations <N>

將返回的絕對路徑 run_dir 記錄在執行緒中，並將其明確傳遞給每個子代理。在第一次調度之前，請閱讀 references/contracts.md。

使用確切的目標和限制填充 goal.json。調度一個全新的規範規劃者來創建不可變的完成定義。要求每個評分量規項目：

• 從不滿意狀態開始；
• 描述一個可觀察的結果，而非一項活動；
• 指明可接受的證據；
• 保留使用者和儲存庫的限制；且
• 可獨立驗證。

將內部的 PEV 機制（例如迭代次數、代理選擇、上下文隔離、暫存路徑和控制器簿記）從產品評分量規中排除。當使用者要求限制結果時，保留使用者可見的工作區不變量，例如“不要提交”、“不要推送”或“不要修改測試”。

在控制器的機械式架構閘之後凍結 rubric.json。僅將可變的滿意度和證據儲存在 progress.json 中。

控制器擁有所有狀態檔案。P、E 和 V 代理必須返回緊湊的 JSON 回應，並且不得修改暫存狀態。

執行循環

對於從 1 到 max_iterations 的每次迭代，按順序執行以下階段。

1. 調度一個全新的規劃者

啟動一個全新的唯讀 Sol 規劃者。只賦予它：

• 工作區路徑；
• goal.json、rubric.json 和 progress.json；
• 如果存在，前一個驗證者的判決；
• 迭代次數和剩餘預算；以及
• 明確請求的 using= 技能。

允許規劃者檢查產品和儲存庫說明。不要賦予它之前的規劃者或執行者推理過程。

要求一個符合合約的有界限 task_packet。僅當沒有可用的有用工作單元時，才允許 DONE_CANDIDATE；切勿將其視為完成的證明。

機械式拒絕滿足以下條件的計劃：

• 未解決任何不滿意的評分量規項目；
• 遺漏了範圍、限制或驗證目標；
• 在沒有回應驗證者證據的情況下重複失敗的工作單元；
• 請求削弱測試或未經授權的破壞性動作；或
• 無法容納在一個執行者指派內。

對於高風險的安全性、遷移、權限、財務或不可逆轉的工作，請在執行之前插入一個全新的唯讀計劃審查者。賦予它目標、評分量規和任務包，但不包含規劃者的推理過程。

在接受任務包後，將其寫入 plan.json，然後再調度執行者。不要將控制器狀態的更新延遲到驗證之後。

2. 調度一個全新的執行者

啟動一個全新的 Sol 工作者，只擁有任務包中檔案的擁有權和責任。告知它程式碼庫中可能存在其他工作，並且它必須保留不相關的變更。

賦予它：

• 確切的任務包；
• 工作區路徑和適用的儲存庫說明；
• 避免範圍偏移所需的原始限制；以及
• 明確請求的 using= 技能。

不要賦予它驗證者的權威。要求它實施一個有意義的工作單元，執行相稱的檢查，並僅返回執行者收據。不要讓它更新評分量規或暫存狀態。

防止驗證和建置命令在目標工作區中遺留偶然的快取、日誌、覆蓋率輸出或其他非產品工件。當支援時，將可丟棄的輸出路由到一個獨立創建的 OS 暫存位置。否則，僅移除由該指派創建且來源確定的確切可丟棄工件；切勿刪除預先存在或路徑不明確的內容。

當執行環境支援模型覆蓋時，按以下方式路由推理努力：

• 機械式、範圍狹窄的執行：gpt-5.6-sol 搭配 low；
• 一般實施：gpt-5.6-sol 搭配 medium；
• 跨領域或高風險實施：gpt-5.6-sol 搭配 high。

除非目標明確要求，否則不要提交或推送。

3. 調度一個全新的盲目驗證者

啟動一個全新的唯讀 Sol 驗證者，使用 high 推理；對於關鍵安全性、遷移、權限或不可逆轉的工作，使用 xhigh。

只賦予它：

• 確切的原始目標和凍結的評分量規；
• 工作區或產生的工件；
• 適用的儲存庫說明；
• 使用者強制的驗證命令；以及
• 明確請求的 using= 技能。

不要賦予它控制器的運行目錄、任務包、規劃者輸出、執行者收據、實施摘要、預期結果、先前的判決理由或 P/E 對話歷史。如果驗證者的工具需要可丟棄的輸出，請為其提供一個單獨的 OS 暫存目錄。

要求驗證者獨立檢查當前產品、執行相關檢查、檢查測試變更是否存在獎勵駭客行為，並返回判決合約。驗證者不得修改產品、測試、運行狀態或外部系統。

4. 更新標準狀態

讓控制器驗證回應格式、將完整回應寫入迭代的判決檔案，並在下一次調度之前將驗證者支持的狀態和證據複製到 progress.json 中。不要將薄弱的證據重新解釋為通過。

• 對於 NEEDS_WORK，使用新的規劃者啟動下一次迭代。
• 對於 PASS，調度一個額外的最終驗證者，不提供先前的滿意狀態。要求其從頭開始評估每個評分量規項目。
• 對於最終的 PASS，執行控制器的機械式稽核，檢查角色隔離、迭代次數、僅限暫存的狀態和授權邊界。僅在兩個閘都通過時，才將原生目標標記為完成。
• 對於最終失敗，如果仍有剩餘迭代次數，則繼續。

停止條件

僅在全新的最終驗證者證明每個評分量規項目後，才成功停止。

將產品驗證和編排完整性視為兩個獨立的閘：

• 產品閘： 一個全新的盲目最終驗證者證明了凍結的評分量規。
• 控制器閘： 可機器檢查的記錄證明了迭代限制、新角色調度、僅限暫存的狀態，以及沒有未經授權的提交、推送、發佈、部署或破壞性動作。

不要將控制器的簿記失敗發送給產品驗證者，也不要將其轉變為產品評分量規項目。在可能的情況下立即修復安全的簿記；否則，報告控制器閘的失敗，且不主張完成。

在達到迭代限制時：

• 不主張成功；
• 不要僅僅因為達到限制就將目標標記為完成或受阻；
• 報告已滿足的項目、剩餘的項目、決定性的證據以及確切的暫存路徑；以及
• 保持目標活躍，以便明確的延續。

僅在執行環境的重複封鎖閾值真正滿足時，才將目標標記為受阻。當授權、重大的產品決策、缺少憑證或不可用的外部依賴項阻礙安全進展時，暫停以等待使用者輸入。

恢復

如果暫存目錄消失，請建立一個新的，並從活躍的執行緒目標和對話中重建目標和凍結的評分量規。將所有先前的滿意度視為未證明，然後在繼續之前運行一個全新的完整驗證者。

如果子代理失敗：

• 在相同隔離邊界內，對至關重要的 P、E 或 V 角色重試一次；
• 絕不以控制器判斷取代遺失的驗證者判決；
• 透過新的規劃者縮小過大的工作單元；
• 保留工作區中不相關的變更；以及
• 當迭代限制阻止恢復時，誠實地報告差距。

最終品質閘

在返回成功之前，請確認：

• 主要代理僅作為控制器行事；
• 每個角色都使用了全新的隔離上下文；
• 沒有代理評分自己的輸出；
• 驗證者沒有看到 P/E 的推理過程或預期結果；
• 每個評分量規項目都有來自最終驗證者的當前、直接證據；
• 現有測試未被削弱以製造成功；
• 工作流程所創建的偶然命令工件不會留在目標工作區中；
• 運行狀態僅存在於記錄的 OS 暫存目錄下；
• 沒有運行狀態被提交或複製到專案中；以及
• 原生目標（如果可用）僅在最終 PASS 後才被標記為完成。