核心設計原則
以下五項原則為本系統的架構基石，所有模組的設計與實作均須遵循
原則 1：報名名額與候補（超賣防護）
名額控管採樂觀鎖（Optimistic Locking）機制，透過資料庫層級的 version 欄位防止並發報名導致超賣。當名額已滿時，系統自動將後續報名導入候補流程。候補晉升時保留名額 48 小時等待確認，逾時未確認則自動釋放名額並通知下一順位。
此原則確保在多 Pod 水平擴展的 Container 部署環境下，名額計數的原子性與一致性。
原則 2：退款必須經 Approver 核准
所有退款操作均須經過 Approver 核准後方可執行，任何退款請求不得繞過核准流程。退款狀態機嚴格遵循 pending → approved → executed 的單向流轉，系統透過資料庫狀態欄位強制執行此約束。
此原則確保財務操作的合規性與可追溯性，防止未經授權的退款行為。
原則 3：外部同步失敗不阻斷主流程
所有外部系統整合（M365 行事曆同步、WordPress 官網同步等）均採用 fire-and-forget 模式，同步操作在非同步背景任務中執行。外部同步失敗時，僅記錄失敗原因並排入重試佇列，絕不影響 TMS 內部的業務資料與流程。
此原則為系統級通用約束，確保外部系統的不穩定性不會傳播至核心業務流程。
原則 4：模組 J 為橫向能力層
模組 J 提供的 RBAC 權限控管、稽核紀錄寫入、報表資料貢獻、全域搜尋、動態欄位與 Tag 標籤系統為橫向能力（Cross-Cutting Concern），所有模組均強制依賴。
- RBAC：所有 API 端點執行權限驗證
- 稽核：所有核心物件的 CUD 操作寫入稽核紀錄
- 報表：所有模組提供標準化報表查詢介面
- 全域搜尋：所有模組實作搜尋端點
- 動態欄位：所有核心實體支援 Custom Field
- Tag：所有核心實體支援 Tag 標籤
原則 5：GUI 優先管理（GUI-First Administration）
所有系統設定與管理操作均須透過管理介面（GUI）完成，最大化 GUI 管理能力。系統不得要求管理員修改 .env 檔案、設定檔或重新部署容器來變更業務設定。環境變數僅用於基礎設施層級的設定（如資料庫連線字串、容器 Port 映射），所有業務邏輯相關的設定均須提供 GUI 管理介面。
此原則確保系統管理員無需具備開發或 DevOps 技能即可完成日常管理操作，降低維運門檻。