Day 12 把問題從「Agent 看得到什麼」推進到「Agent 這次有權改什麼」。

我原本以為，只要兩個任務都有自己的有界修改範圍（Bounded Scope），就足以安全地平行工作。

實際把規劃、實作、Review、驗證等 Session 交錯進行後，問題很快出現：Scope 限制了「哪些地方可以改」的 修改授權（mutation authority），卻沒有隔離「修改中的工作狀態」這層 修改狀態（mutation state）。

兩個任務只要共用同一個工作目錄（working tree），就可能讀到對方尚未完成的檔案、暫時設定與未提交狀態（dirty state）。這時多開 Agent 並不會消除問題，反而可能讓更多工作同時讀到這份中間狀態，甚至拿它來做判斷。

平行工作的第一個問題，是工作狀態有沒有被隔離。

Scope 分開了，filesystem 還是可能混在一起

假設 Task A 正在調整驗證流程，Task B 同時修改另一個功能：

Task A ─┐
        ├─ same working tree
Task B ─┘

Task B 跑測試時，看到的不一定只有自己的變更。它也可能看到：

• Task A 尚未完成的檔案；
• 還沒 commit 的設定；
• 暫時為 debug 修改的內容；
• 原本就存在、但不屬於兩個任務的 dirty changes。

此時測試失敗，很難立刻判斷是 B 做錯，還是 A 的中間狀態造成；測試 PASS 也未必只證明 B 自己成立。

問題不在模型是否夠聰明，而在這份 working state 沒有清楚歸屬：到底是 Task A 的、Task B 的，還是原本就存在的工作。

工作樹（Worktree）把任務邊界變成狀態邊界

Git worktree 對這個流程的價值，不只是可以同時開多個視窗，而是把尚未完成的 mutation 分開：

Repository history
        │
        ├── Worktree A
        │      └── Task A dirty state
        │
        └── Worktree B
               └── Task B dirty state

A、B 仍共享同一份 Git history，但不再共享同一份工作中狀態。

這樣可以把 Day 12 與 Day 13 的責任拆清楚：

Bounded Scope
→ 這次可以改什麼

Worktree Isolation
→ 這次正在改的狀態放在哪裡

沒有 isolation 時，即使 Agent 知道某些檔案不屬於自己的 Scope，它仍會實際看見其他工作的中間狀態。

這個邊界後來長進了 agent-platform

這個做法後來不只停在操作習慣，也進入我的 shared-skill lifecycle。

這套流程同時涉及兩個 Repository：

canonical agent-platform
+
consumer repository

執行前會產生一份 preflight evidence，記錄 canonical / consumer HEAD、目前與預期變更路徑、risk flags，以及 target collision 狀態。

其中有一條刻意設得很硬：

preflight evidence 不能放在 canonical 或 consumer 任一 Git worktree 裡。

new-shared-skill-preflight-evidence.ps1 會解析兩邊的 Git root，再檢查 OutputPath。如果 evidence 落進任一 worktree，直接 fail closed：

evidence OutputPath must be outside both Git worktrees

lifecycle implementation plan 也把同一條件寫成執行契約：

Evidence must resolve outside both Git worktrees
and must not be staged or committed.

理由很單純：用來描述兩份工作狀態的 evidence，不應自己成為其中一份工作狀態。

Isolation 到這裡已經不是習慣，而是能被 deterministic tooling 驗證的 invariant。

Mutation-capable 測試也不碰真實 Repository

同一套 lifecycle executor 還需要測：

• stale HEAD 是否在 mutation 前被擋下；
• evidence 放進任一 worktree 是否失敗；
• tag collision 是否 fail closed；
• partial failure 是否保留可恢復狀態。

這些測試會建立 commit、tag、dirty state。直接拿實際 canonical repo 與 consumer repo 驗證，等於為了測治理工具，主動增加新的污染來源。

negative-path verification 因而改用 disposable Git fixtures：

TEMP
├── fake canonical repo
└── fake consumer repo

implementation plan 明確要求：

verify valid lifecycle on isolated temporary Git fixtures without touching Bento production code

這個案例讓 state isolation 的邊界更清楚：它不是保證錯誤不會發生，而是讓錯誤先發生在不會污染其他工作的地方。

Shared Context 不等於 Shared Working Tree

Session 之間仍然可以共享：

• 已核准 Plan；
• Repository facts；
• Handoff；
• issue / decision；
• verification evidence。

但共享 Context 不需要共享 mutation state。

Shared context
     │
     ├── Session A → Worktree A
     │
     └── Session B → Worktree B

「讓下一個 Agent 知道前一個 Agent 做過什麼」，和「讓下一個 Agent 直接踩在前一個 Agent 尚未完成的 filesystem 上」，是兩種不同的耦合。

前者需要的是 context continuity；後者會形成 mutation coupling。

多 Agent 不能替代 state isolation

三個 Agent 若共用同一個 working tree，mutation state 仍只有一份；反過來，一個 Agent 依序處理兩個 worktree，也能讓中間狀態分離。

因此我把四個維度分開看：

Task count
Worktree count
Dependency count
Agent count

平行工作是 execution topology；Multi-Agent 是 responsibility topology。問題若只是 workspace collision，增加 Agent 只會更早引入 coordination、handoff、token 與 integration cost。

Worktree 也不能消滅 dependency

Isolation 能切開 working state，卻不會消除共用 contract、底層模組與 branch ordering。

例如 A、B 都從同一個 HEAD 分出去：

HEAD-0
├── A → 修改 shared contract
└── B → 依賴舊 contract 完成功能

A 的 worktree 不會污染 B；但 A 先 merge 後，B 原本驗證過的假設仍可能過期。

Worktree 能證明的是：

B 的測試沒有被 A 尚未完成的 dirty state 偷偷污染。

它不能證明 B 永遠不需要重新整合 A 已完成的變更。

我用三層判斷平行工作

最後這件事被我拆成三層：

1. Authority Isolation
   這個 Task 被允許改什麼？

2. State Isolation
   這個 Task 的中間 mutation 放在哪裡？

3. Dependency Coordination
   任務完成後如何重新整合？

Day 12 的 Bounded Scope 解第一層；Day 13 的 Worktree 解第二層。

很多看似需要 Multi-Agent architecture 的問題，到這一步仍只是 workspace state 沒切乾淨。

什麼情況值得建立 isolated worktree

Isolation 也有成本：多一份 branch / HEAD 狀態、dependency setup、test environment、cleanup responsibility 與 integration work。

我會優先用在：

• 任務會修改多個檔案；
• 會持續跨一段 Session；
• 主 working tree 已有其他未完成工作；
• 兩個 mutation-capable task 需要交錯進行；
• 各自能先獨立驗證；
• 需要保留清楚的 changed-file / test / handoff evidence。

若只是 read-only review、分析、單一小修改，或很快能序列完成的工作，建立 worktree 可能比直接做完更重。

判斷點不是「能不能隔離」，而是：

mutation overlap 的風險，是否高於 isolation cost？

Single Agent First 不等於 Single Workspace

Single Agent First 限制的是過早增加協調複雜度，不是要求所有工作擠在同一個 workspace。許多平行需求先靠 Task decomposition、Bounded Scope、Worktree isolation 與 Explicit handoff 就能處理。

只有單 Agent 排程已成為 wall-clock bottleneck、任務確實可獨立平行，而且 integration cost 小於收益時，才值得升級成 Multi-Agent。

先增加 isolation，再評估是否需要增加 Agent。

隔離之後，才輪到 collision 判斷

Day 12 回答「這次有權改什麼」；Day 13 再補上「被授權修改的中間狀態放在哪裡」。

但 Agent 還是可能進入已經有變更的 working tree，而 dirty 本身不等於錯。它可能是使用者的工作、另一個 Session 留下的合法變更，也可能真的與本次任務 collision。

先把能隔離的 mutation state 分開後，剩下的問題才值得精確判斷：

看到既有變更時，怎麼分辨它可以保留、可以避開，還是必須停止？