CFDivePlatform/docs/analysis/2026-06-11-future-roadmap-feasibility.md

CFDivePlatform 未來發展可行性評估

評估日期：2026-06-11 前提：核心閉環（瀏覽 → 預約 → 聊天 → 完課 → 評價）已完成並歸檔；本文評估下一階段候選項目的可行性、依賴與建議順序。 搭配閱讀：《2026-06-11-spec-implementation-audit.md》（修補計畫應先於所有新功能執行，尤其 P0-1）。

---

一、候選項目總覽

#	項目	可行性	預估工時	商業價值	建議優先序
1	教練審核流程（完整版）	高	3~5 天	高（信任基礎）	★ 第 1
2	金流整合（綠界/藍新）	中高	8~12 天	極高（變現核心）	★ 第 2
3	即時聊天室 VPS 部署驗收	高	0.5~1 天	中（已開發未交付）	隨時可做
4	CI/CD（Gitea Actions）修復	中	1~2 天	中（工程效率）	金流前必做
5	課程搜尋強化（地區/價格/日期篩選）	高	2~3 天	中高	第 3
6	行動端體驗（PWA）	中	5~8 天	中	觀望

---

二、逐項評估

2.1 教練審核流程（完整版）— 可行性：高

現況基礎：provider_profiles.is_verified 欄位、Admin toggle-verified 端點、Admin Panel UI 均已存在；缺的是審核「流程」與約束力（見稽核報告 P1-1）。

範圍建議：

1. 教練註冊後狀態為 pending_review（建議將 boolean is_verified 升級為 enum verification_status：pending / approved / rejected）。
2. 證照/資料上傳：複用既有 CourseImageController 的檔案處理模式（local storage，已有上傳驗證先例）。
3. Admin 審核佇列頁 + 通過/駁回（含駁回原因），複用既有 Admin Panel 的列表/操作 UI 模式。
4. 審核結果通知：複用 notification-core + notification-email 既有管線，只需新增 Notification class 與 trigger。

技術風險：低。所有積木（檔案上傳、通知、Admin UI、權限 middleware）都已存在，純組裝工作。 主要決策點：未通過審核的教練能做到哪一步（可登入編輯資料但不可上架？完全不可登入？）——需產品決策，建議前者。 依賴：先完成稽核報告 T2.1（最小語意），再擴充為完整流程，避免重工。

2.2 金流整合 — 可行性：中高（工程可行，依賴外部申請流程）

金流商比較（台灣市場）：

面向	綠界 ECPay	藍新 NewebPay
申請門檻	個人/公司皆可，測試環境免申請即用	偏好公司戶，測試環境需註冊
文件/社群資源	Laravel 套件與範例多（生態最成熟）	文件完整但第三方資源較少
手續費	信用卡約 2.75%~	相近
結論	建議首選，沙箱即開即用、整合範例多	備選

對現有架構的影響（這是工時主要來源）：

1. 預約狀態機需擴充：現有七狀態未含付款概念，需插入 awaiting_payment、paid 等狀態或建立獨立 payments 資料表（建議後者：獨立 Payment model + 與 Booking 一對多，狀態機改動最小，符合開放封閉原則）。
2. Webhook 端點：綠界以 server-side POST 回傳付款結果，需公開端點 + CheckMacValue 驗證 + 冪等處理（重複通知不可重複入帳）——此為資安重點，須走 CLAUDE.md 安全確認流程。
3. 退款政策：取消預約的退款規則（全額/比例/不退）是產品決策，直接影響狀態機與對帳邏輯，須在開工前定案。
4. 金額快照：現有 booking 已記錄價格快照（booking-lifecycle 規格），付款金額有可靠依據，這是現成優勢。

前置條件：

• 確定金流商並取得測試商店（綠界沙箱可立即取得）。
• 退款政策定案。
• 稽核報告 P0-1 必須先修（金流上線後，管理端漏洞的損害會從資料外洩升級為金錢損失）。
• 建議 CI 先行（2.4），金流程式碼回歸成本高，不應依賴手動測試。

工時拆解（粗估）：Payment model + 狀態整合 3 天、ECPay 串接與 Webhook 3 天、前端付款流程 2 天、測試（含冪等與失敗路徑）2~4 天。

2.3 即時聊天室 VPS 部署驗收 — 可行性：高

程式碼已 merge（commit 5ba598c 後系列），記憶中部署狀態未確認。剩餘工作為運維執行：rebuild frontend、restart reverb、.env 五個值（細節在既有部署清單中）。建議排入下次部署窗口一次完成，避免長期掛著「已完成未交付」狀態。

2.4 CI/CD（Gitea Actions）修復 — 可行性：中

已知 runner 的 self-hosted 標籤問題尚未解決。價值在於：測試套件已有 97 案例且將隨修補計畫 Phase 3 成長，沒有 CI 的測試套件會逐漸失去約束力。建議在金流開工前修復，作為金流開發的安全網。風險：Gitea runner 在 Windows/Docker 環境的相容性問題可能再耗時，若兩天內無法解決，備案是改用簡單的 pre-push hook 或部署前手動 gate。

2.5 課程搜尋強化 — 可行性：高

現有 GET /api/diving-offers 已支援關鍵字與分頁；擴充地區/價格區間/可預約日期篩選屬增量開發。注意事項：日期篩選需 join schedules 並留意 N+1 與索引（db-index-optimization 規格已有索引設計先例可循）；快取層（api-cache-layer）的 cache key 需納入新篩選參數。

2.6 行動端 PWA — 可行性：中，建議觀望

Vue 3 + Vite 加 PWA plugin 技術上直接，但通知推播（Web Push）與 iOS 限制會吃掉多數工時，且現階段使用者基數未驗證。建議待金流上線、有真實流量後再評估。

---

三、建議路線圖

Week 1      修補計畫 Phase 1~4（P0 封鎖 + 規格同步 + 預約測試）
            └─ 並行：聊天室 VPS 部署驗收（2.3）
Week 2      教練審核流程完整版（2.1）＋ CI 修復（2.4）
Week 3~4    金流整合（2.2）：Payment model → ECPay 沙箱 → Webhook → 前端
Week 5      金流測試強化 + 課程搜尋強化（2.5）

關鍵判斷：

1. 教練審核排在金流之前——付費平台上架未經審核的教練，發生糾紛時平台責任更重；審核機制是金流的信任前提。
2. 金流是唯一含外部依賴（商店申請、Webhook 公網可達性）的項目，沙箱申請應在 Week 1 就先送出，與其他工作並行等待。
3. 所有新功能開工前，稽核報告的 P0-1（admin register 漏洞）必須先關閉。

四、不建議現在做的事

• 微服務化 / 抽換架構：單體 Laravel 在現階段流量下完全足夠，拆分只會增加部署與除錯成本。
• 多金流商抽象層：先用介面包一層 PaymentGatewayContract 即可（依賴反轉），但不要實作第二家金流——沒有需求前是投機性程式碼（違反 Simplicity First）。
• 評價 AI 審核 / 推薦系統：資料量不足，無訓練與評估基礎。