Day 11 的計畫凍結（Plan Freeze）解決了一個問題：

已經核准的方案，不要因為換 Session 就重新設計。

但它只固定了 intent。

開始 implementation 後，還有另一種 drift：方案沒有被重寫，實際修改範圍卻一路長出去。

這種範圍漂移（Scope Drift）往往不是 Agent 明顯做錯，而是相鄰工作看起來「順手一起做比較完整」：

• 看見旁邊有相似邏輯，想一起抽共用 function；
• 發現舊命名或 warning，順手整理；
• 為了讓測試或架構更漂亮，把 refactor surface 擴大。

單看每一項，都可能是合理修改；問題在於它們是否屬於這一輪的授權。

我在 agent-platform 做 Product Intent Guardrail 時，就碰到很具體的邊界。那一輪只需要修改兩個 shared skills、README，再補一個 read-only contract test。過程中也確認到 consumer template 有 version drift，而且未來確實需要同步 consumer repositories。

但那份 plan 仍明確把這些事情留在本輪之外：

ALLOWED
- 更新既有 preflight / verification contract
- 補對應 contract test
- 更新 overview documentation

NON-GOAL
- 同步 consumer repositories
- 順手修 template version drift
- 新增 runtime approval service / queue / persistent state

不是因為後面那些工作沒有價值，而是因為它們沒有被這次需求授權。這個例子後來直接落進 ap-safe-preflight：implementation 前先記錄 product intent、minimum design、non-goals，以及超出 minimum 的 complexity；completion 時再由 ap-verification-core 檢查實際交付是否出現 scope drift。

有界修改範圍（Bounded Scope）的作用，是把「Agent 看得到什麼」和「Agent 這次可以改什麼」拆開。

為什麼「只修這個 Bug」不算 Scope

最早很容易寫成：

只修這個 bug。
不要動其他地方。

問題是，這句對 Agent 幾乎沒有可執行的邊界。

為了找 root cause，它本來就可能需要讀很多東西：

Repository
Tests
Logs
Config
History

「不能碰其他地方」如果被解讀成不能看，就會讓 Agent 只能局部猜測。

但如果解讀成「看到了就都能改」，任務又會開始膨脹。

需要拆開的是：

讀取範圍（Read Scope）
用來理解問題

修改範圍（Mutation Scope）
這一輪被授權改變的範圍

理解系統可以很廣，改變系統應該更窄。

Scope 拆成三塊後，Read 與 Mutation 才不會混在一起

實作上可以先留下三個區域：

ALLOWED
這次允許改變的行為或責任

VERIFY-ONLY
需要讀、需要追、需要驗證
但沒有新 Evidence 前不修改

NON-GOAL
即使發現可以改善，本輪也不處理

例如一個 bounded change 可能長成：

ALLOWED
- 修正指定行為
- 補直接對應的 targeted test

VERIFY-ONLY
- 上下游 contract
- 相鄰 module
- persistence / config
- 既有 regression evidence

NON-GOAL
- architecture redesign
- schema migration
- unrelated cleanup
- 順手修相似 issue

這裡重要的不是三個英文標籤。

而是把「需要理解」和「獲得修改權」切開。

Agent 可以沿著 dependency 一路查到 root cause，卻不會因為多讀了幾個檔案，就自然取得那些檔案的 mutation authority。

一份可執行的 Scope Contract，至少要讓 Agent 回答五件事

只列「允許改哪些檔案」通常還不夠。

檔案是 implementation surface，不一定等於責任邊界。root cause 真的跨出原本預期檔案時，過度僵硬的 file allowlist 反而可能逼出 workaround。

我現在比較希望 Scope Contract 至少長成：

INTENT
這次要改變哪個 observable behavior？

ALLOWED
哪些行為／責任可以被修改？

VERIFY-ONLY
哪些 dependency 必須讀、Trace、Test，
但沒有新 Evidence 前不修改？

NON-GOAL
哪些相鄰改善即使被看見，本輪也不做？

EXPANSION TRIGGER
出現什麼 Evidence 時，
才有資格重新討論 mutation boundary？

套回前面的 Product Intent Guardrail，那一輪的重點不是「只能碰四個檔案」。

更精確的是：

Intent
把 minimum design / non-goals / complexity approval
變成既有 shared governance contract

Allowed
修改既有 preflight / verification responsibilities
補 contract test 與 overview

Verify-only
consumer template 是否已出現 version drift

Non-goal
consumer rollout
template synchronization
runtime approval service

Expansion trigger
只有新的 correctness / security / data-integrity evidence
證明原 boundary 無法完成已核准 intent
才重新提案

這種寫法比「只改 A、B、C」多一個保護：Agent 可以繼續追 root cause，但越過 mutation boundary 前，必須先說明哪個原假設被 Evidence 推翻。

Scope Contract 因此不是 file lock，而是一份 mutation contract：把理解範圍、修改授權與重新開 boundary 的條件分開。

Scope Drift 為什麼值得前後各檢查一次

只在 Prompt 開頭寫 Scope 還不夠。

因為 implementation 本身會產生新的資訊。

shared governance 後來因此出現兩個不同時點：

Before implementation
ap-safe-preflight
→ intent / minimum / non-goals

After implementation
ap-verification-core
→ changed surface / scope-drift classification

前者回答：

這輪本來允許做什麼？

後者回答：

實際改完後，有沒有偷偷變成另一個任務？

這個前後夾住的設計，是因為 Scope Drift 有時並不是一開始就能看見。

Agent 可能在第二、第三個檔案才發現「順便整理一下會更漂亮」。

如果只有開工前的規則，最後仍可能得到一份超出原風險模型的 diff。

「需要擴大 Scope」本身應該成為事件

Bounded Scope 不是永遠禁止擴大。

原本的判斷真的可能不夠。

例如：

原本以為 A 是 root cause
↓
新的 Test / Trace 顯示 B 才是實際 contract 問題
↓
原 mutation boundary 不足

這時正確做法不是硬守 A，也不是 Agent 靜默把 B 一起改掉。

而是：

原 Scope 不足
↓
提出新 Evidence
↓
說明哪個前提失效
↓
提出需要新增的 mutation boundary
↓
重新確認
↓
再繼續

重點不是讓 Scope 永遠不變。

而是讓它改變時留下明確事件：

Scope 可以改，但不能靜默漂移。

這是 Bounded Scope 和「把 Agent 綁死」最大的差別。

VERIFY-ONLY 是最容易被低估的一層

只有 ALLOWED / FORBIDDEN，容易走向兩個極端：Scope 太小，Agent 看不到完整證據；讀得夠廣，又把理解範圍誤當修改範圍。

VERIFY-ONLY 保留中間層：

可以讀 / Trace / Test
可以證明問題不在這裡
但沒有新 Evidence 前，不取得修改權

它保留 debugging 能力，又不把 debugging 自動轉成 refactoring authority。

Bounded Scope 不是越小越好

Scope 設得太死，也會出問題。

如果已經有 Evidence 證明 root cause 跨兩層，卻硬要求「只能改其中一層」，Agent 最後可能做出一個很漂亮的 workaround，把真正的 contract 問題蓋住。

比較準確的判斷不是：

Scope 越小越安全。

而是：

Scope 應該小到足以控制風險，又大到能完整修掉已被 Evidence 證明的 root cause。

Bounded 的不是思考範圍。

Bounded 的是這一輪的 mutation authority。

從 Context 走到 Authority

Day 3–9 主要在處理：

Agent 現在知道什麼？

Day 10–11 開始處理 workflow 與 approved intent。

到了 Day 12，問題正式往另一層移動：

Context
它知道什麼？

Authority
它這次可以改什麼？

這也是為什麼 ap-safe-preflight 和 completion-time scope-drift check 最後會同時存在。

一個 Agent 能讀完整 Repository、理解 dependency、找到更多改善機會，都不等於那些改善自動進入這次工作。

能力越大，授權邊界反而越需要被寫清楚。

下一步問題會更具體。

即使兩個任務都有自己的 mutation boundary，只要它們還共用同一個 working tree，彼此仍然可能踩到。

那已經不是 Scope 定義問題，而是 Workspace Isolation 的問題。