55 lines
2.0 KiB
Markdown
55 lines
2.0 KiB
Markdown
|
# 總開發規範
|
|||
|
|
|
|||
|
|
## 安全政策
|
|||
|
|
- 禁止所有安全風險的套件
|
|||
|
|
- 所有 API 呼叫必須使用 HTTPS
|
|||
|
|
- 敏感資料必須加密存儲
|
|||
|
|
- 絕不在原始碼中寫死 secrets（API keys、密碼、token）
|
|||
|
|
- 所有使用者輸入必須驗證；使用參數化查詢防止 SQL injection
|
|||
|
|
- 發現安全問題時：立即停止 → 使用 **security-reviewer** agent → 修復後繼續
|
|||
|
|
|
|||
|
|
## 程式開發標準
|
|||
|
|
- 測試覆蓋率不得低於 80%
|
|||
|
|
- 優先不可變資料（immutability）：永遠回傳新物件，不直接修改原物件
|
|||
|
|
- 檔案大小：一般 200-400 行，最多 800 行；超過時拆分
|
|||
|
|
- 錯誤處理：每一層都要明確處理，不可靜默吞掉錯誤
|
|||
|
|
|
|||
|
|
## 合規要求
|
|||
|
|
- 遵循 GDPR 資料保護規範
|
|||
|
|
- 記錄所有資料存取操作
|
|||
|
|
|
|||
|
|
## Agent 使用規範
|
|||
|
|
- 複雜功能請求 → 先用 **planner** agent 規劃
|
|||
|
|
- 寫完程式碼後 → 立即用 **code-reviewer** agent
|
|||
|
|
- 新功能或 bug fix → 用 **tdd-guide** agent（先寫測試）
|
|||
|
|
- 架構決策 → 用 **architect** agent
|
|||
|
|
- 獨立任務盡量平行啟動多個 agent，不要依序執行
|
|||
|
|
|
|||
|
|
## Git 規範
|
|||
|
|
- Commit message 格式：`<type>: <description>`
|
|||
|
|
- Types: feat, fix, refactor, docs, test, chore, perf, ci
|
|||
|
|
- PR 時用 `git diff [base-branch]...HEAD` 分析完整變更
|
|||
|
|
|
|||
|
|
## 模型選擇
|
|||
|
|
- **Haiku**：輕量 agent、頻繁呼叫的 worker
|
|||
|
|
- **Sonnet**：主要開發工作、orchestration
|
|||
|
|
- **Opus**：複雜架構決策、深度研究分析
|
|||
|
|
|
|||
|
|
# 全域開發偏好
|
|||
|
|
|
|||
|
|
## 語言偏好
|
|||
|
|
- 預設使用繁體中文回應自然語言內容
|
|||
|
|
- 程式碼註解和文件使用繁體中文撰寫
|
|||
|
|
- 不要有太多 emoji
|
|||
|
|
- 思考過程也使用繁體中文
|
|||
|
|
|
|||
|
|
## 程式設計偏好
|
|||
|
|
- 偏好函式程式設計風格
|
|||
|
|
- 重視程式碼可讀性多過簡潔性
|
|||
|
|
- 喜歡詳細的錯誤處理和日誌記錄
|
|||
|
|
- 可以有時間複雜度小的方案絕不使用時間複雜度大方案解決，且要兼顧可讀性
|
|||
|
|
|
|||
|
|
## 解釋風格
|
|||
|
|
- 先解釋概念，在給出程式碼
|
|||
|
|
- 提出多種解決方案並說明優缺點
|
|||
|
|
- 包含實際的使用範例
|