# EMPOWER Core 會員系統完整技術盤點

盤點日期：2026 年 7 月 26 日  
盤點分支：`main`  
盤點基準提交：`305dbe9`  
專案路徑：`E:\develop\ruantang\empower-core`

## 1. 盤點方法與判定原則

本報告實際檢查下列證據，不只依賴 README：

- 根目錄、前端、後端、文件、任務文件與 Git 歷史。
- 所有 FastAPI 路由、依賴注入、資料模型、Pydantic schema 與 Alembic 遷移。
- 所有 Next.js 頁面、主要共用元件、API 呼叫與手機版配置。
- 後端 pytest 測試、種子腳本、部署說明與測試帳號文件。
- 前端正式建置、本機開發伺服器、公開後端與資料型 API 的實際回應。

狀態判定如下：

- **已實作**：前後端或資料層存在可辨識的完整程式路徑。
- **部分完成**：只有部分層完成、操作介面未接線，或目前環境無法完成端到端驗證。
- **僅有設計**：只有文件或靜態示意畫面。
- **尚未實作**：找不到資料表、API 與頁面證據。
- **尚未確認**：程式存在，但缺少必要環境、資料或可重現證據。

「程式已實作」與「目前可正常運行」分開判定。

## 2. 專案目錄結構

```text
empower-core/
├─ backend/
│  ├─ app/
│  │  ├─ api/
│  │  │  ├─ deps.py                 # Clerk JWT、當前會員、管理員檢查
│  │  │  └─ routers/                # 身分同步、會員、後台、金鑰、欄位
│  │  ├─ core/                      # 環境設定、資料庫連線
│  │  ├─ models/                    # SQLAlchemy 資料模型
│  │  ├─ schemas/                   # API 輸入輸出驗證
│  │  └─ main.py                    # FastAPI 入口與 CORS
│  ├─ migrations/                   # Alembic 遷移，共 7 份版本檔
│  ├─ scripts/                      # 種子、測試帳號、角色與測試工具
│  ├─ tests/                        # pytest，共收集 7 個測試案例
│  ├─ .env                          # 本機環境變數，已被 Git 忽略
│  └─ requirements.txt
├─ frontend/
│  ├─ src/app/
│  │  ├─ admin/                     # 會員、欄位、系統金鑰後台
│  │  ├─ profile/                   # 個人資料與靜態隱私頁
│  │  ├─ sign-in/、sign-up/         # Clerk 登入／註冊
│  │  └─ page.tsx                   # 公開首頁
│  ├─ src/components/               # 導覽列與 shadcn/ui 元件
│  ├─ middleware.ts                 # 路由登入保護
│  ├─ .env.local                    # 本機環境變數，已被 Git 忽略
│  └─ package.json
├─ doc/                             # 既有環境與測試帳號文件
├─ tasks/                           # 未完成工作與部署／授權設計
├─ docs/member-system-showcase/     # 本次新增成果網站與盤點文件
├─ README.md
└─ ROADMAP.md                       # 本次建立的真實進度來源
```

盤點時專案內沒有 `CLAUDE.md` 或既有 `ROADMAP.md`。缺少專案級維護規範是接手風險；本次未擅自制定新的工程規範，只建立要求中的進度文件。

## 3. 技術架構

### 3.1 前端

- Next.js `14.2.35`，App Router。
- React 18、TypeScript 5。
- Tailwind CSS 3 與 shadcn/ui／Radix UI。
- Clerk Next.js SDK 負責註冊、登入、登出與取得 Bearer Token。
- Vercel Speed Insights 已安裝。
- 手機版包含導覽抽屜、可橫向捲動的頁籤與底部固定儲存按鈕。

### 3.2 後端

- Python 3.12、FastAPI `0.136.1`。
- SQLAlchemy 2 async、asyncpg、Pydantic 2。
- PyJWT 透過 Clerk JWKS 驗證 JWT。
- Svix 驗證 Clerk Webhook 簽章。
- Alembic 管理 PostgreSQL schema。
- httpx 呼叫 Clerk Backend API 執行 ban／unban。

### 3.3 資料庫與外部服務

- PostgreSQL，文件指定 Supabase。
- Clerk 負責身分認證。
- 文件描述的部署組合是：Vercel 前端、Render 後端、Supabase 資料庫、Clerk 身分服務。
- 後端程式使用 `NullPool` 配合 PgBouncer／Supabase pooler。

### 3.4 簡化請求路徑

```text
會員手機
  └─ Next.js 前端
      ├─ Clerk：註冊、登入、JWT
      └─ FastAPI：會員資料、角色、欄位與金鑰規則
          └─ Supabase PostgreSQL：保存會員資料

外部系統
  └─ X-System-Key
      └─ FastAPI 欄位白名單過濾
          ├─ 回傳被允許的會員欄位
          └─ 寫入 AuditLog
```

## 4. 可辨識的系統角色

### 4.1 資料庫角色

`User.role` 目前只有程式約定，未使用資料庫 enum：

- `member`：一般會員。
- `admin`：管理員。

### 4.2 其他使用情境

- 未登入訪客：只允許首頁、登入與註冊路由。
- Clerk Webhook：系統身分，用來同步建立／更新／停用會員。
- 外部系統：以 `SystemKey` 存取指定會員資料。

後端管理 API 使用 `require_admin`，會先驗證 Clerk JWT，再讀取資料庫 `User.role`。前端導覽列也會讀取 `/api/v1/me` 決定是否顯示管理員入口，但真正安全邊界仍在後端。

## 5. 前端頁面盤點

| 路由 | 對象 | 實際內容 | 狀態 |
|---|---|---|---|
| `/` | 公開 | 產品首頁、登入／註冊入口、靜態同步狀態卡 | 已實作；手機預覽成功 |
| `/sign-in` | 公開 | Clerk `SignIn` 元件 | 部分完成；本次實際預覽為空白 |
| `/sign-up` | 公開 | Clerk `SignUp` 元件與條款文字 | 程式已實作；尚未完成實際註冊驗證 |
| `/profile` | 會員 | 轉址到 `/profile/edit` | 已實作 |
| `/profile/edit` | 會員 | 核心資料、工作、學歷、證照、技能與動態欄位 | 程式已實作；資料庫失效，無法端到端驗證 |
| `/profile/privacy` | 會員 | 外部授權與刪除帳號靜態畫面 | 僅有設計；Mock data；選單已隱藏 |
| `/admin/users` | 管理員 | 會員列表、狀態切換、詳情入口 | 程式已實作；資料庫失效 |
| `/admin/users/[id]` | 管理員 | 會員詳情、管理員備註、操作紀錄 | 程式已實作；資料庫失效 |
| `/admin/fields` | 管理員 | 自訂欄位 CRUD | 程式已實作；資料庫失效 |
| `/admin/system-keys` | 管理員 | 金鑰清單、核發、欄位勾選、撤銷 | 程式已實作；資料庫失效 |

### 5.1 前端已確認的功能細節

- 個人資料欄位：真實姓名、顯示名稱、手機、市話、國家、縣市、鄉鎮市區、詳細地址、生日、性別、職涯狀態、自我介紹。
- 經歷模組：最多 10 筆工作經歷、10 筆教育背景、20 筆證照；技能可設定基礎／熟練／專家。
- 國際電話國碼與國家選單，台灣縣市／行政區連動。
- 手機版使用固定底部「儲存設定」按鈕。
- 自訂欄位依後台設定動態產生文字、長文字、數字或日期輸入。

### 5.2 前端不一致或未完成

- README 宣稱自動防抖儲存；實際頁面只在按下「儲存設定」後送出。`useDebounceCallback` 只有匯入，未使用。
- 會員列表有搜尋框，但沒有 state、事件或查詢參數，輸入不會搜尋。
- 會員列表未實作分頁控制，只使用後端預設 `limit=10`，因此可能只顯示前 10 筆。
- 後端有修改角色 API，但前端沒有角色調整操作。
- 隱私頁使用固定 Mock data，刪除按鈕沒有事件與 API。
- 首頁「已連線」「已加密儲存」是固定視覺文案，不是健康檢查；未發現應用層欄位加密實作。
- 部分後台表格採固定欄位寬度，手機體驗可能產生擁擠或橫向內容；本次無法登入做實際行動裝置 QA。

## 6. API 盤點

公開部署的 OpenAPI 在盤點時列出 16 個 path，與程式路由一致。

### 6.1 基礎與身分

| Method | Path | 驗證 | 用途 | 狀態 |
|---|---|---|---|---|
| GET | `/` | 無 | 後端健康訊息 | 可回應 200 |
| POST | `/api/v1/eih/auth/sync` | Svix Webhook 簽章 | 同步 Clerk `user.created`、`user.updated`、`user.deleted` | 已實作；資料庫整合未通過 |
| GET | `/api/v1/me` | Clerk Bearer JWT | 回傳內部會員編號、Clerk ID、狀態與角色 | 已實作；無 Token 時回 401 |

### 6.2 會員資料

| Method | Path | 驗證 | 用途 | 狀態 |
|---|---|---|---|---|
| GET | `/api/v1/profile/me` | Clerk Bearer JWT | 讀取自己的完整個人檔案 | 已實作；缺少停用狀態檢查 |
| PATCH | `/api/v1/profile/me` | Clerk Bearer JWT | 更新自己的標準欄位、經歷與自訂欄位 | 已實作；缺少停用狀態檢查與 AuditLog |
| GET | `/api/v1/profile/{user_id}` | `X-System-Key` | 依金鑰白名單讀取指定會員欄位 | 已實作；無會員逐筆同意 |
| PATCH | `/api/v1/profile/{user_id}/custom-fields` | **無** | 增量更新指定會員自訂欄位 | 已實作但存在嚴重未授權修改風險 |
| GET | `/api/v1/custom-fields` | 無 | 列出所有自訂欄位定義 | 已實作；公開部署目前回 500 |

### 6.3 管理員會員 API

所有下列 API 在 router 層套用 `require_admin`：

| Method | Path | 用途 | 狀態 |
|---|---|---|---|
| GET | `/api/v1/admin/users` | 分頁列出會員；支援 name、email、city、career_status | 已實作；前端未接篩選與分頁 |
| GET | `/api/v1/admin/users/{user_id}` | 會員詳情與最多 50 筆相關 AuditLog | 已實作 |
| PATCH | `/api/v1/admin/users/{user_id}/status` | 啟用／停用，並呼叫 Clerk ban／unban | 已實作；外部呼叫失敗仍會提交本地狀態 |
| PATCH | `/api/v1/admin/users/{user_id}/role` | 更新 `admin`／`member` | API 已實作；前端未實作；輸入未限制 enum |
| PATCH | `/api/v1/admin/users/{user_id}/notes` | 更新管理員內部備註 | 已實作 |

### 6.4 管理員自訂欄位 API

| Method | Path | 用途 | 狀態 |
|---|---|---|---|
| GET | `/api/v1/admin/fields` | 列出欄位 | 已實作 |
| POST | `/api/v1/admin/fields` | 新增欄位 | 已實作 |
| PATCH | `/api/v1/admin/fields/{field_id}` | 修改欄位 | 已實作 |
| DELETE | `/api/v1/admin/fields/{field_id}` | 刪除欄位定義 | 已實作；不會移除既有 Profile JSONB 值 |

### 6.5 管理員系統金鑰 API

| Method | Path | 用途 | 狀態 |
|---|---|---|---|
| GET | `/api/v1/admin/system-keys` | 列出金鑰 metadata | 已實作 |
| POST | `/api/v1/admin/system-keys` | 核發高熵金鑰，明文只回傳一次，資料庫保存 SHA-256 | 已實作 |
| PATCH | `/api/v1/admin/system-keys/{key_id}/status` | 設定 active／revoked 等狀態 | 已實作；輸入未限制 enum |

## 7. 資料模型與關係

目前 SQLAlchemy model 與遷移合計六張主要資料表。

### 7.1 `User`

用途：會員核心身分與權限。

主要欄位：

- `internal_user_id`：UUID 主鍵。
- `status`：程式約定 `active`／`disabled`。
- `role`：程式約定 `member`／`admin`。
- `admin_notes`：管理員內部備註。
- `created_at`、`updated_at`。

關係：一對一連到 `ClerkAccount` 與 `Profile`。

### 7.2 `ClerkAccount`

用途：把 Clerk 身分對應到內部會員。

主要欄位：Clerk user ID、Email、provider、`user_id` 外鍵。

### 7.3 `Profile`

用途：保存會員個人檔案。

標準欄位：姓名、顯示名稱、手機、市話、國家、縣市、行政區、詳細地址、性別、職涯狀態、自介、生日。

JSONB 欄位：

- `custom_fields`
- `work_experiences`
- `educations`
- `certifications`
- `skills`

### 7.4 `CustomFieldDefinition`

用途：定義動態表單欄位。

主要欄位：category、sub_category、key、label、type、sort_order、is_required。

與 `Profile.custom_fields` 以字串 key 約定連結，沒有資料庫外鍵。刪除定義不會自動清除個人檔案裡的舊值。

### 7.5 `SystemKey`

用途：外部系統資料存取權限。

主要欄位：system_name、hashed_key、allowed_fields、is_sandbox、status。

`allowed_fields` 以字串陣列引用標準欄位或自訂欄位 key，沒有外鍵約束。

### 7.6 `AuditLog`

用途：保存部分操作事件。

主要欄位：actor_id、action、before_data、after_data、created_at。

actor 與目標會員通常放在文字或 JSONB 中，沒有對 `User`、`SystemKey` 的正式外鍵。會員詳情頁以 `ILIKE` 搜尋 JSON 文字找相關紀錄，資料量增大後會有效能與誤匹配風險。

### 7.7 關係摘要

```text
User 1 ─── 1 ClerkAccount
  │
  └────── 1 Profile
              │
              └─ custom_fields 的 key 對應 CustomFieldDefinition.key

SystemKey.allowed_fields ──字串引用──> Profile 標準欄位／custom_fields key
AuditLog ──文字或 JSON 內容──> User／SystemKey／操作目標
```

### 7.8 不存在的資料模型

未發現以下資料表或 model：

- 家庭／戶別。
- 小組／群組與成員關係。
- 活動／聚會／場次。
- 報名／候補／取消。
- 出席／簽到。
- 奉獻交易／繳費／付款／退款／收據。
- 通知／訊息／LINE 綁定。
- 會員逐筆外部系統授權。

`seed_npo.py` 可建立「累積捐款總額」與「最後捐款日期」自訂欄位，但這只是會員個人檔案中的彙總值，不是奉獻交易系統。

## 8. 個資與敏感資料分級

### 8.1 高敏感個人資料

- 真實姓名、Email、手機、市話。
- 完整地址、生日、性別。
- 工作、學歷、證照、技能、職涯狀態與自我介紹。
- 管理員備註。
- 自訂欄位可由管理員自由定義，可能加入奉獻、財務、健康、服事或其他高敏感內容。

### 8.2 安全資料

- Clerk user ID、內部 UUID。
- `SystemKey` 金鑰明文與雜湊。
- Clerk Secret、Webhook Secret、資料庫連線字串。
- AuditLog 中的 actor、target user ID 與 before／after data。

### 8.3 誰可以查看或修改

- 一般會員：設計上可讀寫自己的 Profile；但 disabled 狀態沒有在 Profile API 再檢查。
- 管理員：可讀會員清單與詳情、更新狀態與備註；後端另有角色更新 API。
- 外部系統：持有效 `SystemKey` 時可讀 `allowed_fields` 指定的欄位。
- 未登入者：可讀自訂欄位定義；另有一支未保護 API 可修改指定會員的自訂欄位。

## 9. 登入、權限與會員生命週期

### 9.1 註冊與同步

1. Clerk 完成使用者建立或更新。
2. Clerk 以 Webhook 呼叫 `/api/v1/eih/auth/sync`。
3. 後端驗證 Svix 簽章。
4. 依 Clerk user ID upsert `User`、`ClerkAccount`、`Profile`。
5. 寫入 `CLERK_USER_SYNC` AuditLog。

### 9.2 Webhook 刪除

收到 `user.deleted` 時只將 `User.status` 改為 `disabled`，不刪除 `ClerkAccount` 或 `Profile`。硬刪除／匿名化只有任務文件，尚未實作。

### 9.3 登入後自動補資料

`get_current_user` 與 Profile helper 在找不到對應資料時會自動建立 User／ClerkAccount／Profile，降低 Webhook 遺漏造成的阻塞，但也讓身分生命週期有兩條建立路徑，需以測試確保一致性。

### 9.4 管理員停用帳號

管理 API 先改本地 `User.status`，再呼叫 Clerk ban／unban。Clerk 呼叫失敗時只印出警告，仍提交資料庫。因此可能出現本地已停用、Clerk 仍保留有效登入狀態的短暫不一致。

## 10. 稽核紀錄範圍

目前會寫入 AuditLog 的操作：

- Clerk 使用者同步與刪除事件。
- 外部系統讀取會員資料。
- 管理員更新會員狀態、角色、備註。
- 管理員建立或撤銷 SystemKey。

目前不會寫入 AuditLog 的重要操作：

- 會員讀取自己的完整 Profile。
- 會員更新自己的標準欄位、經歷與自訂欄位。
- 無驗證 custom fields endpoint 的更新。
- 自訂欄位定義的新增、修改、刪除。

因此 README 的「完整紀錄所有資料存取與變更」不符合目前程式現況，應視為部分完成。

## 11. 歷史文件與設計文件

### 11.1 `tasks/account-lifecycle-management.md`

明確標示刪除帳號與合併帳號尚未實作。建議未來在 Clerk 與資料庫間執行硬刪除或匿名化，並處理 AuditLog。

### 11.2 `tasks/oauth-like-flow-design.md`

描述未來會員逐筆同意外部系統欄位、保存 `UserSystemAuthorization`、回呼與撤銷授權。實際 model 與 migration 不存在，屬設計藍圖。

### 11.3 `tasks/dev-deployment-guide.md`

描述 Vercel／Render／Supabase／Clerk 架構與環境變數。只可視為部署設計與過去狀態，不代表現場環境健康。

### 11.4 `doc/test_accounts.md`

保存 5 個 demo 帳號與共用密碼。測試帳號是模擬資料，但密碼明文進入版本庫仍有濫用風險。

### 11.5 Git 歷史

- 主要提交者：`KeithHello`。
- 近期工作集中在 2026 年 5 月 20 日至 21 日，包含前端整合、JWT、國際電話、手機版、固定儲存列與建置修復。
- `main` 與 `develop` 已分歧；盤點時 `main` 相對 `develop` 為 11 個提交在左、5 個提交在右。後續開發前應先確認分支策略，避免重複或遺漏修正。

## 12. 環境需求

### 12.1 後端環境變數

程式要求以下名稱，不在本報告顯示任何值：

- `DATABASE_URL`
- `DIRECT_URL`
- `CLERK_SECRET_KEY`
- `CLERK_WEBHOOK_SECRET`
- `CLERK_ISSUER`
- `PORT`（部署環境使用）

### 12.2 前端環境變數

- `NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY`
- `CLERK_SECRET_KEY`
- `NEXT_PUBLIC_CLERK_SIGN_IN_URL`
- `NEXT_PUBLIC_CLERK_SIGN_UP_URL`
- `NEXT_PUBLIC_CLERK_AFTER_SIGN_IN_URL`
- `NEXT_PUBLIC_CLERK_AFTER_SIGN_UP_URL`
- `NEXT_PUBLIC_API_URL`

### 12.3 本機工具

- Python 3.12。
- Node.js 與 npm。
- 可連線的 PostgreSQL／Supabase。
- 可用的 Clerk instance 與對應 Webhook。

## 13. 啟動方式

### 13.1 後端

```powershell
cd backend
.\venv\Scripts\Activate.ps1
pip install -r requirements.txt
uvicorn app.main:app --reload --port 8000
```

API 文件：`http://localhost:8000/docs`

注意：目前 `backend/.env` 中的資料庫連線無法通過 Supabase pooler 驗證；需要由有權限的人更新環境設定。此動作涉及密鑰，必須另外確認後執行。

### 13.2 前端

```powershell
cd frontend
npm install
npm run dev
```

本機網址：`http://localhost:3000`

### 13.3 前端正式建置

```powershell
cd frontend
npm run build
```

2026 年 7 月 26 日實測成功，產生 11 個 Next.js 路由。

### 13.4 後端測試

```powershell
cd backend
.\venv\Scripts\python.exe -m pytest -v tests
```

目前測試直接連遠端資料庫，不是隔離測試環境。盤點時共收集 7 個案例，只有無效 Webhook 簽章案例通過；測試總結為 1 passed、2 failed、11 errors，主要共同原因是 Supabase 回應 tenant／user not found。錯誤數包含 fixture setup／teardown，因此會高於測試案例數。

## 14. 部署方式與現況

### 14.1 文件描述的部署

- 前端：Vercel，Root Directory 為 `frontend`。
- 後端：Render，啟動指令為 `uvicorn app.main:app --host 0.0.0.0 --port $PORT`。
- 資料庫：Supabase PostgreSQL。
- 身分：Clerk，Webhook 指向 `/api/v1/eih/auth/sync`。

### 14.2 實際可確認的現況

- Render 後端根網址於 2026 年 7 月 26 日回傳 HTTP 200 與 `Welcome to Empower Core API`。
- 公開 OpenAPI 可讀，列出與程式相符的 16 個 path。
- `/api/v1/me`、`/api/v1/admin/users`、`/api/v1/profile/me` 在沒有 Token 時均回 401，符合預期。
- `/api/v1/custom-fields` 回 500，表示部署後端可啟動但無法完成資料庫查詢。
- 專案沒有記錄可確認的正式前端網址；無法確認 Vercel 正式站是否存在或健康。
- 專案沒有 Dockerfile、CI workflow、Render blueprint 或 Infrastructure as Code。

## 15. 測試與驗證結果

| 檢查 | 指令／方式 | 結果 |
|---|---|---|
| Git 工作樹初始狀態 | `git status --short` | 盤點前乾淨 |
| 前端正式建置 | `npm run build` | 成功，exit 0 |
| 前端本機啟動 | `npm run dev` | 成功，`http://localhost:3000` |
| 手機首頁 | 390 × 844 瀏覽器預覽 | 成功，已保存實際截圖 |
| 登入頁 | 390 × 844 瀏覽器預覽 | 頁面本體載入，但 Clerk 表單未出現 |
| 後端 pytest | `python -m pytest -v tests` | 未通過；資料庫身分失效 |
| Alembic 當前版本 | `python -m alembic current` | 未通過；相同資料庫錯誤 |
| 公開後端根網址 | HTTPS GET | 200 |
| 公開 custom fields | HTTPS GET | 500 |
| 未授權保護 | HTTPS GET | 3 個受保護 endpoint 均回 401 |

## 16. 已知問題與維護風險

### P0：必須立即處理

1. **明文憑證已提交到 Git**  
   `doc/environment.md` 含 Clerk Secret、Supabase key 與資料庫密碼；`backend/drop.py` 也硬編碼資料庫連線密碼。必須輪替所有相關憑證、移除明文，並評估清理 Git 歷史。因修改密鑰屬高風險操作，本次只通報，未更動任何值。

2. **未授權的會員資料修改 API**  
   `PATCH /api/v1/profile/{user_id}/custom-fields` 的驗證依賴被註解掉，任何知道會員 UUID 的人都可能修改自訂欄位。現有測試還直接依賴這個未驗證行為。

### P1：上線前修復

3. **資料庫連線失效**  
   本機與公開資料型 API 都無法完成查詢；目前不能把系統描述為可用會員服務。

4. **停用會員可繞過狀態檢查使用 Profile API**  
   `/profile/me` 只使用 `verify_clerk_jwt`，沒有使用 `get_current_user`，因此不會檢查 `User.status == disabled`。

5. **外部系統沒有會員逐筆同意**  
   SystemKey 是管理員層級欄位白名單，沒有 `UserSystemAuthorization`。如果實際用於個資交換，治理風險高。

6. **登入元件未載入**  
   實際手機預覽 `/sign-in` 時 Clerk 表單區域為空白，需要檢查 Clerk 前端設定、網域與瀏覽器 console。

7. **CORS 允許所有來源**  
   `allow_origins=["*"]` 適合開發測試，不適合直接當正式環境策略。

### P2：近期補強

8. **角色、帳號狀態與金鑰狀態缺少嚴格 enum 驗證**。
9. **稽核不完整**，會員資料修改與欄位設定變更未記錄。
10. **AuditLog 可能保存敏感全文**，沒有遮罩、保存期限或刪除政策。
11. **會員清單前端只有前 10 筆**，搜尋框與分頁未接線。
12. **自訂欄位定義與 Profile JSONB 沒有一致性約束**，刪除或改類型後可能殘留舊資料。
13. **公開欄位定義 API** 會暴露所有資料欄位名稱與分類；應確認是否有公開必要。
14. **管理員詳情以 JSON 文字模糊搜尋 AuditLog**，資料量增加時效能與準確性會下降。
15. **Clerk ban／unban 失敗只記錄 warning**，可能造成本地與身分服務狀態不一致。
16. **測試沒有隔離資料庫**，會依賴共享遠端環境並執行資料清理。
17. **測試覆蓋不足**，沒有前端測試，也沒有正式 pytest 管理員權限測試。
18. **高風險工具腳本存在**，`backend/drop.py` 會直接刪除主要資料表，且沒有環境防護。
19. **分支已分歧**，`main`／`develop` 需先整理策略再繼續開發。
20. **缺少專案級 `CLAUDE.md` 與既有 ROADMAP**，接手者無法從專案本身得知工程規範與真實進度。

## 17. 明確未完成項目

- 家庭／小組關係。
- 活動／聚會建立。
- 會員報名、候補、取消與名額控管。
- 出席／簽到。
- 奉獻交易、繳費、付款、退款與收據。
- LINE、Email、簡訊或站內通知。
- CSV／Excel 匯出。
- 前端實際搜尋與分頁。
- 前端角色管理。
- 會員外部系統授權同意與撤銷。
- 刪除帳號、資料匿名化、合併帳號。
- 完整稽核與個資保存政策。
- 可確認的正式前端部署。

## 18. 建議接手順序

1. 輪替已曝光的 Clerk、Supabase 與資料庫憑證，移除 Git 明文。
2. 暫停或修復未授權 custom fields API。
3. 修復 Supabase 連線，確認 Alembic 版本與實際 schema 一致。
4. 修復 Clerk 登入元件與 Webhook，完成註冊／登入／停用端到端測試。
5. 建立隔離測試資料庫，讓 7 個既有 pytest 全部可重現。
6. 補上 Profile 停用檢查與完整 AuditLog。
7. 完成管理後台搜尋、分頁、角色管理與匯出。
8. 實作會員同意／撤銷／刪除，並訂定個資保存與存取政策。
9. 與 FK 事工單位確認家庭、小組、活動、出席與奉獻的真正資料需求後，再分模組開發。

## 19. 本次成果檔案

- `docs/member-system-showcase/index.html`：執事手機閱讀版。
- `docs/member-system-showcase/styles.css`：手機優先樣式。
- `docs/member-system-showcase/assets/home-mobile.png`：無個資的實際首頁截圖。
- `docs/member-system-showcase/assets/showcase-hero-mobile.png`：成果網站手機首屏驗證畫面。
- `docs/member-system-showcase/assets/showcase-screens-mobile.png`：成果網站畫面展示區驗證畫面。
- `docs/member-system-showcase/MEETING_SUMMARY.md`：一頁會議摘要。
- `docs/member-system-showcase/TECHNICAL_INVENTORY.md`：本技術盤點。
- `ROADMAP.md`：專案真實進度與最新驗證。

本次沒有修改既有會員系統程式、資料庫 schema、`.env`、密鑰、CI/CD 或部署設定，也沒有公開發布網站。