執行一個由 bead 或呼叫者意圖所描述的有限 RED 到 GREEN 實驗；回傳衍生的 subject 身分並檢查事實。觸發詞：「implement」、「implement this bead」、「run the experiment」。完整的計畫到驗證請求會路由到 rpi。
Implement
執行由已解析的 bead 或呼叫者意圖所描述的確切一個有限實驗。Implement 負責 subject 的編輯與事實證據。它不會建立第二個計畫記錄或模型撰寫的候選封包。
工作流程
- 從其現有來源讀取意圖、驗收與範圍。執行環境可以自動對該來源進行快照與雜湊，以偵測漂移。
- 在變更行為之前，先執行宣告的第一個驗收檢查。RED-first 僅在驗收是行為性時適用：保留檢查因預期的缺失行為而失敗的證據。搬移、文件合併與純重構不需要失敗檢查的儀式——反而記錄一個誠實的變更前綠色基準。
- 做出滿足目前行為的最小範圍內變更。
- 執行目標驗收檢查並擷取事實結果。
- 僅在這些檢查保持綠色時重構。重構不會變更驗收測試。
- 讓執行環境從 before/after subject 推導實際變更的路徑與
subject-manifest.v1。不要讓模型轉錄這些事實。 - 在回應或執行通道中回傳 manifest digest、作者 context ID 與精確的檢查收據。停止。
專家如 standards、domain、test、refactor 與 security 可以提供建議。它們永遠不是硬性依賴，也不能增加生命週期權限。
證據比例原則
在編輯期間，執行能反駁目前變更的最小確定性檢查。當 subject 與工具身分仍然相符時，重用精確輸入收據。在整合邊界執行昂貴的完整套件檢查，或僅在意圖明確將其設為第一個驗收檢查時提前執行。在每次聚焦編輯後重複重播完整套件只會增加延遲，而非證明。
範圍衝突規則
當發現變更的即時消費者位於宣告的寫入範圍之外——例如斷言舊路徑的測試、產生的孿生、讀取搬移檔案的閘道——停止並向呼叫者回報確切的檔案與行號。不要靜默擴展範圍以吸收它，或從 Implement 修訂意圖。呼叫者可以修訂來源意圖並啟動單獨的呼叫。
在宣告 GREEN 之前，自我審查 diff 中的 mock、佔位符、TODO 存根、硬編碼的 fixture 值、弱化的斷言、重新產生的 golden、放寬的容差、抑制指令，或取代真實行為的規格編輯。當 diff 變更測試、閘道、fixture、golden 或驗收來源時，說明原始意圖為何需要該變更，並確認綠色來自實作的行為，而非弱化的 oracle。通過替代或弱化 oracle 的檢查不是驗收準則的證據；要么完成行為，要么回報為未建置。
邊界
- 不要提交、推送、宣稱、關閉、發布、落地、保留、重試，或呼叫語意驗證器。
- 不要靜默擴展驗收。不同的驗收契約是新的意圖，應由呼叫者另行啟動。
- 失敗的檢查是給呼叫者的證據，不是建立封包或驗證迴圈的許可。
