ADR 0002: 從獨立 Web App 到 MCP (Model Context Protocol) 擴充的典範轉移¶

Context (背景脈絡)¶

Time Compass 第一版 (v1) 是使用 Gradio 作為前端、DSPy 作為 LLM Pipeline、FastAPI 為後端的龐大獨立應用程式 (Standalone App)。這套架構運作良好，但存在四個致命痛點： 1. 啟動摩擦力高：學生壓力大時，要求他們開啟全新網頁、登入、生成長篇報告，門檻過高。 2. 對話狀態負擔：後端需要花費大量程式碼維護使用者的對話歷史 (Session State)、使用者管理等「非核心排程功能」。 3. 高昂 Token 成本：所有對話都需消耗部署者或使用者輸入的 API Key 額度。 4. 難以與 IDE 整合：開發者在寫 Code 時焦慮，需要立刻排程，獨立網頁無法無縫嵌入工作流中。

Decision (技術決策)¶

全面揚棄獨立 Web 服務與 DSPy 代理層，將 Time Compass 降級重構為一個遵守 Model Context Protocol (MCP) 的 Tool Provider。 所有視覺化呈現退居第二線，透過 MCP 的工具呼叫啟動微型前端 (Planner Studio)。

Consequences (決策結果)¶

Positive (優點)¶

零摩擦力體驗：系統直接寄生於 Cursor / Claude 等現存的 AI IDE。使用者在原本對話的主介面中即可下令排程。
狀態管理外包：完全省去了維護對話歷史與 Session 的程式碼，這些通通交給了 MCP Host (如 Claude) 負責。
成本轉移：消耗的是使用者本身 IDE/AI 服務的訂閱額度，而非依賴本專案維護的免費 API_KEY。
更精純的專注力：整個專案得以砍掉 40% 處理 UI 與狀態的冗餘程式碼，全心致力於資料流處理與排程演算法 (Library 端)。

Negative (缺點)¶

受限於宿主能力：使用體驗高度取決於 MCP Host 的實作 (例如某些 Host 無法渲染複雜介面，故我們開發了 Planner Studio 進行彌補)。
部署難度增加：MCP 對於非技術開發者的初始安裝相對陌生，需要依賴 Node.js (npx) 與命令列介面運作。