a620906209
aeb8c975e2
P0 漏洞：原 POST /api/admin/register 無任何防護，任何人可註冊管理員帳號。 - 移除路由、AuthController::registerAdmin、對應 Swagger 文件 - 新增 app:create-admin artisan command（密碼門檻 min:8） - 補 AdminAccountCreationTest 防止端點被重新打開 - 同步 admin-auth 規格，並收錄 2026-06-11 稽核報告與路線圖文檔 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
101 lines
6.9 KiB
Markdown
101 lines
6.9 KiB
Markdown
# 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 審核 / 推薦系統**：資料量不足，無訓練與評估基礎。
|