文件改名與三處內容修正

需求彙整-UIUX改版.md 改名為 UIUX優化成果與技術說明.md（git mv，保留
檔案歷史）。原檔名讓業主誤以為是專案開跑前的內部文件而不會打開，但
文件在補上「本次改版完成項目總覽」後，主要用途已是向業主說明執行成果；
新檔名同時保留「技術說明」，讓工程接手時知道規格仍在這份文件裡。
內文標題同步更新。

第八節標題移除「方案 D」代號：該代號源自 2026-07-20 訪談時的多方案
比較，但 A/B/C 三案從未寫進本文件，單獨留一個 D 對任何讀者都沒有指涉
對象。更新紀錄與開發優化建議.md 內的三處引用一併清除。

第四節缺口 3（監督式／非監督式學習下載按鈕）補註已完成：實作在
commit 80da6cc（Phase 5），元件為 tab_imp_file / tab_cluster_file，
但文件停留在規劃語氣加「✅已確認要做」，與缺口 1 當初有回頭標註
「已實作完成」的處理不一致，容易被誤讀為未施工。

開發優化建議.md：六處對舊檔名／舊稱呼的引用改為《UIUX優化成果與
技術說明》。

docs/{需求彙整-UIUX改版.md → UIUX優化成果與技術說明.md}

@@ -1,4 +1,4 @@
-# SpectraEngine（譯彩紛呈 II 分析引擎）UI/UX 改版需求彙整
+# SpectraEngine（譯彩紛呈 II 分析引擎）UI/UX 優化成果與技術說明
 
 - 文件建立日期：2026-07-20
 - 最後更新日期：2026-08-06（全文同步為最終實作結果，對應 commit `f8aab79`）
@@ -137,7 +137,7 @@
 - 目前點「略過」後，系統標記為「使用者未提供」並永久跳過，**沒有任何入口可以事後回來編輯**
 - **本次改版做法**：不做「回來補」功能，只調整文案誠實告知：「以下資訊會寫入報告開頭，您也可以先略過（略過後這次分析將不會用到這些補充說明）」
 
-### 缺口 3：統計比較分析「監督式學習」「非監督式學習」兩子頁沒有下載按鈕
+### 缺口 3：統計比較分析「監督式學習」「非監督式學習」兩子頁沒有下載按鈕（2026-07-21 已實作完成）
 - 「1. 敘述統計」「2. 差異性分析」有各自的下載按鈕，但「3. 監督式學習」「4. 非監督式學習」**完全沒有下載入口**
 - 澄清：**不是內容產不出來**——後端 `run_statistical_analysis` 已經有算出並存檔（`imp_path`／`imp_fig_path`／`dendro_path`／`elbow_path`／`cluster_fig_path`／`cluster_csv_path`），只是沒有接對應的 UI 下載按鈕
 - **技術上確認可行、且是低成本修改**：「敘述統計」「差異性分析」兩子頁已經有接 `gr.File` 元件顯示下載按鈕（`tab_desc_file`／`tab_diff_file`），照同一種寫法幫「監督式學習」「非監督式學習」各加一個 `gr.File` 接到已存在的檔案路徑即可，不需新增任何運算邏輯
@@ -150,7 +150,7 @@
   | 監督式學習 | `imp_path`：特徵重要性分數排序表（CSV）；`imp_fig_path`：Top20 特徵重要性長條圖（PNG） |
   | 非監督式學習 | `dendro_path`：階層式分群樹狀圖（PNG）；`elbow_path`：K-means Elbow 曲線（PNG）；`cluster_fig_path`：PCA 二維分群散佈圖（PNG）；`cluster_csv_path`：分群結果表（CSV） |
 
-- **✅ 已確認要做**：補上下載按鈕以維持四個子頁一致性
+- **✅ 已實作完成**：commit `80da6cc`（Phase 5）補上兩顆下載按鈕，四個統計子頁的下載入口現已一致。元件為 `tab_imp_file`（label「下載監督式學習」，app_agent.py:3086）與 `tab_cluster_file`（label「下載非監督式學習」，app_agent.py:3103）
 
 ## 五、資訊架構設計
 
@@ -265,7 +265,7 @@
 - 章節數字編號（一、二、三、四）拿掉，改純文字標題（見 Bug 清單）
 - 「略過」文案定稿：「以下資訊會寫入報告開頭，您也可以先略過（略過後這次分析將不會用到這些補充說明）」
 
-## 八、持久化機制（方案 D：進度存檔／讀檔）
+## 八、持久化機制（進度存檔／讀檔）
 
 不做登入、不做 server 端多 session 儲存。理由：避免資安疑慮（無登入代表任何人拿到 session 網址都能看到他人資料）、避免與現有 Gradio session 架構衝突。
 
@@ -381,11 +381,12 @@
 
 | 日期 | 修改摘要 |
 |---|---|
-| 2026-07-20 | 初版建立：專案背景、技術限制、Bug 1-2、資訊架構、版面配置、Metadata 表單、持久化機制（方案D）、下載機制、Footer/設定/API處理、視覺規範（14px字級）、既有架構限制 |
+| 2026-07-20 | 初版建立：專案背景、技術限制、Bug 1-2、資訊架構、版面配置、Metadata 表單、持久化機制、下載機制、Footer/設定/API處理、視覺規範（14px字級）、既有架構限制 |
 | 2026-07-20 | 新增 Bug 3（步驟列失敗視覺狀態，已確認真實可觸發）＋上傳驗證強化（檔名字首合法性／每組檔案數下限／Metadata群組數一致性）；新增十三章空狀態/極限狀態/錯誤狀態規劃；新增十四章待業主確認清單 |
 | 2026-07-20 | 「監督式學習」「非監督式學習」補下載按鈕確認要做（移出待業主清單），命名定為「下載監督式學習」／「下載非監督式學習」；格式驗證每組檔案數下限確認為既有缺陷修正、非待業主確認事項；精簡缺口3內容；補充 Metadata 表單四種情境皆會出現、差異僅在內容的說明 |
 | 2026-07-20 | 開始與 UI/UX Pro Max Skill 協作視覺設計：確定風格方向（對話區參考AI-Native UI、結果分頁參考Data-Dense Dashboard）、字體（英文數字Crimson Pro＋中文維持Noto Sans TC）、配色（維持業主既有雙主題系統，WCAG對比度驗算通過，不重新設計） |
 | 2026-07-24 | 缺口 1「整包下載」改為直接實作完成（原訂只做假按鈕交業主拍板），第九節下載機制改寫成四顆下載捷徑的實際規格，待業主確認清單第 1 項結案；持久化機制的「防手滑」（`beforeunload`）同步實作完成 |
+| 2026-08-06 | 檔名由 `需求彙整-UIUX改版.md` 改為 `UIUX優化成果與技術說明.md`，反映文件的主要用途已從「協作時的需求依據」轉為「向業主說明本次執行成果，並保留技術規格供工程接手」；第八節標題移除「方案 D」代號（該代號源自 2026-07-20 訪談時的多方案比較，A/B/C 三案未寫入本文件，單獨保留 D 對讀者無意義）；第四節缺口 3 補註已於 commit `80da6cc` 實作完成（原文件停留在規劃語氣，未回頭標註，易誤讀為未施工） |
 | 2026-08-06 | **全文同步為最終實作結果**（對應 commit `f8aab79`）：新增「本次改版完成項目總覽」章節；5.1 首頁改寫（情境卡片已於 2026-07-30 依業主要求搬回工作區成為第 1 步，首頁只留品牌介紹＋單一入口）；5.2 步驟列由 7 步更正為 4 步、補上左側導覽的最終項目與沿革；6.2／6.3 版面圖改為實作結果（下載捷徑四顆、技術執行紀錄轉正為獨立頁、置底設定/API 連結列移除、二欄改三欄）；6.4 補技術執行紀錄頁；第八節註明存檔／讀檔未實作；13.1 首頁空狀態更新；第十四節移除校徽識別項（已確認不做）；第二節風險分區行號更新（CSS 已抽出為 `assets/app.css`，全檔行號位移） |
 | 2026-07-24 | 運算階段重構：步驟列收斂為 3 步（文本上傳／語料說明／分析運算），格式驗證退為文本上傳內部處理、指標計算+統計分析+報告產出合併為「分析運算」單一步驟；分析運算改用 Canvas 內容區塊分段呈現三子階段（進度→摘要＋查看入口）。Bug 3（步驟列失敗視覺狀態）與報告產出失敗的誠實呈現一併落地：報告失敗不再誤報「全部完成」，步驟列標紅、對話總結據實說明「指標與統計已完成、僅報告未產出」。結果導覽項目在對應結果產出前 disabled |
 

docs/開發優化建議.md

@@ -87,11 +87,11 @@
 
 我在 2026-08-05 實測時重現了一個問題：一次完整分析（指標計算＋統計分析＋報告撰寫）耗時數分鐘，過程中瀏覽器分頁若失去與伺服器的即時連線，**後端會照常把運算跑完、報告與下載檔案也正常產出在磁碟上，但前端畫面永遠停在「處理中」不會更新**。此時使用者若重新整理頁面試圖恢復，畫面只會回到全新首頁；剛才的分析結果雖然還在磁碟上（`sessions/<session_id>/output/`），但介面上沒有任何入口能找回它。
 
-我追查後確認，這個缺口從系統第一天架構設計起就存在，與這次改版動到的邏輯無關：系統沒有任何形式的執行狀態持久化。這正是原始需求彙整文件（`docs/需求彙整-UIUX改版.md` 第八節）裡列為「持久化機制（方案 D）」、從專案第一天起進度就是 0% 的項目。
+我追查後確認，這個缺口從系統第一天架構設計起就存在，與這次改版動到的邏輯無關：系統沒有任何形式的執行狀態持久化。這正是《UIUX優化成果與技術說明》（`docs/UIUX優化成果與技術說明.md`）第八節列為「持久化機制」、從專案第一天起進度就是 0% 的項目。
 
 ### 我為什麼把它歸類為工程範疇、不放進本次改版施工範圍
 
-需求彙整文件第二節「技術背景與限制」原本就把 `app_agent.py` 分成三個風險區，並明確界定本次改版的施工邊界：
+《UIUX優化成果與技術說明》第二節「技術背景與限制」原本就把 `app_agent.py` 分成三個風險區，並明確界定本次改版的施工邊界：
 
 | 區域 | 風險等級 | 本次改版是否可動 |
 |---|---|---|
@@ -105,7 +105,7 @@
 
 ### 原始需求（2026-07-20 訪談已定案，尚未實作）
 
-摘自需求彙整文件第八節「持久化機制（方案 D：進度存檔／讀檔）」：
+摘自《UIUX優化成果與技術說明》第八節「持久化機制（進度存檔／讀檔）」：
 
 - **不做登入、不做伺服器端多 session 儲存**。理由：無登入代表任何人拿到 session 網址都能看到他人資料，有資安疑慮；且會與現有 Gradio session 架構衝突。
 - 防手滑（`beforeunload` 離開頁面前跳出確認）：**已實作完成**（2026-07-24）。
@@ -116,7 +116,7 @@
   - 存檔用自訂副檔名（如 `.spectra`）、次要按鈕樣式＋警語，與「成果下載」（一般格式＋醒目主色按鈕）在視覺與命名上明確區分，避免非技術使用者誤認「中繼存檔＝最終成果」
 - 多開分析：不需特別開發，開新分頁天生是獨立 session，只需在首次進站提示「建議同時只跑一個分析，以確保運算速度」
 
-需求彙整文件第十三節「錯誤狀態設計」也已預先列出一個目前完全沒有現成邏輯的案例：**讀取進度檔案毀損或格式不符**，需要設計對應錯誤訊息與復原路徑。
+《UIUX優化成果與技術說明》第十三節「錯誤狀態設計」也已預先列出一個目前完全沒有現成邏輯的案例：**讀取進度檔案毀損或格式不符**，需要設計對應錯誤訊息與復原路徑。
 
 ### 現況缺口：連「執行到一半先匯出」都做不到
 
@@ -140,11 +140,11 @@
 
 ### 實作選項與優缺點
 
-**選項 A：純前端存讀檔（原方案 D 設計，2026-07-20 已定案方向）**
+**選項 A：純前端存讀檔（2026-07-20 已定案方向）**
 
 使用者手動點擊「儲存進度」，系統把 `state` + `chat_history` + `log_history` + 已上傳原始文本序列化成一個 `.spectra` 檔案供下載；之後在首頁點「讀取進度」上傳該檔案，還原上述狀態並重放對應的可見性 yield 邏輯。
 
-- 優點：不需要伺服器端多使用者儲存、不需要登入，維持原始需求「無資安疑慮」的設計初衷；不需要在現有 Hugging Face Spaces 之外額外採購資料庫或儲存服務；與需求彙整文件已定案方向一致
+- 優點：不需要伺服器端多使用者儲存、不需要登入，維持原始需求「無資安疑慮」的設計初衷；不需要在現有 Hugging Face Spaces 之外額外採購資料庫或儲存服務；與《UIUX優化成果與技術說明》已定案方向一致
 - 缺點：`.spectra` 檔案內含完整原始語料，體積不小，且**使用者要自行妥善保管，這本身是一個新的機密性風險點**（見第一節）；**無法解決本節重現的問題**，因為存檔動作需要使用者手動觸發，若連線已經斷了，使用者根本按不到那顆按鈕；讀檔還原邏輯技術複雜度不低
 
 **選項 B：伺服器端 session 儲存 + 恢復代碼／連結**
@@ -232,7 +232,7 @@ def _call_openrouter(api_key, model, system_prompt, user_prompt, max_tokens=1600
 
 ## 四、Session 輸出目錄清理機制
 
-原始需求彙整文件第十四節「待業主確認的範圍清單」第 3 項已列出：**Session 輸出目錄的清理機制**。`sessions/`（`SESSIONS_DIR`，app_agent.py:71-72）目前沒���任何過期清理邏輯，每次分析都會留下一個含原始上傳文本與全部產出檔案的資料夾。
+《UIUX優化成果與技術說明》第十四節「待業主確認的範圍清單」第 3 項已列出：**Session 輸出目錄的清理機制**。`sessions/`（`SESSIONS_DIR`，app_agent.py:71-72）目前沒有任何過期清理邏輯，每次分析都會留下一個含原始上傳文本與全部產出檔案的資料夾。
 
 這一項同時命中兩個角度：