# ADR-079: Telegram 分類按鈕下架 + Phase 5 完整化計畫 > **日期**: 2026-04-14(台北深夜) > **狀態**: ✅ Completed(Sprint 5.0-5.4 全數完成,2026-04-14 深夜) > **作者**: Claude Sonnet 4.6(首席架構師)+ 統帥 audit > **相關**: ADR-071 通知類型、ADR-075 Telegram 標準、[feedback_no_ghost_buttons.md](~/.claude/projects/-Users-ogt-awoooi/memory/feedback_no_ghost_buttons.md) --- ## 背景 統帥 2026-04-14 20:00 完整 audit 發現 `telegram_gateway._CATEGORY_BUTTONS` 定義的 **28 個分類按鈕全部是鬼魂**: | 檢查 | 結果 | |------|------| | callback_data 格式 | ❌ 3-part `action:xxx:id`,parser 只認 4-part nonce / 2-part info | | 後端 dispatch handler | ❌ grep `apps/api/src` 無任何 `elif action == "restart_service":` 等分支 | | MCP 底層能力 | ✅ K8s 6 工具 + SSH 15 工具都在(能做就是沒接線) | 從 2026-04-11 commit `325b3851` 起死了 **3 天**。統帥今天真的點了「查程序」結果完全沒反應 → **信任破壞**。 --- ## 決策 ### 立刻執行(A 下架) **臨時對策**:`_CATEGORY_BUTTONS: dict = {}` 改空 dict → fallback 通用按鈕(approve/reject/silence/detail/history/reanalyze)。 **影響**: - 所有 TYPE-3 審核卡只顯示 6 個通用按鈕(已驗證全部 ✅) - 零破壞:approve/reject 通道正常工作 - 信任修復:用戶不會再點到無反應的鬼魂按鈕 ### 後續計畫(B Phase 5) **Phase 5「分類按鈕完整化」**納入 MASTER 藍圖,估 3-5 天。 #### Phase 5 工作分解 | Sprint | 內容 | 估時 | |--------|------|------| | 5.1 | 設計 `action → MCP method` 對應表(每個按鈕寫規格)| 0.5 天 | | 5.2 | 查類按鈕實作(無副作用):`check_process`/`check_port`/`check_log`/`check_health`/`open_signoz`/`open_flywheel` | 1 天 | | 5.3 | 寫類按鈕實作(有副作用):`restart`/`scale_up`/`scale_down`/`rollback`/`restart_service`/`clear_log`/`reload_nginx`/`renew_cert` | 2 天 | | 5.4 | 資安按鈕(secops_isolate/block_ip/evict/authorize)| 0.5 天 | | 5.5 | E2E 測試:click → action → MCP → result reply 完整鏈 | 1 天 | **總計**:3-5 天(依資源) #### 每個按鈕的 checklist 每個分類按鈕上線前必須: - [ ] callback_data 格式通過 `_security.parse_callback_data()` 驗證 - [ ] dispatch handler 新增 `elif action == "xxx":` 分支 - [ ] 呼叫的 MCP method 存在且可用 - [ ] 寫類按鈕有 nonce + audit log - [ ] E2E 測試涵蓋 click → action → result reply 完整鏈 ### 設計原則(永久) > **寧可沒按鈕,不可有死按鈕**。 - 沒按鈕 → 用戶知道要手動處理,正確預期 - 死按鈕 → 用戶以為能自動處理,點了沒反應 → 信任毀掉 --- ## 結果 - ✅ Commit `XXXXX`:`_CATEGORY_BUTTONS = {}` 下架 28 個鬼魂 - ✅ Memory `feedback_no_ghost_buttons.md` 建立(鐵律文件化) - ⏳ Phase 5 排入 MASTER 藍圖,待資源分配 --- ## 教訓 1. **PR Review 漏網**:ADR-075 commit 只加了按鈕定義,沒 Review callback_data 格式 vs parser 規則 2. **缺少 E2E 測試**:單元測試只驗「按鈕產生」,沒驗「點擊後完整流程」 3. **ADR 規格不完整**:ADR-075 只說「新增 _CATEGORY_BUTTONS」,沒規格化「每個按鈕對應的 action handler + MCP method」 4. **信任成本**:任何面向用戶的 UI 元素,功能與可見性必須一致 — 這是 SRE 產品化的核心 --- *Accepted by 統帥 @ 2026-04-14 台北深夜*