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

前作：CM-1053（每個需求成為靜態網站）— 文件產出泛化 ③.1：每個需求成為一個靜態網站（全文件建 html + 導覽）

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

決策者要什麼

「這樣是不是沒有導覽 menu？我想到是有一個共用的導覽頁面，跟之前的 spec 一樣，有左側或是上方 menu，然後切換內容，才方便瀏覽」

「模板要共用喔，不要加一個檔案就每一個 html 都要改，這樣很笨」

CM-1053 做出了「站」，但導覽是往返式的：每頁頂欄有本頁章節錨點 + 一顆「↑ 需求首頁」，頁尾有上一份／下一份 pager。要跳到不相鄰的另一份文件，必須先回主頁再點。缺 SPEC 站那種常駐檔案樹。

🔴 核心約束：共用模板，不可 build-time 寫死

這是本案最重要的一條，違反等於白做。

現況 render_index.py 的 build_pages() 把 prev/next 在 build 時算好、直接寫進每一頁 HTML。後果：新增一支 md，它前後那兩頁的 pager 就過期，必須整個資料夾重 build 才對得上。

側欄若照同樣做法會更嚴重——每頁都嵌完整檔案樹，新增一個檔就得改該資料夾每一頁。決策者明確否決這個方向。

正解＝比照 SPEC 站的 nav-data 驅動（render_html.py + site.js 已是這個架構，可直接參考）：

• build 只產一份 nav-data.json（每個 FR 資料夾一份）
• 每頁 HTML 只放空殼 <nav class="sidebar" data-current="..." data-navdata="..."> + 外連 CSS/JS
• 側欄內容、current 高亮、收合狀態全部瀏覽器端渲染
• 新增一支 md → 只有 nav-data.json 變動，既有 HTML 一字不改

現成參考座標：

• render_html.py:385 nav_data()（產純資料）／:127 空殼 nav 標籤／:423 shared_href()（算相對路徑深度）／:436 navdata 相對路徑
• site.js:50 renderNav()／:88 bindCollapse()／:154 initNav()／:128 showNavError()
• site.css:12 .sidebar 與 :21 起的側欄樣式全套（含 900px 以下自動隱藏）