feat(1.16.0): 讓 wiki 真的被讀到——查詢即搜尋 wiki+subagent 自動注入

病根(leo 2026-07-20 點破,真實事故):總管三次擋回 leo「某機制早已棄用」的
正確判斷,查證後 leo 全對。根因不是知識不足,是讀取流程:
① wiki 只讀開頭就開工(關鍵記載在第 56 行,答案一直在那裡)
② 派 subagent 只叫它讀 code、沒叫讀 wiki → 從稿子推論必然得出過時結論
③ 把 wiki 的「當時狀態」當永久事實(沒核對解除條件)

leo:「我需要的不是你記住,而是機制面的解法」
「如果你不是讀而是搜尋 wiki,就不會只讀 50 行就下定論,像 cmd+F 那樣高亮。」

新增:
- wiki-first-search.sh(PreToolUse: Grep|Glob|Read)
  查 code/文件的當下,用同一組關鍵字 grep wiki,只推命中行。
  開場 push 全文解決不了「只讀開頭」——時機才是關鍵。提醒不阻擋。
- subagent-wiki-guard.sh(PreToolUse: Task)
  查證/實作類任務 → 注入「先查 wiki」指示。
  第一版為「上游沒交代就擋」,經 leo 指正改注入式:
  「它只要聽到查,就應該主動查 wiki」——依賴上游記得寫=同一個病。

update.sh 除同步兩支 hook 外,自動註冊進 settings.json(不只提醒)——
靠人看提醒手動補,等於把同一個病搬到安裝環節。
template/ 新裝樣板同步(新 repo 裝完即生效)。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-07-21 01:30:46 +08:00
parent 7b83465acf
commit ed3a97c6a2
6 changed files with 235 additions and 2 deletions
+34
View File
@@ -10,6 +10,40 @@
---
## 1.16.0 — 讓 wiki 真的被讀到:查詢即搜尋+subagent 自動注入
**病根(leo 2026-07-20 點破,真實事故)**:總管三次擋回 leo「某機制早已棄用」的正確判斷,
查證後 leo 全對。根因不是知識不足,是**讀取流程**:
① wiki 只讀開頭就開工(關鍵記載在第 56 行,答案一直在那裡)
② 派 subagent 只叫它讀 code、沒叫讀 wiki → agent 從稿子推論,**必然**得出過時結論
③ 把 wiki 的「當時狀態」當永久事實(沒核對解除條件)
leo:「我需要的不是你記住,而是如何解這題不再發生,**機制面的解法**」
「如果你不是讀而是**搜尋** wiki,就不會只讀 50 行就下定論,而是像 cmd+F 那樣高亮。」
**新增兩支 hook(皆不依賴任何人自覺)**
- **`wiki-first-search.sh`**PreToolUse: `Grep|Glob|Read`
在「正要去翻 code/文件」的當下,用同一組關鍵字 grep `system-dev/wiki/`
**只推命中行**(非開場 push 全文——那必然只被讀開頭)。提醒不阻擋:
wiki 沒記載時本來就該翻原文,唯一目的是消滅「不知道 wiki 有寫」。
- **`subagent-wiki-guard.sh`**PreToolUse: `Task`
偵測查證/實作類任務 → **注入**「先查 wiki」指示給 subagent。
⚠️ 第一版設計為「上游 prompt 沒交代就擋下」,經 leo 指正改為注入式:
「subagent 的問題跟你一樣——**它只要聽到查,就應該主動查 wiki**,
因為每個 repo 都有維護自己的 wiki。」依賴上游記得寫指示 = 同一個病。
**安裝行為**`update.sh` 除同步兩支 hook 外,**自動註冊進 settings.json**(不只提醒)。
理由同上——靠人看提醒手動補,等於把同一個病搬到安裝環節。
**注入給 subagent 的三條硬規則**
1. wiki 與程式碼衝突 → **以 wiki 為準**,回報衝突,不自行用 code 推翻 wiki
2. wiki 寫「不可動/待廢除/進行中」→ 讀它的**解除條件**逐條核對(那是當時狀態,非永久禁令)
3. 翻原文後得到新結論 → 回報「wiki 該更新」(wiki 過時是債,要還)
---
## 1.15.0 — SDD 生命週期鐵律:單一活性 SDDissue #6
leo 拍板全體系採「單一活性 SDD」制度:任何時刻每個 repo 只有一份現行 SDD(`status: active`),所有開發任務唯一對應它的 tasks。prompt 軟約束+檔案系統硬約束(hook)雙層。