feat(zh-tw): Stage B Gemini review 套用片語級在地化（47 patches）

Gemini 3.1 Pro 掃描全 57 個 zh-tw 檔，找出 OpenCC 漏掉的台灣慣用詞 50 條。
Maki review 後分流：

Applied (44 條，直接套用)：
- 幹活 → 做事 / 工作 / 執行任務
- 倉庫 → 專案、手搓 → 實作
- 流水線 → 管線、鏈路 → 路徑、槽位 → 插槽
- 落盤/寫盤 → 寫入磁碟 / 存檔
- 郵箱 → 信箱、收件箱 → 收件匣
- 報錯 → 錯誤訊息、粘 → 貼、貼上回 → 貼回
- 控制面 → 控制平面、收口 → 收尾
- 路子 → 方式、騰空間 → 騰出空間
- 構建 → 建構、章 → 章節、理清 → 釐清

Modified (3 條，Maki override)：
- 對話框 → 對話視窗（非 Gemini 的「對話框」）
- 拖放 → 拖曳（非 Gemini 的「拖放」）
- 「水管工→工程師」patch 拆解：保留水管工 + 程式設計師，只採「意淫→幻想」

Rejected (3 條)：
- 線上 → 在線（反向錯誤，台灣是「線上」）
- 相容分支 → 相容分支（no-op）
- 提示詞水管工式 → 提示詞工程師式（保留原作 plumber 比喻）

未套用 (4 條 errors)：因前一條 patch 已改字串造成 unique-match 失敗，
不重要——前 patch 已涵蓋等價修改。

Pipeline：briefing → gemini --approval-mode auto_edit → JSON patches
        → Python apply (unique-match check) → git diff review → commit
Evidence: ~/Documents/agent-council/2026-05-21-zh-tw-stageB/

Author: MakiDevelop

README-zh-tw.md

@@ -6,7 +6,7 @@
 
 在討論程式碼之前，先把一件事說清楚。
 
-**Agency -- 感知、推理、行動的能力 -- 來自模型訓練，不是來自外部程式碼的編排。** 但一個能幹活的 agent 產品，需要模型和 harness 缺一不可。模型是駕駛者，harness 是載具。本倉庫教你造載具。
+**Agency -- 感知、推理、行動的能力 -- 來自模型訓練，不是來自外部程式碼的編排。** 但一個能做事的 agent 產品，需要模型和 harness 缺一不可。模型是駕駛者，harness 是載具。本專案教你打造載具。
 
 ### Agency 從哪來
 
@@ -32,11 +32,11 @@ Agent 的核心是一個神經網路 -- Transformer、RNN、一個被訓練出
 
 "Agent" 這個詞已經被一整個提示詞水管工產業劫持了。
 
-拖拽式工作流構建器。無程式碼 "AI Agent" 平臺。提示詞鏈編排庫。它們共享同一個幻覺：把 LLM API 呼叫用 if-else 分支、節點圖、硬編碼路由邏輯串在一起就算是 "構建 Agent" 了。
+拖曳式工作流建構器。無程式碼 "AI Agent" 平台。提示詞鏈編排庫。它們共享同一個幻覺：把 LLM API 呼叫用 if-else 分支、節點圖、硬編碼路由邏輯串在一起就算是 "構建 Agent" 了。
 
 不是的。它們做出來的東西是魯布·戈德堡機械 -- 一個過度工程化的、脆弱的過程式規則流水線，LLM 被楔在裡面當一個美化了的文字補全節點。那不是 Agent。那是一個有著宏大妄想的 shell 指令碼。
 
-**提示詞水管工式 "Agent" 是不做模型的程式設計師的意淫。** 他們試圖透過堆疊過程式邏輯來暴力模擬智慧 -- 龐大的規則樹、節點圖、鏈式提示詞瀑布流 -- 然後祈禱足夠多的膠水程式碼能湧現出自主行為。不會的。你不可能透過工程手段編碼出 agency。Agency 是學出來的，不是編出來的。
+**提示詞水管工式 "Agent" 是不做模型的程式設計師的幻想。** 他們試圖透過堆疊過程式邏輯來暴力模擬智慧 -- 龐大的規則樹、節點圖、鏈式提示詞瀑布流 -- 然後祈禱足夠多的膠水程式碼能湧現出自主行為。不會的。你不可能透過工程手段編碼出 agency。Agency 是學出來的，不是編出來的。
 
 那些系統從誕生之日起就已經死了：脆弱、不可擴充套件、根本不具備泛化能力。它們是 GOFAI（Good Old-Fashioned AI，經典符號 AI）的現代還魂 -- 幾十年前就被學界拋棄的符號規則系統，現在噴了一層 LLM 的漆又登場了。換了個包裝，同一條死路。
 
@@ -172,7 +172,7 @@ Claude Code = 一個 agent loop
 >
 > **s05**   *"沒有計劃的 agent 走哪算哪"* — 先列步驟再動手, 完成率翻倍
 >
-> **s06**   *"大任務拆小, 每個小任務乾淨的上下文"* — 子 Agent 自己幹活，只把結果帶回來
+> **s06**   *"大任務拆小, 每個小任務乾淨的上下文"* — 子 Agent 自己執行任務，只把結果帶回來
 >
 > **s07**   *"用到時再載入, 別全塞 prompt 裡"* — 技能先列目錄，用到時再展開
 >
@@ -182,7 +182,7 @@ Claude Code = 一個 agent loop
 >
 > **s10**   *"prompt 是組裝出來的, 不是寫死的"* — 分段 + 按需拼接
 >
-> **s11**   *"錯誤不是終點, 是重試的起點"* — 出錯時會重試、騰空間、換路子
+> **s11**   *"錯誤不是終點, 是重試的起點"* — 出錯時會重試、騰出空間、換個方式
 >
 > **s12**   *"大目標拆成小任務, 排好序, 持久化"* — 檔案持久化的任務圖, 多 agent 協作的基礎
 >

docs/zh-tw/data-structures.md

@@ -23,7 +23,7 @@
 
 ### 原則 2：區分“持久狀態”和“執行時狀態”
 
-- task、memory、schedule 這類狀態，通常會落盤，跨會話存在。
+- task、memory、schedule 這類狀態，通常會寫入磁碟，跨會話存在。
 - runtime task、當前 permission decision、當前 MCP connection 這類狀態，通常只在系統執行時活著。
 
 ## 1. 查詢與對話控制狀態
@@ -225,7 +225,7 @@ transition = {
 
 - 日誌更清楚
 - 測試更清楚
-- 恢復鏈路更清楚
+- 恢復路徑更清楚
 
 相關章節：
 
@@ -556,7 +556,7 @@ runtime_task = {
 這和 `TaskRecord` 不是一回事：
 
 - `TaskRecord` 管工作目標
-- `RuntimeTaskState` 管當前執行槽位
+- `RuntimeTaskState` 管當前執行插槽
 
 相關章節：
 

docs/zh-tw/entity-map.md

@@ -68,7 +68,7 @@
 | 實體 | 它是什麼 | 它不是什麼 |
 |---|---|---|
 | `work-graph task` | 任務板上的工作節點 | 不是系統裡活著的執行單元 |
-| `runtime task` | 當前正在執行的後臺/agent/monitor 槽位 | 不是依賴圖節點 |
+| `runtime task` | 當前正在執行的後臺/agent/monitor 插槽 | 不是依賴圖節點 |
 
 這對概念是整個倉庫後半程最關鍵的區分之一。
 

docs/zh-tw/glossary.md

@@ -410,7 +410,7 @@ pending -> expired
 這個詞第一次看到容易怕。  
 但在本倉庫裡，你只需要把它先記成：
 
-> 不直接幹活，負責協調怎麼幹活的一層。
+> 不直接做事，負責協調怎麼做事的一層。
 
 ## Capability
 

docs/zh-tw/s00-architecture-overview.md

@@ -143,7 +143,7 @@
 
 ### 階段 1：核心單 agent (`s01-s06`)
 
-目標：先做出一個能幹活的 agent。
+目標：先做出一個能做事的 agent。
 
 | 章節 | 學什麼 | 解決什麼問題 |
 |---|---|---|

docs/zh-tw/s00a-query-control-plane.md

@@ -311,7 +311,7 @@ query loop
 - 每次 `continue` 都應該有明確原因，而不是黑盒跳轉
 - 訊息層、工具回寫、壓縮恢復、重試恢復，最終都要回到同一份 query 狀態上
 
-更細的 `transition taxonomy`、預算跟蹤、prefetch 等擴充套件，可以放到你把這條最小控制面真正手搓穩定以後再補。
+更細的 `transition taxonomy`、預算跟蹤、prefetch 等擴充套件，可以放到你把這條最小控制面真正實作穩定以後再補。
 
 ## 一句話記住
 

docs/zh-tw/s00d-chapter-order-rationale.md

@@ -251,7 +251,7 @@ Hook 是在問：
 
 - 對前面所有輸入、執行、狀態、許可權、壓縮分支的總回收
 
-它天然適合做“控制面階段的收口章”。
+它天然適合做「控制平面階段的收尾章節」。
 
 只有當讀者已經知道：
 
@@ -363,7 +363,7 @@ Hook 是在問：
 
 因為在平臺層裡，worktree 是執行隔離邊界，MCP 是能力邊界。
 
-對開發者自己手搓系統來說，更應先搞清：
+對開發者自己實作系統來說，更應先搞清：
 
 - 多個執行者如何不互相踩目錄
 - 一個任務與一個執行車道如何繫結

docs/zh-tw/s00e-reference-module-map.md

@@ -66,7 +66,7 @@
 | 許可權閘門 | `types/permissions.ts`、`hooks/toolPermission/*`、審批處理器 | `s07` | 執行安全是明確閘門，不是“某個 hook 順手乾的事”，所以必須早於 hook。 |
 | Hook 與側邊擴充套件 | `types/hooks.ts`、hook runner、生命週期接線 | `s08` | 參考倉庫把擴充套件點和許可權分開。教學順序保持“先 gate，再 extend”是對的。 |
 | 持久記憶選擇 | `memdir/*`、`services/SessionMemory/*`、記憶提取與篩選 | `s09` | 參考倉庫把 memory 處理成“跨會話、選擇性裝配”的層，不是通用筆記本。 |
-| Prompt 組裝 | `constants/prompts.ts`、prompt sections、memory prompt 注入 | `s10`、`s10a` | 參考倉庫明顯把輸入拆成多個 section。教學版把 prompt 講成流水線，而不是一段大字串，是正確的。 |
+| Prompt 組裝 | `constants/prompts.ts`、prompt sections、memory prompt 注入 | `s10`、`s10a` | 參考倉庫明顯把輸入拆成多個 section。教學版把 prompt 講成管線，而不是一段大字串，是正確的。 |
 | 恢復與續行 | query transition、retry 分支、compact retry、token recovery | `s11`、`s00c` | 真實系統裡“為什麼繼續下一輪”是顯式存在的，所以恢復應當晚於 loop / tools / compact / permissions / memory / prompt。 |
 | 持久工作圖 | 任務記錄、任務板、依賴解鎖 | `s12` | 當前教程把“持久任務目標”和“會話內待辦”分開，是對的。 |
 | 活著的執行時任務 | `tasks/types.ts`、`LocalShellTask`、`LocalAgentTask`、`RemoteAgentTask`、`MonitorMcpTask` | `s13`、`s13a` | 參考倉庫裡 runtime task 是明確的聯合型別，這強烈證明 `TaskRecord` 和 `RuntimeTaskState` 必須分開教。 |

docs/zh-tw/s01-the-agent-loop.md

@@ -8,7 +8,7 @@
 
 ## 問題
 
-語言模型能推理程式碼, 但碰不到真實世界 -- 不能讀檔案、跑測試、看報錯。沒有迴圈, 每次工具呼叫你都得手動把結果粘回去。你自己就是那個迴圈。
+語言模型能推理程式碼, 但碰不到真實世界 -- 不能讀檔案、跑測試、看錯誤訊息。沒有迴圈, 每次工具呼叫你都得手動把結果貼回去。你自己就是那個迴圈。
 
 ## 解決方案
 

docs/zh-tw/s02b-tool-execution-runtime.md

@@ -321,7 +321,7 @@ handlers[tool_name](tool_input)
 - 共享 context 的修改最好先排隊，再按穩定順序統一合併
 
 只要這三條邊界已經清楚，後面的許可權、後臺任務和 MCP 接入就都有地方掛。  
-更細的佇列模型、取消策略、流式輸出協議，都可以放到你把這條最小執行時自己手搓出來以後再補。
+更細的佇列模型、取消策略、流式輸出協議，都可以放到你把這條最小執行時自己實作出來以後再補。
 
 ## 讀完這一篇你應該能說清楚