Day 10 把 Workflow 與 Agent decision 分開之後，一個新的問題變得很明顯。

有些任務根本不是「還不知道怎麼做」。

相反地，前一輪已經完成：

需求收斂
→ 方案比較
→ 架構決定（Architecture）
→ 修改範圍確認（Scope）
→ 執行計畫（Execution Plan）
→ 人工核准（Human Approval）

接著換一個 Session、重新進入 Repository，Agent 卻又開始：

重新掃架構
→ 再提出另一個方案
→ 順手重排 execution order
→ 再問一次原本已經回答過的設計問題

這些動作看起來很認真。

但在已核准的工作上，它們未必提高品質，反而可能重新打開一個已經關閉的決策。

這也是我後來開始加入 計畫凍結（Plan Freeze） 的原因。

當一份計畫（Plan）已經被核准，後續 Agent 的預設任務應該是執行與驗證，而不是重新設計。

PROBLEM｜Agent 不知道「可以思考」和「可以改計畫」是兩回事

Coding Agent 很擅長找替代方案。

看到一個 implementation plan，它可能自然想到：

• 這裡是不是能再抽象一層；
• 這個檔案是不是應該一起重構；
• 既然都碰到了，要不要順便改另一條 flow；
• 原本的分層是不是還有更漂亮的做法。

如果任務還在探索期，這些能力很有價值。

問題出在：計畫已經通過 review 之後，Agent 仍把每個新 Session 當成新的 design session。

長任務尤其明顯。

我遇過的摩擦不是 Agent 完全忘記前文，而是長 Session 經過 compact，或換到下一個 Session 後，先前已否決的方案又被重新提出。Repository 狀態沒有要求重新設計，真正變動的是 Conversation 裡可見的 Context。

Session A 已經把需求與 architecture 收斂好；Session B 接手 implementation 時，只要看到另一種可能，就可能把「我想得到另一個方案」誤當成「我應該重新設計」。

原本已經縮小的問題，就這樣再次膨脹。

EVIDENCE｜我的 Workflow 裡，最浪費的不是寫錯 Code，而是重複打開已完成的決策

這類摩擦讓我開始把「決策有沒有做過」和「決策還能不能被重新打開」分開。

一個已收斂的流程通常已經走到：

Context 已建立
Decision 已記錄
Plan 已核准
Scope 已明確

下一輪 Agent 理論上只需要：

讀取核准 Plan
→ 確認前置條件仍成立
→ 執行
→ 驗證
→ 回報偏差

但如果沒有 Plan Freeze，流程很容易退回：

重新理解需求
→ 重新比較方案
→ 重新設計
→ 重新確認
→ 才開始執行

代價不只是在 Token。原本已否決的方案會再次出現，execution scope 可能被重新解釋，人也得再花一次注意力確認「為什麼又變了」。

Day 5 用 DECISIONS.md 解決的是：

不要讓下一個 Session 忘記「為什麼選這條路」。

Plan Freeze 再往前一步。

它處理的是：

既然這條路已經被核准，什麼情況下才有資格重新打開？

先講結論：Freeze 的不是思考能力，是 mutation of intent

Plan Freeze 很容易被誤解成：

不准 Agent 思考。

這不是我要的。

Agent 執行時仍然需要判斷：

• 某個 API 實際位置和 Plan 假設不同；
• 測試揭露了新的 dependency；
• Repository 在交接期間已經變動；
• 原本的步驟無法成立；
• 新證據顯示原 Plan 可能不安全。

這些都必須思考。

需要 Freeze 的其實是另一件事：

Approved Intent
Approved Architecture
Approved Scope
Approved Execution Boundary

也就是：

可以發現問題，但不能把「發現問題」自動升級成「自行改寫已核准方案」。

MODEL｜把 Plan 拆成「可執行區」與「重新核准區」

我現在比較傾向把核准後的 Plan 看成一份 execution contract。

它至少包含四層：

Plan Freeze 如果寫成「所有步驟一字不准改」，會太僵硬；真實 Repository 不可能完全照預測前進。

比較合理的是：

Goal / Architecture / Scope
        ↓
      Freeze
        ↓
Execution details
        ↓
允許 bounded adaptation

例如原 Plan 說：

修改 A
→ targeted test
→ 更新 B
→ regression

實作時發現 test command 的實際名稱不同，Agent 可以自行修正 command。

但如果它發現另一套 architecture 看起來更漂亮，不應直接把 A / B 整條方案換掉。

那已超出 execution detail，等於修改 approved intent。

CHANGE｜我會要求 Agent 遇到偏差時先「停在差異」，不要直接跳到新方案

Plan Freeze 最有用的一條規則，不是「照 Plan 做」。

而是偏差處理。

我會把行為壓成：

Plan says X
Repo / Test shows Y
        ↓
描述 mismatch
        ↓
判斷是否仍能在 approved boundary 內處理
        ↓
YES → bounded adaptation + evidence
NO  → stop / escalate / request re-approval

這個差別看似很小，卻把 Agent 的預設動作從：

有問題
→ 我來重新設計

改成：

有問題
→ 先證明哪個前提失效

重新設計因此變成 exception，而不是每個 Session 的預設行為。

一份最小 Plan Freeze Contract

如果不想先做複雜 Harness，其實一小段規則就能開始。

例如：

PLAN STATUS: APPROVED / FROZEN

You may:
- implement the approved plan
- make local execution adjustments that do not change goal, architecture, or scope
- run the agreed verification
- report newly discovered evidence

You must not:
- redesign the approved architecture
- expand scope because adjacent work looks useful
- revive rejected alternatives without new evidence
- reinterpret approval as permission for unrelated mutation

If a frozen assumption is invalid:
1. identify the exact mismatch
2. show evidence
3. explain impact
4. stop before changing the approved plan

這比單純寫一句「請照計畫執行」多了一個重要定義：什麼情況算偏離計畫。

工作模式也因此可以明確分成：

DESIGN MODE
→ explore / compare / challenge

EXECUTION MODE
→ implement / verify / escalate exception

Plan Freeze 也需要 Exit Condition

Freeze 不是永久鎖死。

如果新的 Evidence 足以推翻原本假設，Plan 當然可以重新打開。

我通常會接受幾類訊號：

Repository state 已經改變
Plan 依賴的前提不存在
targeted test 證明方案不可行
出現新的 security / data / migration risk
核准範圍與實際 implementation 無法一致

但這些訊號的共同點是：

有新的 Evidence。

而不是：

Agent 想到另一個更漂亮的做法。

沒有這條線，Plan Freeze 會變成僵化流程；沒有 Freeze，execution 又容易退回 architecture workshop。

Human Gate 不一定要很重

我最近把一個公開的 Agent Governance Bootstrap 做成兩階段時，也刻意採用相同概念。

第一階段只允許：

Repository Discovery
→ Governance Gap Analysis
→ Proposal

在人工批准以前，不進入後面的 implementation。

這裡的價值，在於讓 Workflow 明確知道：

proposal != authority to mutate

同樣地：

approved plan != authority to redesign

兩者都在限制同一件事：分析能力可以很強，但 mutation authority 必須由目前階段決定。

公開的 bootstrap 實作放在：

https://github.com/henryfir456/agent-governance-bootstrap

BOUNDARY｜什麼時候不該 Freeze？

不是每個任務都值得建立正式 Plan Freeze。

例如：

• 一次性的小修正；
• 只有單一檔案、沒有 architecture choice；
• 幾分鐘內就能完成並驗證；
• 任務仍處於探索期；
• 使用者明確要求 Agent 自主比較並選擇方案。

這些情況硬加 freeze，成本可能高於風險。

Plan Freeze 比較適合：

跨 Session
+
已有 review / approval
+
方案改動成本高
+
scope drift 會造成實際風險

也就是說，它更像一個狀態轉換，而不是「大型專案一定要有的文件」：

Explore
→ Decide
→ Approve
→ Freeze
→ Execute
→ Verify

如果工作根本沒有經過 Decide / Approve，Freeze 也沒有東西可以凍結。

VERIFY｜怎麼知道 Plan Freeze 有沒有發揮作用？

Plan Freeze 不應該只靠感覺。我會看四個直接訊號：

1. 下一個 Session 是否仍會重開已決定的 architecture？
2. 發現 mismatch 時，Agent 是先提供 Evidence，還是直接改方案？
3. 核准後的 scope 是否保持穩定？
4. 人工重新 review 是否仍被無效 redesign 反覆觸發？

理想狀態是讓偏差變得可分類：

execution adjustment
or
plan invalidation

前者可以繼續。

後者才需要重新進入 design / approval。

Day 11 留下的一條規則

已核准的判斷，不應該只因為換了一個 Session 就自動失效。

Plan Freeze 不限制 Agent 分析新 Evidence；它限制的是「沒有新 Evidence 就重新設計」。一旦 frozen assumption 被證明失效，再回到 design / approval。

Freeze 固定的是已核准 intent，不是整個 Repository。下一層問題因此變成：Agent 看得到很多東西時，這次究竟被授權改到哪裡？