[Bug]: SSE connection instability and incorrect entry point in Docker image

[eouzoe]

關於 PromptX MCP Server 容器化部署的相容性與路徑問題反饋
一、 遇到的核心問題 (The Issues)
SSE 模式頻繁 500 錯誤：

在 Docker/Podman 環境下啟動後，使用 MCP Inspector 或前端連線時，伺服器頻繁拋出 500 Internal Server Error，導致連線被中斷。這讓基於 HTTP 的 SSE 傳輸方式幾乎無法在容器環境穩定使用。

文件路徑與實際鏡像結構不符：

官方文檔或常見習慣引導用戶尋找 /app/dist/index.js，但實際在容器內，該專案是被當作全域 Node 模組安裝的，真實路徑為： /usr/local/lib/node_modules/@promptx/mcp-server/dist/index.js

這導致用戶在嘗試改用 STDIO（本地標準流）模式連線時，會因為找不到模組而失敗。

STDIO 模式無響應 (Hang)：

即便手動指定了正確的路徑執行 node index.js 並透過標準輸入餵入 JSON-RPC 指令（如 tools/list），伺服器依然沒有任何輸出回傳，程式直接卡死（Hang），必須手動 Ctrl+C 中斷。這說明 STDIO 模式在當前封裝下可能未正確處理輸入流。

配置目錄初始化缺失：

當掛載空的 /root/.promptx 目錄進容器時，伺服器不會主動初始化預設的專家配置（experts），導致工具列表為空，且缺乏日誌提示。

二、 技術觀察與想法 (Our Findings)
封裝方式問題：鏡像將 MCP Server 安裝在 node_modules 深處，卻沒有在容器根目錄建立軟連結（Symbolic Link），也沒有設定正確的 WORKDIR 或 ENTRYPOINT，這對「需要呼叫二進位制/腳本」的 STDIO 模式非常不友善。

STDIO 處理邏輯可能被 SSE 阻斷：懷疑程式碼入口點（index.js）過度依賴 Hono 或其他 web 框架的生命週期，導致在純 STDIO 環境下無法正常初始化或輸出。

環境變數依賴：伺服器可能依賴特定的環境變數來決定運行模式，但在容器文檔中並未詳細說明。

三、 給開發團隊的改進建議 (Suggestions)
規範鏡像目錄結構：

建議在 Dockerfile 中增加 RUN ln -s /usr/local/lib/node_modules/@promptx/mcp-server /app，讓路徑回歸直覺。

修復 STDIO 連線能力：

確保 dist/index.js 在接收到 stdin 指令時能正確響應。目前這部分完全無法在容器內透過 docker exec -i 調試。

完善自動初始化機制：

啟動時若檢測到 .promptx 目錄為空，應自動寫入預設的 experts 設定檔，而不是讓 Server 空跑。

提供明確的 STDIO 啟動範例：

在 README 中增加容器版 STDIO 的配置範例，這對於 OpenCode 或 Claude Desktop 使用者至關重要。

你好，我在測試 PromptX 的容器版本時發現，SSE 模式不穩定且頻繁報 500 錯誤。轉向 STDIO 模式調試時發現 index.js 的路徑隱藏在全域 node_modules 中，且即便找到路徑，STDIO 也無法正確響應 JSON-RPC 指令。希望團隊能優化鏡像結構並修復 STDIO 的輸入輸出邏輯，方便我們在本地開發工具中整合，謝謝