§2
結論
- 落地版出錯時要能遠端查：客戶不必會下指令、原廠不必到場。四棒——log 地基／錯誤收集站進出貨包／
guidant diag 指令／系統設定的支援頁（最近錯誤列表 ＋ 一鍵匯出）。
- 錯誤收集站選 GlitchTip 並隨安裝包出貨，每個客戶自帶一套、只給原廠管理員看。Sentry 自架（授權不允許隨產品出貨）與 Loki/Grafana（做的是日誌聚合不是錯誤去重）都排除了。
- 驗收條款寫死且不可打折：故意弄壞一個功能 → 產包 → 丟給一個什麼都不知道的 AI（只給包＋原始碼），它要能指出根本原因與修法。過不了不算完成。
- 像但不做的：診斷包不加密（與「客戶要能自審交出了什麼」直接衝突，遮罩才是防線）；不做 log 檢視畫面、不另開系統日誌選單頁（會與 GlitchTip 成為第三套錯誤檢視介面）；不做自動回傳原廠。
§4
需求討論紀錄
- 2026-09-02：決策者提出白話需求——落地版出錯只能派人到場，要一個「客戶一鍵匯出、原廠遠端分析」的診斷包；驗收條款當場就寫死成「丟給乾淨 AI 要查得出來」。
- 2026-09-17：看過 FR-071.0 的 GlitchTip 試用效果後拍板往下做，並選積極版（站台隨安裝包出貨，每客戶一套）；同時定案開放註冊預設關、POC 試用期不接、Sentry 自架與 Loki/Grafana 排除。
- 2026-09-18：D1–D10 裁定（多數採討論稿建議，D3 與 D10 改判）；新增 D11（支援頁直接列最近 ERROR，理由是一線最常做的就是「看一眼是什麼錯」，不該先開站台登入）；追加兩項子任務（出貨環境明訂
RUN_ENV、操作日誌時間區間查詢）。
- 2026-09-18 被推翻的判斷：討論稿寫「落地版根本沒有 log 檔、prod 沒掛資料庫輸出所以稽核事件可能是空的」——實查後兩者皆錯。出貨端根本沒設
RUN_ENV，預設值讓客戶機房跑的是 dev 那套（檔案與資料庫輸出都開著）。真正的問題是「沒有人明訂過用哪一套」與「稽核事件被除錯 log 以 1,255 : 1 淹沒」。D3 因此從「退役整張表」改判為「表留著、寫入端加 filter」。
- 決策者定調：客戶端的人不碰 Linux、不碰 docker——他只碰 GlitchTip 站台與支援頁；檔案 log 是診斷包的原料，不是給客戶看的東西。
§5
文件
以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。
需求與討論
設計