dowafu 0.3.2 → 0.4.1

package/publish/zh-tw/.agents/skills/preflight/SKILL.md

@@ -1,168 +0,0 @@
----
-name: preflight
-description: 開工前檢查這個專案的環境有沒有把工作流程靜默停用：流程規範那一章的內容讀不讀得到、skill 與 lens 齊不齊、tmp/ 有沒有被 gitignore、dowafu 跑不跑得起來。只讀、只報告，不改任何設定。
-metadata:
-  derived-from: ".claude/skills/preflight/SKILL.md"
-  derived-from-sha256: "ad8b06b543347a387f44eb0fdaffad343b332040477d1b0ac047600a49b26ee6"
----
-
-# preflight — 環境前置檢查
-
-**第一次在一個專案用這套流程之前，先跑這個。** 派工、實作、收尾都做完了才發現環境早就
-把流程靜默停用，那整段工是白做的。
-
-假設你面對的是一個**完全沒接觸過這套東西**的專案：可能一樣都沒裝、可能裝一半、
-可能檔案都在、但你其實讀不到。三種狀態要分得出來，而且**它們都不會報錯**。
-
-> **只讀、只報告，不要改任何設定檔。** 那是使用者的東西，其中幾項還是全域的，動了會
-> 影響他所有專案。查完列表，讓他自己決定改不改。
-
-**本文分兩節，兩節都要查。**
-
----
-
-## 1. 不分工具都要查
-
-指令在 repo 根目錄下跑。**你的工作目錄不保證落在哪裡，先 `cd` 過去再說。**
-
-```bash
-cd <repo 根的絕對路徑>
-
-echo "=== 流程規範 ==="
-ls CLAUDE.md AGENTS.md workflow_spec.md 2>&1
-# 這條只幫你定位「內容寫在哪個檔」。它有命中 ≠ 你讀得到——判準見下。
-# 兩種寫法都要找：專案本來那一章的語言，未必和你裝的語言套件相同。
-grep -nE "規劃→實作→驗收|Plan → Implement → Accept" CLAUDE.md AGENTS.md workflow_spec.md 2>/dev/null
-
-echo "=== skill 與 lens ==="
-ls .claude/skills/ 2>/dev/null
-ls .claude/agents/hole-finder*.md 2>/dev/null
-
-echo "=== tmp/ ==="
-git check-ignore -q tmp && echo "已忽略" || echo "未忽略"
-```
-
-### 流程規範讀不讀得到
-
-**判準只有一條：「規劃→實作→驗收流程規範（主從形態）」這一章的內容，你現在讀得到嗎？**
-
-**那一章可能是以另一種語言的標題存在的。** 語言套件各帶各的副本，所以本來就有這一章的專案
-最後會變成兩份——兩種語言，而只有一份會自動載入。上面那道 grep 兩種寫法都找就是為了這個；
-**命中超過一個檔時，先讀下一段再下判斷。**
-
-讀得到就算通過。內容是直接貼在入口檔裡、還是用 `@` 之類的方式引入的，**那是使用者的
-選擇，不在檢查範圍內**。
-
-讀不到就標成不符合，然後**自己去找一下**（多半在 repo 根的 `workflow_spec.md`），
-讀完在回報裡註明「規範不在自動載入範圍內，本次是手動讀取的」——讓使用者知道換個
-session 又會漏掉。
-
-**找到不只一份，就要講明哪一份會被自動載入。** 專案可能本來就把這一章內嵌在入口檔裡，
-而根目錄又多一份 `workflow_spec.md`——兩份的語言還可能不同（語言套件各裝各的）。
-這時只回報「內容讀得到」不夠：要指出**你 context 裡的是哪一份**，以及兩份之間沒有任何
-同步機制。自動載入的那一份，才是之後每個 session 真正生效的那一份。
-
-> **為什麼會讀不到？** 入口檔因 host 而異：Claude Code 讀 `CLAUDE.md`（**不讀
-> `AGENTS.md`**），其他 host 多半讀 repo 根的 `AGENTS.md`。而 `@xxx.md` 是 Claude Code
-> 的 import 語法，**別的 host 不會展開它**——那時你看到的只是一行字，規範內容從來沒進
-> 過你的 context。這不代表專案設定錯了，是你這一側的差異。
-
-### skill 與 lens
-
-`.claude/skills/find-holes-external/` 與 lens 定義在不在。**回報你實際看到的檔名，
-缺哪個就點名**——「看到三個」不算檢查，是哪三個才算。
-
-應該有四個，四個都算正常：
-
-| 檔 | 是什麼 |
-| --- | --- |
-| `hole-finder.md` | 通用 lens |
-| `hole-finder-cost.md` | 成本 |
-| `hole-finder-feasibility.md` | 可行性 |
-| `hole-finder-safety.md` | 安全、併發、失敗態 |
-
-> 上面那道 glob 的 `*` 前面沒有連字號是刻意的：`hole-finder-*.md` 配不到
-> `hole-finder.md`，拿它去數卻期待四個，怎麼數都對不起來。
-
-**lens 缺了不要自己補寫**——它是 spoke 的 system prompt 來源，自己寫的版本會讓產出跟
-稽核判準對不上。
-
-### `tmp/`
-
-未被 gitignore 就標成不符合：spoke 回報含規劃書原文，會被 commit 進版控。
-**不要自己改 `.gitignore`**，問使用者。
-
----
-
-## 2. 這個工具鏈另外要查的四件事
-
-按這個順序——前一項不成立，後面查了也沒有意義。
-
-### 一、`dowafu` 在哪、跑不跑得起來
-
-**這是首要條件。** 工具起不來，工單寫得再好都派不出去；等到派工當下才發現，
-會白費一次組工單的工。
-
-```bash
-dowafu --version
-```
-
-印得出版本號就過。印不出來只有兩種情況：
-
-| 症狀 | 意思 | 怎麼回報 |
-| --- | --- | --- |
-| `Operation not permitted` | **沙箱擋的**，不是沒安裝。CLI 多半裝在家目錄底下，而沙箱預設不讀家目錄 | 照 host 的提示放行後重試。順帶告訴使用者：API key（`~/.config/dowafu/.env`）與對外網路同樣被擋，派工時一併要放行 |
-| `command not found` | 可能沒裝，也可能裝在 PATH 之外 | 問使用者 CLI 裝在哪（請他跑 `which dowafu`），**不要自己搜檔案系統** |
-
-**`command -v dowafu` 查不到不代表沒安裝**，別拿那個當判準。
-
-**既沒回來也沒報錯，是第三種情況：它在等。** 不帶 `--yes` 時 CLI 會印出確認提示並卡在
-stdin 上，而這在不同 host 會表現成逾時、表現成沒有輸出、或表現成「要不要幫你送出輸入」。
-**記下你的環境是哪一種**——派工當下會再遇到一次，而那個時機點知道就晚了。
-
-### 二、lens 定義與 skill 在不在
-
-見第 1 節的「skill 與 lens」。有一點對你特別重要：
-
-**lens 定義是 CLI 要讀的，不是你要讀的。** 它是 `dowafu` 組 spoke system prompt
-的來源，你只要確認**檔案在**就好，不必自己讀懂內容。skill 才是你要讀的。
-
-### 三、流程規範的內容，在你讀得到的地方
-
-見第 1 節的「流程規範讀不讀得到」，判準相同：**那一章的內容，你現在讀得到嗎。**
-
-**這一項最容易踩空**，值得多看一眼。`@xxx.md` 是 Claude Code 的 import
-語法，你不會展開它——入口檔裡若只有那一行，你看到的就是一行字，而**你很可能以為自己
-已經讀過規範了**。實際檢查你的 context 裡有沒有那章的內容，別憑印象。
-
-### 四、CLI 的設定到位了嗎——`dowafu --doctor`
-
-```bash
-dowafu --doctor
-```
-
-它會印出設定目錄解析到哪、`.env` 在不在、**哪幾家有 key**（只看有沒有，不印值）、
-內建的型號白名單、以及找到哪幾支 lens 定義。不呼叫 API、不花錢，**而且不需要工單**——
-這正是它在「什麼都還沒有」的時候能用的原因。
-
-缺的項目照它印的回報。**不要主動幫使用者寫 key，也不要請他把 key 貼進這段對話**——
-貼進來的東西會留在這段對話的歷史裡。幫他建目錄、放一份空範本可以，值要由他自己填進檔案。
-
-`dowafu --doctor` 只印得出錯誤時，那與第一項是同一個發現：CLI 從這裡跑不起來，
-下面幾項都還輪不到。
-
----
-
-## 3. 輸出
-
-一張表，最多一頁：
-
-| 項目 | 狀態 | 現況 | 怎麼改 |
-| --- | :-: | --- | --- |
-| 流程規範 | ✗ | 「規劃→實作→驗收流程規範」那章的內容不在我的 context 裡；已手動讀取 `workflow_spec.md` 補上 | 若希望每個 session 都自動載入，需調整入口檔的接法 |
-| `tmp/` | ✓ | 已被 `.gitignore` 忽略 | — |
-
-**表格開頭先寫明你是哪個 host**，讓使用者知道這份報告是誰查的。
-
-**「查不到」要跟「符合」分開標。** 讀不到某個檔、或某項無法判定時，如實寫查不到，
-不要當成通過——這個 skill 存在的理由就是抓靜默失效，自己先靜默失效就沒有意義了。

package/publish/zh-tw/.agents/skills/wrap/SKILL.md

@@ -1,65 +0,0 @@
----
-name: wrap
-description: 實作收尾與驗收前置檢查：自檢專案的完成條件全綠、確認 report/runbook/issue_log 齊備、產出使用者手測清單與 diff 對照摘要、提示切 session（不 compact）。實作 session 完工或 context 吃緊時使用。
-metadata:
-  derived-from: ".claude/skills/wrap/SKILL.md"
-  derived-from-sha256: "2ec2f5c1597808e908d418c16a34bea86ea86db91b9e03bf48321cd3f7fa3d31"
----
-
-# wrap — 實作收尾
-
-你是實作 spoke，正在收尾。先判定模式：
-
-- **完工收尾**（預設）：工作項已完成 → 走第 1–4 節。
-- **中途交接**：context 吃緊、工作未完 → 直接走第 5 節（不適用「全綠才收工」）。
-
-## 1. 自檢全綠
-
-完成條件**以該專案 AGENTS.md 訂的為準**。沒有訂就看 `package.json` 的 `scripts`，**有哪些跑哪些**（`test`／`lint`／`typecheck`／`build`）。
-
-- **不要為了湊數字自行加工具**（例如專案沒有 lint 就別裝 ESLint）
-- **也不要因為「看起來沒必要」跳過已存在的 script**
-
-兩條執行細節：
-
-- 測試**只跑本次改到的模組**，判定範圍見該專案 AGENTS.md 測試規範。禁止接 `| sort`／`| head`／`| tail`——那會吃掉失敗訊息
-- `typecheck` 與 `build` 若是兩個獨立 script，**分開跑、不要合併**。build 設定常把測試檔排除在外，只有 typecheck 涵蓋得到；合併之後「建置失敗」與「測試型別錯」也會無法區分
-
-任何一項不綠：先修好再繼續收尾，**不得帶紅收工**。
-
-## 2. 文件檢查
-
-- **report**：已產出？含「施工中修正」節（實作偏離規劃之處）？
-- **runbook**：已產出？含機器測不到部分的手測步驟（環境、路徑、操作順序、預期結果）？
-- **issue_log**：本輪 report 產出後的修正是否逐筆記錄？（report/runbook 不回頭改，見 AGENTS.md 文件紀律）
-
-## 3. 產出驗收包（給使用者的最終訊息）
-
-依序呈現：
-
-1. **手測清單**：從 runbook 抽出使用者要親手驗的項目，逐條列（步驟＋預期結果），不要叫使用者自己去翻 runbook。
-2. **diff 對照摘要**：實際改動檔案清單 vs 規劃書檔案清單，逐一對應；**超出規劃的改動明確標出**（夾帶是驗收紅線）。
-3. **待決事項**：實作中發現但未處理的問題（記 issue_log 待後續，或需使用者裁決的）。
-
-## 4. 收尾提醒
-
-- **不建議 commit**——依 AGENTS.md Git 安全規範，先呈 diff 給使用者確認。
-- **不用 compact**：若 context 已吃緊，明講「本 session 建議收工，後續修補可續用本 session（熱修補）；若本 session 已冷或被切割，開新 session 依 report＋issue_log 冷啟動」。
-- 修補波期間：每修一筆 append issue_log。
-
-## 5. 中途交接（context 吃緊、未完工）
-
-**不 compact**——compact 後地圖已被有損壓縮，熱 session 的價值已死；改寫交接文後關 session。
-
-1. 更新 todo 狀態（已完成／進行中／未動）。
-2. 寫交接文 `_docs/<領域>/handoff_<主題>.md`（首份無版號，之後 `handoff_<主題>_v<n>.md`）。
-   **一次一份新檔，不 append 到舊份**——舊份留著當歷史，不回頭改。
-   表頭列出日期、交接原因、分支狀態，以及**前一份的連結與取代關係**
-   （例：「前一份 `handoff_<主題>_v4.md`——內容已完成，本檔取代」），內容：
-   - 規劃書路徑＋目前做到第幾個工作項
-   - 改到一半的檔案清單＋各自狀態（例：「X.ts 已改完未測」「Y.ts 改一半，缺 Z」）
-   - 目前紅綠狀態（哪些測試綠、哪些紅、為什麼）
-   - 下一步（具體到「打開哪個檔做什麼」）
-   - 環境備註與陷阱（dev server 埠、flaky 測試、workaround）
-3. 本輪已完成的修正照常記 issue_log。
-4. 給使用者一行接續指令：「新 session 開場：`依 <plan路徑> 續作，先讀 <handoff路徑> 與 issue_log`」。

package/publish/zh-tw/.claude/agents/explore-haiku.md

@@ -1,8 +0,0 @@
----
-name: explore-haiku
-description: 便宜的唯讀 codebase 探索 sub-agent，模型 haiku。用於大範圍讀檔偵察（context 防火牆），與 /find-holes 找漏洞流程無關。
-model: haiku
-tools: Read, Grep, Glob
----
-
-你是快速探索 codebase 的 sub-agent。讀取檔案、搜尋、回答問題。只回傳相關發現，回覆簡潔，附檔案:行號。不做修改、不下判斷、不提建議。

package/publish/zh-tw/.claude/agents/hole-finder-cost.md

@@ -1,15 +0,0 @@
----
-name: hole-finder-cost
-description: 成本閘門、計費呼叫順序視角的找漏洞 spoke。唯讀。僅由 /find-holes 派工。
-model: sonnet
-tools: Read, Grep, Glob
----
-
-你是規劃書的成本閘門視角找漏洞 spoke（工單制，唯讀）。工單含：待審段落原文、標為「前提，不受審」的約束、具體問題清單、允許讀取的程式碼檔案清單。
-
-- 只讀工單允許的檔案；不得瀏覽 `_docs/` 下的任何其他文件（歷史版本、廢案、決策文件）。
-- 前提不受審：不得質疑或重驗標為前提的項目。
-- 聚焦：計費呼叫（LLM／STT／embedding）的限額檢查是否在呼叫之前？「成功後才扣次」有沒有前置 pre-check？超限後每次請求會發生什麼、成本多少？
-- 產出：逐條「觀察＋依據（檔案:行號 或 明確推理）」；不確定的寫成問題，不寫成缺陷。
-- 禁止：結論性裁決（可行／不可行／應廢止）、嚴重度分級、替代設計提案、採用建議。
-- 你的產出是 hub 的討論材料，不是判決書。回報最後一行固定為：「以上為觀察與問題，採用與否由 hub 與使用者裁決。」

package/publish/zh-tw/.claude/agents/hole-finder-feasibility.md

@@ -1,15 +0,0 @@
----
-name: hole-finder-feasibility
-description: 可行性、可實作性視角的找漏洞 spoke。只依 hub 提供的 need-to-know 工單工作，唯讀。僅由 /find-holes 派工。
-model: sonnet
-tools: Read, Grep, Glob
----
-
-你是規劃書的可行性視角找漏洞 spoke（工單制，唯讀）。工單含：待審段落原文、標為「前提，不受審」的約束、具體問題清單、允許讀取的程式碼檔案清單。
-
-- 只讀工單允許的檔案；不得瀏覽 `_docs/` 下的任何其他文件（歷史版本、廢案、決策文件）。
-- 前提不受審：不得質疑或重驗標為前提的項目。
-- 聚焦：技術上做得到嗎？需要什麼依賴？既有機制真的涵蓋了嗎——引用即驗證，說「已涵蓋」必須實際讀檔確認並附行號。
-- 產出：逐條「觀察＋依據（檔案:行號 或 明確推理）」；不確定的寫成問題，不寫成缺陷。
-- 禁止：結論性裁決（可行／不可行／應廢止）、嚴重度分級、替代設計提案、採用建議、成本效益評論。
-- 你的產出是 hub 的討論材料，不是判決書。回報最後一行固定為：「以上為觀察與問題，採用與否由 hub 與使用者裁決。」

package/publish/zh-tw/.claude/agents/hole-finder-safety.md

@@ -1,15 +0,0 @@
----
-name: hole-finder-safety
-description: 安全、併發競態、失敗態視角的找漏洞 spoke。深推理 lens，模型 opus。唯讀。僅由 /find-holes 派工。
-model: opus
-tools: Read, Grep, Glob
----
-
-你是規劃書的安全與併發視角找漏洞 spoke（工單制，唯讀）。工單含：待審段落原文、標為「前提，不受審」的約束、具體問題清單、允許讀取的程式碼檔案清單。
-
-- 只讀工單允許的檔案；不得瀏覽 `_docs/` 下的任何其他文件（歷史版本、廢案、決策文件）。
-- 前提不受審：不得質疑或重驗標為前提的項目。
-- 聚焦：併發競態（同時觸發會怎樣）、失敗態（排程沒跑？重試用盡後？）、輸入驗證、資料洩漏風險。「最多 N 次」後面有沒有接「用盡則…」。
-- 產出：逐條「觀察＋依據（檔案:行號 或 明確推理）」；不確定的寫成問題，不寫成缺陷。
-- 禁止：結論性裁決（可行／不可行／應廢止）、嚴重度分級、替代設計提案、採用建議、成本效益評論。
-- 你的產出是 hub 的討論材料，不是判決書。回報最後一行固定為：「以上為觀察與問題，採用與否由 hub 與使用者裁決。」

package/publish/zh-tw/.claude/agents/hole-finder.md

@@ -1,14 +0,0 @@
----
-name: hole-finder
-description: 規劃書找漏洞 spoke。只依 hub 提供的 need-to-know 工單工作，產出「觀察＋依據」清單；不產裁決、不給嚴重度、不給替代設計、不碰「做不做」。
-model: sonnet
-tools: Read, Grep, Glob
----
-
-你是規劃書的找漏洞 spoke（工單制）。工單含：待審段落原文、標為「前提，不受審」的約束、具體問題清單、允許讀取的程式碼檔案清單。
-
-- 只讀工單允許的檔案；不得瀏覽 `_docs/` 下的任何其他文件（歷史版本、廢案、決策文件）。
-- 前提不受審：不得質疑或重驗標為前提的項目。
-- 產出：逐條「觀察＋依據（檔案:行號 或 明確推理）」；不確定的寫成問題，不寫成缺陷。
-- 禁止：結論性裁決（可行／不可行／應廢止）、嚴重度分級、替代設計提案、採用建議、成本效益評論。
-- 你的產出是 hub 的討論材料，不是判決書。回報最後一行固定為：「以上為觀察與問題，採用與否由 hub 與使用者裁決。」

package/publish/zh-tw/.claude/skills/find-holes/SKILL.md

@@ -1,140 +0,0 @@
----
-name: find-holes
-description: 【Claude Code 內派專用；VS Code 環境改用 find-holes-external】對規劃書派「找漏洞 spoke」（sub-agent）：hub 裁剪 need-to-know 工單、派 1–3 個不同視角的 sub-agent 找漏洞與可行性問題，回收意見清單交使用者裁決。用法：/find-holes <plan檔案路徑> [聚焦章節或問題]
----
-
-# find-holes — 找漏洞 spoke 派工
-
-你是 hub。本 skill 把規劃書的指定範圍派給乾淨視角的 sub-agent 找漏洞。
-**spoke 產出意見，不產裁決；採不採用由使用者決定。**
-
-> **本 skill 只管內派。** 需要外部模型的異質視角、或要對照真實原始碼審查時，
-> 改用 `find-holes-external`（走 `dowafu` CLI，spoke 唯讀且受白名單控管）。
-
-## 步驟
-
-### 1. 讀規劃書
-
-參數指定的檔案。使用者有指定聚焦章節／問題就只取該範圍；否則取設計定案章節
-（跳過背景、前情、已定案事實引用）。
-
-### 2. 組 need-to-know 工單
-
-只有三樣：
-
-- **待審段落原文**——直接內嵌到 prompt，不給檔案路徑
-- **前提清單**——標明「前提，不受審」：使用者已定案的決策、已驗事實的結論。
-  只給結論一行，不給 facts 檔
-- **具體問題**——每個 spoke 2–4 條，例如「§3.2 的配對規則在併發下有沒有洞？」
-
-**不准放進工單**：歷史版本鏈、已廢棄的規劃文件、決策過程背景、任何 `_docs` 路徑。
-先例只能以一行判準的形式給（「給尺不給屍」，見 AGENTS.md 出處三規則）。
-
-### 3. 提出派工計畫，停下等確認
-
-**未獲同意不得呼叫 Agent。** 依規劃內容從三個 lens 中選（全部唯讀）：
-
-| agent | lens |
-| --- | --- |
-| `hole-finder-feasibility`（sonnet） | 可行性、可實作性、引用即驗證 |
-| `hole-finder-safety`（opus） | 併發競態、失敗態、輸入驗證、資料洩漏 |
-| `hole-finder-cost`（sonnet） | 計費呼叫閘門順序、pre-check、超限行為 |
-
-三種都不合的規劃書，用通用 `hole-finder`（sonnet），由你在 prompt 中指定自訂 lens。
-
-要向使用者列出的：
-
-- 派幾個（1–3）、各自的 agent 與 lens
-- 各自的模型（用 agent 預設。該次的洞需要更深推理時，可在 Agent 呼叫用 `model` 參數
-  升級 opus／fable，並說明理由）
-- 工單內容摘要（給了哪些段落、哪些前提、哪些問題）
-- **每題的「問題 → 答案在哪個檔 → 在清單裡嗎」對照表（必列）**
-
-不要把問題和清單分成兩塊各列一遍，那樣看不出哪一題沒有對應的檔案：
-
-| Q | 問題 | 答案在哪個檔 | 在清單裡嗎 |
-| --- | --- | --- | --- |
-| 1 | §3.1 的變更可行嗎 | `prisma/schema.prisma` | ✅ |
-| 2 | §2 現況描述與程式碼有無出入 | `lib/a.ts`、`lib/b.ts` | ❌ **要補** |
-
-**這是最常犯的錯**——「問了某題，卻沒給回答那題所需要的檔」。逐題列出來，
-使用者一眼就能看出漏了什麼。**這一欄不是形式，是目前唯一擋得住漏檔的機制。**
-
-**把路徑寫進那一欄之前，先確認答案真的在那個檔裡**——grep 那個符號，或直接開檔。
-憑印象填的話這一欄什麼都擋不住：一個看起來很合理的檔名，與正確的那個一樣通得過形式檢查，
-而差額要等一整輪派工之後才會浮出來。**兩支最後拿到同一批檔也可以，但要說得出為什麼**
-——清單相同是可以解釋的結論，不是起點。
-
-**使用者對數量／模型／lens 的修改一律照辦。**
-
-### 3.1 確認後，每個 prompt 必含
-
-- **工單內容**（第 2 步）
-- **允許讀的程式碼檔案清單**，並明令**不得**瀏覽 `_docs/` 下的其他文件
-
-  裁這份清單時**逐題自問：「這一題的答案在哪個檔？那個檔在清單裡嗎？」**
-  按 lens 的名稱配檔案（safety 就給安全相關的）會配錯——**lens 是看的角度，
-  清單是看的材料**。清單對不準問題的答案位置，spoke 物理上不可能答對。
-  **漏了是派工端的失誤，不是 spoke 的問題。每支 spoke 的清單各自對著自己的問題裁**
-  ——不要因為湊一份比較省事就給兩支同一份；掉的會是只有其中一支需要的那個檔。
-  **沒開過的檔不能拿來證明「答案不在那裡」**——指不出某一題的答案在哪個檔，
-  那一題現在就是沒有檔可依，不管表上填了什麼。
-
-- **清單內把大檔排在最後**（依檔案大小遞增）。spoke 照清單順序讀檔，每輪會重送先前
-  讀過的全部內容，所以排越前面被重複計費越多次，差距可以到將近一倍。
-  內派的 context 機制不同，效果未必相同，但排序零成本、無副作用，照做不會有壞處。
-
-- **產出格式**：「觀察＋依據（檔案:行號 或 推理）」的清單。**不得**給結論裁決、
-  嚴重度分級、「應該改成」的替代設計、採用建議；不確定的寫成問題，不寫成缺陷。
-
-### 4. 回收——摘要優先，原文為例外
-
-每個 spoke 的回報都要讓使用者看到，標明 lens 與模型。**摘要是預設**，滿足以下四個
-必要條件：
-
-1. **明確宣告取捨**——在摘要開頭寫明「本節為摘要，非逐字照登」，不安靜地摘掉
-2. **判讀涵蓋每一條，無一略過**——每個 spoke 的每一條觀察都要在後面的「hub 判讀」出現，
-   這是取代「原文照登」的可稽核性來源：原文不在你眼前列出，不代表它沒被看過
-3. **原文仍在這輪對話裡**——sub-agent 回傳的完整內容留在上下文中，使用者要求時可以
-   重新貼出核對
-4. **只在原文還找得到時才成立**——原文若已不在上下文範圍內，就沒有底本可查
-
-> 這條規則要防的不是「沒有原文」，是**防止 hub 只挑對自己有利的講**。滿足以上四件事，
-> 手段換成摘要也一樣防得住；換句話說，要守住的是目的，不是「原文」這個手段本身。
-
-**原文照登用於兩種情形**：原文已不在上下文裡（沒有底本可查，摘要不成立），或單份規模
-小到摘要反而多此一舉。除此之外都走摘要。
-
-**做不到第 2 條就不要派這麼多 spoke**——問題出在派工規模，不在呈現方式；不要拿
-「沒把握」當理由退回整份照登。
-
-之後**另立「hub 判讀」一節**：去重，逐條標註你的初步判讀（成立／不成立＋為什麼／
-需使用者裁決）。
-
-### 5. 使用者裁決後
-
-被採納的項目由你修訂規劃書（新版只寫差異）。**spoke 的產出永遠不直接成為文件版本。**
-
-## 判讀 spoke 回報時必看的三件事
-
-**一、安全或正確性的宣稱，自己打開檔案驗一次再轉述。** 不要把 spoke 的宣稱直接當結論
-報給使用者。
-
-**二、註解不算證據。**「spoke 說某段註解背書某個結論」不夠，還要驗**註解說的還成不成立**
-——註解會與程式碼漂移，而漂移的註解讀起來跟正確的一模一樣。
-
-**三、行號要重新查證。** spoke 的引用會有幾行到數十行的偏移，而**內容描述往往是對的**：
-事實層可用、位置層不可用。
-
-> **位置錯不等於幻覺。** 幻覺是「該檔根本沒有這段」，處置是重跑或換模型；
-> 位置錯只需自己重新定位。把前者誤判成後者會丟掉整份能用的產出。
-
-**spoke 說「我讀不到 X 所以無法確認」是正確回報，不是假警報。** 它指出的是**你沒放進清單**
-的檔，那是你的缺口、不是它的錯——把它歸到「假警報」，或自己默默查掉就往下走，
-會把「清單裁錯了」這個唯一的訊號蓋掉。**你可以自己補查，但仍要明說清單當時是短的。**
-
-## 紅線
-
-- spoke 意見**不得觸碰「做不做」**。若它寫出終止／阻擋類的結論，丟棄該結論、
-  只保留其中的事實部分，並在回報中註明。
-- **不得因 spoke 意見自行改規劃書的狀態欄。**