feat(prompts): add /m2_smoketest for app verification workflow

[oahsiao]

What

新增 /m2_smoketest（.github/prompts/m2_smoketest.prompt.md）—— App 基本驗證的完整流程：探索既有 smoke test → 沒有就建立／有就依新功能補測試 → review 並精修腳本 → 實際執行 → 輸出量化報告與明確的 bug 清單。覆蓋安裝、執行、設定、使用者體驗、效能五個面向，約定目錄為 smoketest_script/。

同時把它接進 copilot-instructions.md §9 路由表與標準流程順序（/m2_review → 修 → /m2_smoketest → /m2_pr），並更新 README 與 CHANGELOG（v3.1.0）。

Why

既有六支指令裡沒有一支回答「這包東西還裝得起來、跑得起來嗎」。/m2_review 只看 diff，CI 只跑得動自動化測試，而桌面 App 最常壞的地方——安裝、升級覆蓋、設定遷移、關閉後殘留 process——全都在這兩者的射程之外。

/m2_evo 已經把 smoke test 當成每個迭代的回歸防線（§0.4「沒有 smoke test 就沒有這支 prompt」），但它只說「要有」，沒說「怎麼生出來、怎麼維護、怎麼判讀」。這支 prompt 補的就是那一段。

第二個動機是誠實度。smoke test 最容易腐爛的方式不是沒人寫，而是寫了之後慢慢變成「永遠會綠」——空 catch、沒有斷言、把跑不動的案例標成 skip、效能量一次就下結論。所以這支 prompt 的重點不在「會跑測試」，而在讓放水無所遁形。

How

流程分流（§1–§3）

• 第一步一定先探索，判定三態並明說是哪一種：A 不存在 → 建立／B 已存在 → 缺口分析後補測試／C 存在但在別處 → 用按鈕問使用者，不另起爐灶（重複造第二套 smoke test 的結果是兩套一起爛）。
• 缺口分析不憑印象：以 git log -1 --format=%H -- smoketest_script 找出腳本上次更新後的 diff，再依訊號對照該補哪些案例（新 CLI 參數、新設定項、新頁面、安裝變更、新相依、schema 變更、修過的 bug）。先輸出覆蓋缺口表、按鈕確認過才動手。

五大面向與編號（§4）

• SMK-<AREA>-<NNN>，AREA ∈ INS／RUN／CFG／UX／PERF；ID 發出去就不重用，否則歷史報告會對不上。
• UX 明確畫出誠實界線：能自動化的自動化，不能的進 manual-checklist.md 標 manual ——沒驗證就不准寫 pass。
• PERF 要求每項至少 3 次取中位數、先暖機、門檻寫在腳本裡；首次執行只寫 baseline 並標「不做回歸判定」。

輸出契約（§2.4）

• 強制 result.json（summary / cases / metrics 欄位固定），報告一律以它為資料來源，不靠 agent 讀 stdout 猜數字。
• 退出碼分三級：0 全過／1 有 fail／2 腳本或環境本身壞掉 —— 不分開的話，CI 紅了看不出是 App 壞還是測試壞。

環境安全（§6.1、§6.4）

• 安裝與設定測試被明確定義為破壞性動作：一律在可還原的隔離環境進行、事前備份真實設定、事後還原並回報還原結果（還原失敗要標 🔴 放在報告最上方）。
• 要動系統層（登錄檔／服務／驅動／憑證／防火牆）必須先 beep + 按鈕確認。禁用 git clean -fd、git reset --hard，以及打到使用者目錄的 Remove-Item -Recurse -Force。

量化報告與 bug 清單（§7、§8）

• 總通過率 + 各面向 PASS/FAIL/FLAKY/SKIP/MANUAL 表 + 效能 vs 基準 + 環境還原結果 + 二選一結論（可放行／不可放行，不寫「大致上還行」）。
• 通過率分母 = pass + fail + flaky + skip，不含 manual，但 manual 數量必須出現在報告上。
• bug 清單分兩類不可混：App 的 bug（嚴重度 + 檔案:行號 + 重現步驟 + 期望 vs 實際）與smoke test 自己的問題（每筆給可直接套用的修法）。

範圍界線

• 只改 smoketest_script/ 底下的東西且逐項確認；不修 App 的 bug、不改 CI workflow、不 commit／不 push／不開 PR —— 問題列清楚後交回使用者或 /m2_review。
• results/ 的忽略設定寫在 smoketest_script/.gitignore（巢狀），不動 repo 根目錄的 .gitignore，以免在下游 repo 留下沒被要求的變更、也不牴觸上面那條範圍規則。
• 不支援 auto：安裝與設定測試會實際動到使用者機器，確認節點不可免除；想少被打擾用 /m2_smoketest run（只跑不改）。

其他

• copilot-instructions.md §9 的「強制確認節點」列舉由 four → five（納入 m2_smoketest），並在 Auto Mode 一節寫明它為何被排除。
• scripts/validate.py 會檢查路由表涵蓋所有 prompt file，所以 §9 的 routing 條目是必要而非選配。

Impact

• 影響範圍：新增一支 prompt file；copilot-instructions.md §9 三處措辭；README 指令表／流程圖／auto 說明／目錄樹。
• 既有六支指令行為完全不變，沒有任何確認節點被放寬。
• 下游 repo：sync-manifest.txt 已列 prompts/（資料夾 overlay），新檔會自動同步，manifest 與下游 workflow 皆零改動。下次同步後 Copilot Chat 打 / 會多一支 /m2_smoketest。
• Breaking change：無。屬 minor（v3.1.0）。
• 風險：這支 prompt 會在使用者機器上實際執行安裝與設定測試。已用「隔離環境 + 事前備份 + 事後還原 + 系統層需按鈕確認 + 不支援 auto」四道防線收斂，但建議先在自己的 App 專案實跑一次再推廣。

Verification

• python scripts/validate.py → 6 個 prompt file 全數通過、0 錯誤 0 警告（含機密掃描與「路由表涵蓋所有 prompt」檢查）
• 走過 /m2_review → 🔴 0 項、🟡 2 項，兩項 Should fix 皆已修（.gitignore 自我矛盾、§9 確認節點列舉漏列）
• 驗算報告範例的算術：五個面向逐列 案例 = ✅+❌+⚠️+⏭️ 成立，總通過率 42/45 = 93.3%，效能 +2.9% / +25.2% 與離散度 3.7% 皆相符
• git diff --cached 自檢無機密資料、無內部 IP、無殘留 debug 程式碼
• 確認本機未落後 origin/main（git rev-list --left-right --count 左側為 0）
• 依 CI gate 於同一 PR 更新 CHANGELOG.md（v3.1.0）
• /m2_smoketest 尚未在真實 App 專案端到端實跑過（本 repo 沒有可安裝的 App，跑不到 INS/RUN/CFG/UX/PERF 任一面向）—— 屬規格，需在下游 App 專案首次使用時驗證
• 未涵蓋的 🔵 Nit 3 項（探索指令加 -Depth、pwsh fallback、報告欄名改 計分案例）刻意保留，待實跑後再決定
• CI passed