# 02 — 實作前強制查詢（建議常駐在規則檔）

## 它防的是什麼

大專案的主要檔案可能有兩三萬行 —— **沒有人（包含 AI）能整檔讀進上下文**。

而對模型來說：

> **沒寫進檔案的預留鉤子＝不存在。**

⇒ 同一個能力被重寫第二遍，兩邊還開始漂移。而且你不會發現，因為兩邊都能動。

---

## 直接複製（貼進規則檔）

```markdown
## 🔁 實作前強制流程（HARD RULE）

**任何新增功能／新檔案／新函式之前，必須依序做完：**

1. 讀 `<擴充點索引路徑>`（含「新增時怎麼接」）。
2. `grep` 既有實作 — **至少 3 個同義詞**（中英文都試：
   如 `提醒`/`remind`/`notify`；`分類`/`category`/`kind`）。
   大範圍探索丟給子代理，讓它在自己的上下文翻檔案、只回結論。
3. **在回覆開頭輸出查詢結果**，二選一，不可省略：
   - `既有可複用項：<ID> <名稱>（<怎麼接>）` — 然後接上去，不新寫。
   - `查無可複用項。已查：<索引 / grep 的關鍵字>。新寫理由：<為什麼既有機制接不上>`

**跳過 1–3 直接寫 code 視為錯誤，需重做。**

重點是把「有沒有查」從**不可觀測的內部行為**，變成使用者一眼能驗收的產出
— **沒印出來就是沒查。**

**兩個配套習慣：**
- **先要計畫、不要直接要 code**：計畫階段的錯誤改一行字，實作階段的錯誤改三個檔案。
- **交付後回頭更新索引**：新增擴充點 → 加一列 ＋ code 定義處加 `// EXT-NN:` 標記；
  接上新實作 → 更新「已接的實作」欄。
  🚨 **索引一旦腐爛，比沒有索引更糟（它會誤導）。**
```

---

## 為什麼是「印出來」而不是「請你查一下」

這是這一條最關鍵的設計，值得單獨講：

| 要求 | 可驗收嗎 |
|---|---|
| 「動手前請先查一下有沒有現成的」 | ❌ 你永遠不知道它查了沒 |
| 「在回覆開頭印出查詢結果，二選一」 | ✅ 沒印出來就是沒查，一眼看得出來 |

**把不可觀測的內部行為，變成可驗收的產出。**
這個模式適用於任何「我希望 AI 做但沒辦法檢查」的事。

---

## 配套：擴充點索引長什麼樣

```markdown
| ID | 在哪 | 做什麼 | 已接的實作 | 新增時怎麼接 |
|---|---|---|---|---|
| EXT-06 | `shared/sync.js:142` | 實體建立後同步到後端 | 財務／健康／房屋 | 加一個 `kind` 分支即可 |
| EXT-36 | `shared/store.js:88` | 共用 storage 的唯一寫入口 | 全部 | 一律走 `save()`，不要直接寫 |
```

並且配一支守衛**從 code 端反查**它有沒有說謊：

```bash
grep -rn "EXT-[0-9]\+:" src/     # code 裡的標記
# 對照索引，任一邊有對方沒有的 ⇒ FAIL
```

它擋的那種安靜失敗：**符號改名／檔案搬走／雙平台只更新了一邊**。
索引照樣印得漂漂亮亮，而它指的地方已經不存在了。

---

## 什麼時候可以跳過

只有一種情況：**改動完全在一個既有函式內部，不新增任何符號。**

其餘一律要查 —— 包括「我很確定沒有現成的」。
那個「很確定」正是漏掉的來源。