# MEMORY.md（索引檔）

> ⚠️ 這份是**唯一會每次載入**的記憶檔，所以它跟規則檔受同一條成本約束：
> **一則一行，只放指標與鉤子，永遠不放內容。**
> 實際比例可以是：索引 5 行、內容 700 行 —— 索引只佔 0.7%，但它決定了另外 99.3% 會不會被撈出來。

- [01 我是誰與合作方式](01-user-and-collab.md) — `<回覆語言／要計畫不要 code／範圍延伸先報價／…>`
- [02 專案定位與目標](02-scope-and-goals.md) — `<唯一焦點是什麼、任何提案往哪個方向收斂>`
- [03 排程與硬錨點](03-schedule.md) — `<權威主表在哪、哪些日期不能動>`
- [04 已拍板的決策](04-decisions.md) — **別再提替代方案的那些**
- [05 作廢紀錄](05-obsolete-log.md) — **提新方案前先讀**，防重議

---
---

# 以下是五類記憶各一則範例（實際使用時各自獨立成檔）

---

## 範例 1：`type: user`

```markdown
---
name: reply-language-and-style
description: 回覆語言與說明風格的固定要求
metadata:
  type: user
---

回覆一律用 <語言>。英文 UI 字樣要附中文意思（選擇卡也算）。
說明採手把手風格：指令要能直接複製貼上，不要只寫「執行建置」。

**Why:** 我不是每個工具都熟，缺一步就卡住，而問回來的來回成本比多寫一行高。
**How to apply:** 給指令時附上「在哪個目錄執行」與「預期看到什麼輸出」。

相關：[[plan-before-code]]
```

---

## 範例 2：`type: feedback` —— **最重要的一類**

```markdown
---
name: plan-before-code
description: 大改動一律先出計畫與估時，不直接寫 code
metadata:
  type: feedback
---

大改動先出【計畫＋估時】讓我裁示，不要直接產出 code。
範圍要延伸（「順手也改一下 X」）先報價，不要直接做。

**Why:** 計畫階段的錯誤改一行字，實作階段的錯誤改三個檔案。
   而且我對範圍的判斷比對實作細節的判斷準得多。
**How to apply:** 收到「做 X」時，先回一份「要動哪些檔／風險／估時／不確定的地方」，
   等我說「開始」再動手。已經在跑的工作中途發現要擴大範圍，停下來問。

相關：[[green-light-needs-numbers]]、[[obsolete-log]]
```

> 🚨 **`feedback` 一定要寫 `Why:`。** 只寫 `How` 的話，下次遇到「形狀不同但同一個道理」的情況，
> AI 不會推廣過去。

---

## 範例 3：`type: project`

```markdown
---
name: current-single-focus
description: 這一版的唯一焦點，與所有提案的收斂方向
metadata:
  type: project
---

現階段唯一焦點＝<目標>（日期：<YYYY-MM-DD>）。
任何「順便加個功能」的提案一律往**收斂**推，不往擴張推。

**Why:** 範圍每擴張一次，<目標> 就往後推一次，而那個日期是硬的。
**How to apply:** 收到新功能提案時，先問「這個不做，<目標> 會不會受影響？」
   不會的話，寫進排程表的〈之後再說〉區，不要排進這個月。

⚠️ 硬數字（剩餘工時、表數、端點數）**不存在這裡** —— 一律用
   `python tools/spec_check.py --list` 現算。存進記憶的數字會安靜地腐爛。
```

---

## 範例 4：`type: reference`

```markdown
---
name: external-dashboards
description: 常用的外部儀表板與後台入口
metadata:
  type: reference
---

- 部署狀態：<URL>
- 資料庫主控台：<URL>
- 錯誤追蹤：<URL>

**How to apply:** 問「線上現在怎麼樣」時先去這三個地方，不要用上次對話的印象回答。
```

---

## 範例 5：`type: obsolete` —— **這一類是這套系統自己加的**

```markdown
---
name: obsolete-log
description: 被否決／被取代的決策。提新方案前先讀，防重議
metadata:
  type: obsolete
---

# A 區：已作廢的狀態（曾經是真的，現在不是）

- **「等 <某功能> 做完才能做 <另一件事>」** — <日期>已解除，<某功能>已完成。
  🚨 全 repo 若還看到這句話＝殘留，**當場修掉，不要照著它把工作往後排。**

# B 區：被推翻／否決的決策（含理由，1–3 行）

- **<方案 A>**（<日期>否決）
  理由：<為什麼>。⇒ <改用什麼>。

- **<方案 B>**（<日期>取消）
  理由：<為什麼>。
  ⚠️ 這個方案聽起來很合理，所以**每隔幾週就會有人重提一次** —— 包括我自己。

# 使用規則

**提新方案、或覺得「這個好像可以做」之前，先讀本檔。**
```

> **為什麼這一格特別值錢**：
> 對協作 → 它**防重議**，直接省下重複討論的時間。
> 對自己 → **「我否決過什麼、為什麼」比「我做了什麼」更能證明判斷力**：
> 做過的事只證明你動過手；否決紀錄證明你在同一批資訊下做過取捨，而且說得出理由。

---

## 三條寫記憶的坑（全文見 [03-memory.md](../03-memory.md)）

1. **記憶是「寫的時候是真的」，不是「現在是真的」** —— 提到檔案／函式／旗標的，用之前先確認它還在。
2. **硬數字不要存進記憶** —— 存「怎麼取得現值」的指令，不存值本身。
3. **不要存 repo 已經記錄的東西** —— 有人要求你記住時，先問「這件事哪裡不明顯？」
   不明顯的那一層才值得存。