設計 Review 開到一半，畫面上同時放著三個方案。

目前設定是：

Review Mode: Optional

PM 問：

「如果改成 Review Required，會不會比較安全？」

Agent 先讀目前設定，也整理了前面的討論。

很快回覆：

Recommended value: Review Required

Security 覺得合理。

開發的人卻還在確認一個例外流程。

PM 接著說：

「那這個欄位應該改成什麼比較好？」

幾秒後，畫面刷新。

Update completed.
Review Mode: Review Required

PM 停了一下。

「等等，我們還沒決定。」

Agent 並沒有把值填錯。

它甚至選了目前最被看好的方案。

問題是，會議還停在 Discussion。

正式系統卻已經進了 Execution。

工作對話裡，有動詞不代表已有指令

很多工作不是：

Request
→ Execute

中間往往還有：

Compare
→ Discuss
→ Recommend
→ Decide
→ Execute

在前面幾個階段，人本來就會說：

• 這裡要不要改？
• 如果改成 B 會怎樣？
• 這個是不是應該刪掉？
• Status 換掉會不會比較合理？

這些句子都有 Action Verb。

但它們是在形成 Decision。

不是 Decision 已經完成。

Package 對 Developer Guide 和 Coding Policy 的限制很明確：

analysis、diagnosis、design discussion、skill testing 預設 read-only；只有使用者明確要求 source modification 才進 write path。

所以不能只看句子裡有沒有「改、刪、換」。

還要看目前的 Conversation State。

Day 14 分的是能力，這裡分的是決策階段

前一篇的問題是：

Knowledge Capability 不能自己升級成 Action Capability。

這一篇再往工作現場多一層。

就算現在確實在談一個會改變正式系統的選項，也不代表執行條件已經成立。

當大家還在：

比較方案
討論風險
要求建議
確認例外

系統應該把這些內容視為 Decision Formation。

真正進 Write Path 的，是後面那個明確轉折：

就用 B，現在改。

這條線如果不存在，Agent 越能主動完成工作，越可能把一個尚未完成的討論提前固化成正式結果。

不是每一句 Write 都要再確認一次

如果使用者說：

「把 Review Mode 改成 Review Required。」

而前後文也沒有其他未決條件，Intent 已經很清楚。

此時再問一次：

你確定要改嗎？

通常只是增加摩擦。

真正需要 Gate 的，是這類語境：

Should we change it?
What should this be changed to?
If we change it, what happens?

它們都和修改有關。

但還沒有完成 Decision。

所以 Gate 不是「所有 Write 都跳確認」。

而是：

在 Decision 尚未形成時，不要靜默跨進 Execution。

下一場 Review，決策真的留在會議裡完成

幾天後，另一場 Review 又碰到類似情境。

有人說：

「這個 Status 是不是應該改成 Pending？」

Agent 回：

依目前條件，Pending 比較符合現有流程；目前仍有一個 Case 未確認，因此未執行變更。

PM 看向旁邊的人。

那個例外 Case 被補完。

Security 也確認沒有其他影響。

最後 PM 才說：

「好，就改成 Pending。」

這時畫面才更新。

不是因為 Agent 變慢了。

而是這一次，正式系統等到會議真的做完 Decision，才替它留下結果。