母案：CM-1049（文件產出機制泛化）— 文件產出機制泛化：md + build 涵蓋討論稿/規格，並自動生成 FR 索引頁

前作：CM-1050（抽共用 CSS + render_doc.py）— 已 Done，[文件產出泛化 ②：抽共用 CSS + render_doc.py，討論稿改 md](https://app.notion.com/p/CSS-render_doc-py-md-3b1346da4cd0819d8374d95af4e346f3)

設計與驗證結論：docs/analysis/2026-08-03-doc-html-pipeline.md

要解決的問題

決策者要「一個需求一份主 HTML」：含討論稿／spec／開發過程紀錄／操作手冊／Notion 連結，供未來回查與 release SPEC 站參考。

🔴 不要另寫一份手維護的主 HTML。那會變成第五份要人工維護的文件，而它記的東西（檔案清單、Notion 卡號、SPEC 連結）全都存在別處，手維護必然 stale（新增 handoff 忘了補、開了新卡沒登記），半年後比沒有更糟（你以為它是完整的）。

改成 build 自動生成：掃得到的不手寫，這是不 stale 的關鍵。

docs/features/FR-060-.../
  ├─ （設定）          ← 唯一手寫，只寫「掃不到的東西」
  ├─ discussion.md
  ├─ design.md
  └─ handoff/*.md
              ↓ build
  索引頁 HTML          ← 自動生成

手寫部分只放：title／status／Notion 母案與卡樹／本案牽動的 SPEC 頁／relates。

檔案清單、日期、handoff 列表全由 build 掃資料夾產生。

🔴 開工第一個要回答的問題（不要預設照原案做）

原案寫「新增 _meta.yaml」，但 CM-1050 落地後情勢變了：render_doc.py 已經用 YAML front matter（split_front_matter()，靠 pyyaml）在 md 檔頭寫 title / eyebrow / chips / lede 等。

→ 再另立 _meta.yaml 就是兩套設定格式並存，正是本 arc 一直在避免的事。

先讀 render_doc.py 的 front matter 機制，再判斷三選一：

• (a) 索引頁設定也用 front matter（放在資料夾內某支主 md，例如 README.md）
• (b) 獨立 _meta.yaml（原案）
• (c) 其他

拿不準 → 問決策者，不要自己挑一個就做下去。

🔴 前置約束：兩支 CSS 不可同頁混掛

CM-1050 實作後確認：site.css（SPEC 站）與 doc-base.css / doc-artifact.css（討論稿）共通語意對齊、色盤各自獨立——--ink / --bg / --accent / --line 同名，但 SPEC 站是藏青金、討論稿是青灰。