From 99cf35c1ec165d8261cc7bf11a792b8ac739d377 Mon Sep 17 00:00:00 2001 From: Hank Date: Thu, 11 Jun 2026 19:06:34 +0800 Subject: [PATCH] =?UTF-8?q?docs:=20=E7=A8=BD=E6=A0=B8=E6=96=87=E6=AA=94?= =?UTF-8?q?=E6=94=B9=E7=82=BA=E5=9F=B7=E8=A1=8C=E7=B4=80=E9=8C=84=E3=80=81?= =?UTF-8?q?=E9=96=8B=20provider-verification-gaps=20change=20=E8=A6=8F?= =?UTF-8?q?=E5=8A=83=E9=81=BA=E7=95=99=E7=BC=BA=E5=8F=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 稽核報告：已完成的修補計畫改寫為執行紀錄（commit 對照表 + 偏差說明）， 未處理事項收斂為三項（verification 缺口 / 效能優化 / 新功能路線圖） - 新 change provider-verification-gaps：規劃 schedules/reviews 公開子端點 過濾與預約入口檢查（含「既有預約不受影響」政策決定），待實作 Co-Authored-By: Claude Fable 5 --- .../2026-06-11-spec-implementation-audit.md | 136 ++++++------------ .../provider-verification-gaps/.openspec.yaml | 2 + .../provider-verification-gaps/design.md | 26 ++++ .../provider-verification-gaps/proposal.md | 30 ++++ .../specs/provider-verification/spec.md | 29 ++++ .../provider-verification-gaps/tasks.md | 19 +++ 6 files changed, 146 insertions(+), 96 deletions(-) create mode 100644 openspec/changes/provider-verification-gaps/.openspec.yaml create mode 100644 openspec/changes/provider-verification-gaps/design.md create mode 100644 openspec/changes/provider-verification-gaps/proposal.md create mode 100644 openspec/changes/provider-verification-gaps/specs/provider-verification/spec.md create mode 100644 openspec/changes/provider-verification-gaps/tasks.md diff --git a/docs/analysis/2026-06-11-spec-implementation-audit.md b/docs/analysis/2026-06-11-spec-implementation-audit.md index 3ff1c89..0f15f1e 100644 --- a/docs/analysis/2026-06-11-spec-implementation-audit.md +++ b/docs/analysis/2026-06-11-spec-implementation-audit.md @@ -1,8 +1,9 @@ -# CFDivePlatform 規格與實作分析報告暨修補計畫 +# CFDivePlatform 規格與實作分析報告暨修補紀錄 > 分析日期：2026-06-11 > 分析範圍：`openspec/specs/`（32 份規格）vs 後端實作（Laravel 11）、前端（`frontend/` Vue 3）、測試（`tests/`） -> 分析基準：branch `test/auth-tests-coverage`（commit ca5b843，與 master 同步） +> 分析基準：branch `test/auth-tests-coverage`（commit ca5b843） +> **狀態更新（2026-06-11）**：修補計畫四階段已全部完成於 branch `fix/audit-remediation`（PR #28），本文件保留發現紀錄與執行結果，未完成事項見第四節。 --- @@ -10,131 +11,74 @@ ### 1.1 規格狀態 -- OpenSpec 規格共 **32 份**，全部 change 已歸檔（`openspec/changes/` 僅剩 `archive/`，無進行中 change）。 +- OpenSpec 規格共 **32 份**（修補後 33 份，新增 `provider-verification`），全部 change 已歸檔。 - 涵蓋範圍：認證安全（lockout / rate-limiting / OAuth state / token refresh）、三角色入口（Member / Coach / Admin）、預約生命週期、評價系統、通知系統、即時聊天、Swagger 文件、效能優化。 -### 1.2 實作狀態 +### 1.2 實作狀態（修補後） | 模組 | 規格 | 實作 | 測試 | |------|------|------|------| -| 認證（三角色登入/註冊/登出） | ✅ | ✅ | ✅ 39 案例 | -| 帳號鎖定 + OAuth state | ✅ | ✅ | ✅ 15 案例 | -| Token Refresh | ✅ | ✅ | ✅ 11 案例 | -| 課程 CRUD + 圖片上傳 | ✅ | ✅ | ✅ 14 案例 | -| 開課時段管理 | ✅ | ✅ | ❌ 無 | -| 預約生命週期（七狀態機、防超賣、Scheduler） | ✅ | ✅ | ❌ 無 | -| 評價系統（匿名、投票、rating 重算） | ✅ | ✅ | ✅ 32 案例 | -| 通知系統（站內 + Email） | ✅ | ✅ | ❌ 無 | -| 即時聊天 + Presence | ✅ | ✅ | ❌ 無 | -| Admin 管理端點（stats / users / offers / bookings / reviews） | ✅ | ✅ | ❌ 無 | -| 教練審核流程 | ❌ 無規格 | ⚠️ 僅半套（見 P1-1） | ❌ 無 | -| 金流整合 | ❌ 無規格 | ❌ 未實作 | — | - -整體而言規格與實作的對應度高，路由、端點、middleware 配置大致與規格一致。以下列出本次稽核發現的偏差與風險。 +| 認證（三角色登入/註冊/登出） | ✅ | ✅ | ✅ | +| 帳號鎖定 + OAuth state | ✅ | ✅ | ✅ | +| Token Refresh | ✅ | ✅ | ✅ | +| 課程 CRUD + 圖片上傳 | ✅ | ✅ | ✅ | +| 預約生命週期（七狀態機、防超賣、Scheduler） | ✅ | ✅ | ✅（修補新增 26 案例） | +| 評價系統 | ✅ | ✅ | ✅ | +| 通知系統 | ✅ | ✅ | ⚠️ 僅 Scheduler 路徑覆蓋 | +| 即時聊天 + Presence | ✅ | ✅ | ✅（授權路徑，修補新增 8 案例） | +| Admin 管理端點 | ✅ | ✅ | ✅（權限邊界，修補新增 5 案例） | +| 教練驗證（is_verified 最小語意） | ✅（修補新增） | ✅ | ✅（7 案例） | +| 教練審核流程（完整版） | ❌ 無規格 | ❌ | — | +| 金流整合 | ❌ 無規格 | ❌ | — | --- -## 二、發現問題（依嚴重度排序） +## 二、稽核發現（保留原始紀錄，狀態見第三節） ### 🔴 P0-1：`POST /api/admin/register` 完全公開，任何人可註冊管理員帳號 -- **位置**：`routes/api.php:106`、`AuthController::registerAdmin()`（`AuthController.php:852`） -- **事實**：該路由無任何 middleware、無邀請碼、無「僅限第一位管理員」檢查；request 通過基本驗證後直接 `role => 'admin'` 建立帳號。 -- **影響**：攻擊者一個 HTTP 請求即可取得全平台管理權限（停權用戶、刪課程、刪評價、看全部個資），**使 P0~P2 所有認證安全強化形同虛設**。 -- **規格對應**：`admin-auth` 規格只定義「管理員登入」，**從未定義公開註冊端點**——此端點本身就是規格外實作。 -- **附帶問題**：密碼規則僅 `min:6`，低於一般管理帳號標準。 +- 該路由無任何 middleware、無邀請碼；request 通過基本驗證後直接 `role => 'admin'` 建立帳號。攻擊者一個 HTTP 請求即可取得全平台管理權限。`admin-auth` 規格從未定義此端點（規格外實作）。 ### 🟠 P1-1：`is_verified`（教練驗證）從未被任何業務邏輯強制執行 -- **事實**：`is_verified` 只出現在兩處——Admin 的 `toggleProviderVerified()`（`AdminUserController.php:144`）與 Model 屬性定義。教練**註冊後不需任何審核即可登入、上架課程、被公開列表曝光、接受預約**。 -- **影響**：Admin 後台的「驗證教練」開關是純展示功能，平台對教練資質零把關。這就是記憶中「教練審核流程未實作」的實際狀態：開關存在、約束不存在。 -- **規格對應**：目前**沒有任何規格**定義 `is_verified` 的業務語意（未驗證教練能做什麼/不能做什麼），屬規格空洞。 +- `is_verified` 只有 Admin toggle 開關與 Model 屬性，教練註冊後不需任何審核即可上架、曝光、接單。無任何規格定義其業務語意。 ### 🟠 P1-2：登入頻率限制規格與實作不一致（規格漂移） -- **規格**（`openspec/specs/login-rate-limiting/spec.md`）：Member / Provider 每 IP 每分鐘最多 **5 次**。 -- **實作**（`routes/api.php:31,67`）：`throttle:10,1`，即 **10 次**。 -- **測試**（`AuthRateLimitTest.php`）：已在 commit 0dabc4e 改為斷言 10 次，**與實作一致、與規格矛盾**。 -- **影響**：規格失去單一真實來源（single source of truth）地位。未來任何人依規格實作或稽核都會得出錯誤結論。Admin 的 3 次限制則規格實作一致。 +- 規格寫 Member/Provider 5 次/分鐘，實作 `throttle:10,1`，測試（commit 0dabc4e）已配合實作改為 10 次，規格未同步。 ### 🟡 P2-1：核心業務流程（預約）零測試覆蓋 -- 現有 97 個測試案例集中在認證（70）、評價（32 中含投票）、圖片（14）。 -- **預約狀態機（七狀態）、防超賣鎖定、Scheduler 自動過期/完成**（`ExpirePendingBookings`、`CompleteFinishedBookings`）——平台最核心、含金量最高、最容易因修改而回歸的邏輯——**沒有任何一條測試**。 -- 同樣無測試：時段管理（時段重疊/容量）、通知觸發、聊天授權（presence channel 參與方驗證）、全部 Admin 端點（含 P0-1 的權限邊界）。 -- 依 CLAUDE.md Rule 9，這些測試需編碼「為什麼」：防超賣測試保護的是金錢與信任，狀態機測試保護的是不可逆操作的合法轉移。 +- 預約狀態機、防超賣鎖定、Scheduler 自動過期/完成沒有任何測試；時段管理、通知觸發、聊天授權、Admin 端點亦無。 ### 🟡 P2-2：規格維護債 -1. `auth-test-coverage/spec.md` 的 Purpose 仍是 `TBD - created by archiving change`，歸檔後未補。 -2. `member-portal-ui` 規格寫「前端 SHALL 建立於獨立 repo」，實際前端在本 repo 的 `frontend/` 目錄——規格描述已過時。 -3. `admin-auth` 規格未涵蓋實際存在的 `/admin/register`、`/admin/check-member/{id}`、`/admin/check-provider/{id}` 端點。 +- `auth-test-coverage` Purpose 為 TBD；`member-portal-ui` repo 描述過時；`admin-auth` 未涵蓋 check-member / check-provider 端點。 --- -## 三、修補計畫 +## 三、修補執行紀錄（2026-06-11 全部完成） -### Phase 1 — 立即（建議今天，0.5 天內） +分支 `fix/audit-remediation`（基底 `test/auth-tests-coverage`，PR #28），容器內全套件 **146 passed / 378 assertions**。 -**T1.1 封鎖 `POST /api/admin/register`**（對應 P0-1） +| 對應發現 | 修補內容 | Commit | +|---------|---------|--------| +| P0-1 | 移除公開 admin/register（路由/controller/Swagger），新增 `php artisan app:create-admin`（min:8），`AdminAccountCreationTest` 4 案例，`admin-auth` 規格補「帳號建立途徑」 | aeb8c97 | +| P1-2 | `login-rate-limiting` 規格同步至 10/min（以實作為準，註記放寬理由） | 88a81aa | +| P1-1 | `DivingOffer::visibleToPublic` scope（公開 index/show 過濾未驗證教練課程）、toggle-verified 後 flush 快取、新增 `provider-verification` 規格、`DivingOfferVisibilityTest` 7 案例 | 3c38d08 | +| P2-1 | 預約核心 39 案例：狀態機 17、防超賣 3、Scheduler 6、聊天授權 8、Admin 權限邊界 5 | 63b25f9 | +| P2-2 | 規格清理（Purpose / repo 描述 / 查詢端點）+ 同步移除測已刪端點的 2 個舊測試 | d3a0d30, cec2078 | +| — | OpenSpec 補歸檔 `2026-06-11-audit-remediation`（proposal / design / tasks / 規格增量） | a97a7d0 | -建議方案（擇一，建議 a）： -- (a) **移除公開路由**，改為 artisan command `php artisan admin:create`（僅能從主機執行），生產環境的管理員一律由既有管理員或主機端建立。 -- (b) 移入 `auth:sanctum + admin` middleware group（僅既有 admin 可開新 admin）——但需先用 (a) 或 seeder 解決第一位管理員的雞生蛋問題。 +**與原計畫的偏差**：原計畫建議「Demo seeder 將教練預設 `is_verified=true`」，實際保留 seeder 中 1 位未驗證教練——其課程從公開列表消失正好展示新規則，屬刻意決策（記錄於 PR #28 說明）。 -驗收標準： -- [ ] 未認證請求 `POST /api/admin/register` 回傳 404 或 401（不再是 201）。 -- [ ] 補 Feature test：未授權者無法建立 admin 帳號。 -- [ ] Demo seeder 既有的 admin 帳號不受影響。 -- [ ] 同步新增/更新 `admin-auth` 規格段落，明確定義管理員帳號建立途徑。 +## 四、尚未處理事項 -**T1.2 解決 rate-limiting 規格漂移**（對應 P1-2） - -- 先決定基準：5/min（規格）或 10/min（實作）。10/min 是後來有意調整（測試已配合修改），建議**以實作為準、更新規格**；若當初是誤改，則改回 5 並還原測試。 -- 驗收標準：規格、`routes/api.php`、`AuthRateLimitTest` 三者數字一致。 - -### Phase 2 — 短期（1~2 天） - -**T2.1 賦予 `is_verified` 最小業務語意**（對應 P1-1，為完整教練審核流程鋪路） - -最小可行約束（不做完整審核流程，僅堵住風險）： -- 未驗證 Provider 的課程不出現在公開列表 `GET /api/diving-offers`（或：未驗證 Provider 無法將課程上架/`store()` 回 403，二擇一，依產品決策）。 -- 課程詳情頁顯示教練 `is_verified` 徽章（前端已有欄位可用）。 -- 驗收標準： - - [ ] 新增規格 `provider-verification`（最小版），定義未驗證教練的能力邊界。 - - [ ] Feature test：未驗證教練的課程不可被公開查詢（或不可建立）。 - - [ ] Admin `toggle-verified` 後行為立即生效（注意 `api-cache-layer` 的快取失效）。 - -> 完整審核流程（證照上傳、審核佇列、駁回原因）屬新功能，見《未來發展可行性評估》文檔。 - -### Phase 3 — 中期（2~3 天） - -**T3.1 補預約核心測試**（對應 P2-1，優先序由高至低） - -1. `BookingLifecycleTest`：七狀態機合法/非法轉移（pending→confirmed→completed、reject、cancel、不可逆狀態防護）。 -2. `BookingOversellTest`：併發/邊界情境下 confirmed 不超過時段容量；pending 不佔名額。 -3. `BookingSchedulerTest`：`app:expire-pending-bookings` 與 `app:complete-finished-bookings` 的時間邊界。 -4. `BookingChatAuthTest`：非參與方無法讀寫訊息、無法訂閱 presence channel。 -5. `AdminEndpointTest`：非 admin token 存取 `/api/admin/*` 一律 403。 - -驗收標準：以上測試全綠且任一狀態機規則被改壞時至少一條測試會失敗（mutation 自查）。 - -### Phase 4 — 規格清理（0.5 天，可與 Phase 3 並行） - -- [ ] 補 `auth-test-coverage` 的 Purpose。 -- [ ] 更新 `member-portal-ui` 的 repo 描述。 -- [ ] `admin-auth` 補 `check-member` / `check-provider` 端點描述（`register` 端點依 T1.1 決策寫入或標記移除）。 - ---- - -## 四、風險與依賴 - -| 項目 | 風險 | 緩解 | -|------|------|------| -| T1.1 | 前端 Admin 註冊頁（若存在）會失效 | 檢查 `frontend/src/views/admin/`，同步移除入口 | -| T2.1 | 公開列表過濾可能影響 demo 資料展示 | Demo seeder 將教練預設 `is_verified=true` | -| T3.1 | 測試需 MySQL 容器運行 | 沿用既有 `php artisan test` 容器內流程 | +1. **provider-verification 已知限制**（規格 Notes 已載明）：`GET /api/diving-offers/{id}/schedules`、`GET /api/diving-offers/{id}/reviews` 與預約建立流程尚未套用可見性過濾，知道課程 id 仍可間接互動。 + → **已開 OpenSpec change `provider-verification-gaps` 規劃**（`openspec/changes/provider-verification-gaps/`），待實作。 +2. **操作體驗優化**：見 `docs/analysis/2026-06-11-performance-optimization-plan.md`（O1.1 啟用 OPcache 起步），尚未實施。 +3. **新功能路線圖**：教練審核完整版、金流整合等，見 `docs/analysis/2026-06-11-future-roadmap-feasibility.md`。 ## 五、規格同步狀態聲明 -本報告本身不改動程式碼。執行修補計畫時需同步的規格文件：`admin-auth`（T1.1）、`login-rate-limiting`（T1.2）、新增 `provider-verification`（T2.1）、`auth-test-coverage` 與 `member-portal-ui`（Phase 4）。 +修補已同步的規格：`admin-auth`、`login-rate-limiting`、`auth-test-coverage`、`member-portal-ui`、新增 `provider-verification`；變更軌跡歸檔於 `openspec/changes/archive/2026-06-11-audit-remediation/`。 diff --git a/openspec/changes/provider-verification-gaps/.openspec.yaml b/openspec/changes/provider-verification-gaps/.openspec.yaml new file mode 100644 index 0000000..e0c0898 --- /dev/null +++ b/openspec/changes/provider-verification-gaps/.openspec.yaml @@ -0,0 +1,2 @@ +schema: spec-driven +created: 2026-06-11 diff --git a/openspec/changes/provider-verification-gaps/design.md b/openspec/changes/provider-verification-gaps/design.md new file mode 100644 index 0000000..d57523b --- /dev/null +++ b/openspec/changes/provider-verification-gaps/design.md @@ -0,0 +1,26 @@ +# Design — provider-verification-gaps + +## D1：預約入口擋在哪一層 + +候選： +- (a) `MemberBookingController::store` 的 Layer 1 快速失敗區（採用）——載入 `$schedule->divingOffer.provider.providerProfile` 後檢查，與既有「時段不開放」「名額不足」的 422 錯誤同層、同風格 +- (b) `CourseSchedule` 加 scope——過度設計，時段本身沒有可見性概念，可見性屬於課程 + +回應訊息建議與既有風格一致：`['status' => false, 'message' => '此課程目前不開放預約']`，HTTP 422。不用 404：schedule id 是真實存在的資源，422 表達「請求合法但業務上不可行」。 + +## D2：既有預約不受影響（關鍵政策決定） + +教練被取消驗證（toggle off）時： +- **新預約**：擋（本 change 範圍） +- **既有 pending**：教練仍可 confirm／reject——合約協商已開始，平台不單方面撕毀；若要更嚴格（pending 也凍結），屬產品決策，本 change 不做 +- **既有 confirmed / completed**：聊天、完課、評價全部照常——會員已付出時間成本，懲罰應落在教練（不能接新單）而非會員 + +此政策需寫入規格 scenario，避免未來誤解為漏洞。 + +## D3：visibleToPublic 的查詢成本 + +`schedules` / `reviews` publicList 由 `findOrFail($offerId)` 改為 `visibleToPublic()->findOrFail($offerId)`，多一個 `whereExists` 子查詢（provider→providerProfile），單筆 by-id 查詢成本可忽略；兩端點目前無快取，無一致性問題。`store` 的檢查在 transaction 之外的 Layer 1 即可（教練驗證狀態變動頻率極低，不需要鎖）。 + +## D4：測試歸屬 + +擴充既有 `DivingOfferVisibilityTest`（同一保護目標：可見性），不另開檔案；預約入口的測試放 `BookingLifecycleTest`（屬建立預約的前置條件），各加 3~4 案例。 diff --git a/openspec/changes/provider-verification-gaps/proposal.md b/openspec/changes/provider-verification-gaps/proposal.md new file mode 100644 index 0000000..ddfc8a6 --- /dev/null +++ b/openspec/changes/provider-verification-gaps/proposal.md @@ -0,0 +1,30 @@ +## Why + +2026-06-11 修補（archive: `2026-06-11-audit-remediation`）讓未驗證教練的課程從公開 `GET /api/diving-offers`（列表/詳情）消失，但 `provider-verification` 規格 Notes 載明三個遺留缺口： + +1. `GET /api/diving-offers/{id}/schedules`（公開時段列表）未過濾——知道課程 id 仍可查到可預約時段 +2. `GET /api/diving-offers/{id}/reviews`（公開評價列表）未過濾——隱藏課程的評價仍可讀取 +3. `POST /api/member/bookings` 未檢查——會員可直接以 `schedule_id` 預約未驗證教練的課程，繞過整個可見性機制 + +缺口 3 最關鍵：可見性過濾的目的（平台對教練資質把關）在預約入口被完全繞過。 + +## What Changes + +- `ScheduleController::publicList`：`DivingOffer::findOrFail` 改為 `DivingOffer::visibleToPublic()->findOrFail`，隱藏課程的時段查詢回 404 +- `ReviewController::publicList`：同上，隱藏課程的評價查詢回 404 +- `MemberBookingController::store`：建立預約前驗證 schedule 所屬課程對該會員「可預約」（課程屬已驗證教練或 `provider_id` 為 null），否則回 422 +- **既有預約不受影響**：教練被取消驗證時，已成立的 pending / confirmed / completed 預約照常運作（含聊天、完課、評價）——只擋新預約，不毀既有合約 +- 補充 Feature tests 並更新 `provider-verification` 規格（Notes 移除、改為正式 Requirements） + +## Capabilities + +### Modified Capabilities + +- `provider-verification`：新增「公開子端點套用相同可見性」與「未驗證教練課程不可建立新預約」requirements；移除 Notes 中的已知限制聲明 + +## Impact + +- 影響檔案：`ScheduleController`、`ReviewController`、`MemberBookingController`、`tests/Feature/DivingOfferVisibilityTest.php`（擴充）或新增測試檔 +- 行為變更：DemoSeeder 未驗證教練的課程時段/評價將不可公開查詢、不可新預約 +- 風險：低——`visibleToPublic` scope 已有 7 條測試保護，本 change 僅擴大套用範圍 +- 不影響：教練自有管理端點（`/api/provider/*`）、Admin 端點、既有預約的聊天與評價流程 diff --git a/openspec/changes/provider-verification-gaps/specs/provider-verification/spec.md b/openspec/changes/provider-verification-gaps/specs/provider-verification/spec.md new file mode 100644 index 0000000..995e184 --- /dev/null +++ b/openspec/changes/provider-verification-gaps/specs/provider-verification/spec.md @@ -0,0 +1,29 @@ +## ADDED Requirements + +### Requirement: 公開子端點套用相同可見性 +課程的公開子端點（`GET /api/diving-offers/{id}/schedules`、`GET /api/diving-offers/{id}/reviews`）SHALL 套用與課程詳情相同的可見性規則：課程屬未驗證教練時回傳 HTTP 404。 + +#### Scenario: 隱藏課程的時段查詢回 404 +- **WHEN** 匿名使用者請求 `GET /api/diving-offers/{id}/schedules`，該課程屬未驗證教練 +- **THEN** 回傳 HTTP 404 + +#### Scenario: 隱藏課程的評價查詢回 404 +- **WHEN** 匿名使用者請求 `GET /api/diving-offers/{id}/reviews`，該課程屬未驗證教練 +- **THEN** 回傳 HTTP 404 + +#### Scenario: 可見課程的子端點正常 +- **WHEN** 課程屬已驗證教練或 `provider_id` 為 null +- **THEN** 時段與評價端點照常回傳資料 + +--- + +### Requirement: 未驗證教練的課程不可建立新預約 +`POST /api/member/bookings` SHALL 在建立預約前驗證 schedule 所屬課程可預約（`provider_id` 為 null 或教練 `is_verified = true`），不符時回傳 HTTP 422，不建立預約。既有預約（pending / confirmed / completed）SHALL 不受教練驗證狀態變動影響：教練仍可處理 pending、confirmed 的聊天與完課流程照常、completed 可正常評價。 + +#### Scenario: 未驗證教練課程的新預約被拒絕 +- **WHEN** 會員以未驗證教練課程的 schedule_id 送出預約 +- **THEN** 回傳 HTTP 422，`{ status: false, message: "此課程目前不開放預約" }`，不建立 Booking + +#### Scenario: 教練被取消驗證後既有預約照常 +- **WHEN** 教練在預約 confirmed 之後被取消驗證 +- **THEN** 該預約的聊天、完課、評價流程照常運作；僅新預約被擋 diff --git a/openspec/changes/provider-verification-gaps/tasks.md b/openspec/changes/provider-verification-gaps/tasks.md new file mode 100644 index 0000000..23f134a --- /dev/null +++ b/openspec/changes/provider-verification-gaps/tasks.md @@ -0,0 +1,19 @@ +## 1. 公開子端點套用可見性 + +- [ ] 1.1 `ScheduleController::publicList`：`DivingOffer::findOrFail($offerId)` → `DivingOffer::visibleToPublic()->findOrFail($offerId)` +- [ ] 1.2 `ReviewController::publicList`：同 1.1 +- [ ] 1.3 [整合測試] `DivingOfferVisibilityTest` 擴充：未驗證教練課程的 `/schedules` 回 404、`/reviews` 回 404、已驗證教練兩端點正常（3~4 案例） + +## 2. 預約入口檢查 + +- [ ] 2.1 `MemberBookingController::store` Layer 1 增加課程可預約檢查（provider_id null 或教練已驗證），不符回 422 `此課程目前不開放預約` +- [ ] 2.2 [整合測試] `BookingLifecycleTest` 擴充：未驗證教練課程的 schedule 不可建立預約（422）、已驗證可預約、教練被取消驗證後既有 confirmed 預約聊天/完課照常（3 案例） + +## 3. 規格同步 + +- [ ] 3.1 `openspec/specs/provider-verification/spec.md`：新增「公開子端點套用相同可見性」「未驗證教練課程不可建立新預約」requirements（含既有預約不受影響 scenario），移除 Notes 已知限制段落 + +## 4. 驗證 + +- [ ] 4.1 容器內 `php artisan test` 全綠（基準：146 passed） +- [ ] 4.2 手動驗證 DemoSeeder 未驗證教練課程：時段/評價查詢 404、無法新預約