编码规范制定

# codex.yaml — Team Coding Standards
# 放置于项目根目录，Codex 自动读取

project:
  name: "TaskFlow"
  language: "typescript"
  framework: "next.js"

rules:
  naming:
    components: "PascalCase"
    functions: "camelCase"
    constants: "UPPER_SNAKE_CASE"
    files: "kebab-case"
    typeFiles: "*.types.ts"
    testFiles: "*.test.ts"

  typescript:
    strictMode: true
    noAny: true
    preferInterface: false  # 使用 type
    explicitReturnType: true  # 函数显式返回类型
    noTypeAssertion: false  # 允许 as 断言

  react:
    componentStyle: "functional"
    propsType: "interface"
    preferNamedExport: true
    noDefaultExport: true
    stateManagement: "hooks"
    cssApproach: "tailwind-css"

  api:
    pattern: "RESTful"
    versionPrefix: "/api/v1"
    responseFormat: "{ success: boolean, data: T, error?: string }"
    pagination: "cursor-based"

  database:
    orm: "prisma"
    idType: "cuid"
    timestamps: true
    softDelete: true

  testing:
    framework: "vitest"
    coverage:
      lines: 80
      branches: 70
      functions: 80
    testPattern: "describe → it → expect"
    mockStrategy: "prefer-spy"

  git:
    commitStyle: "conventional-commits"
    branchPrefix:
      feature: "feat/"
      bugfix: "fix/"
      hotfix: "hotfix/"
    prTitleFormat: "[TYPE] description"

  errorHandling:
    apiErrors: "AppError class"
    frontendErrors: "ErrorBoundary + Toast"
    logging: "pino"

代码审查检查清单（AI 生成代码专用）：

□ 类型安全
  - 没有 any 类型（除非有充分理由）
  - 没有 @ts-ignore 或 @ts-expect-error
  - 所有 async 函数有 try/catch

□ 安全性
  - 没有硬编码凭据
  - 用户输入经过验证和转义
  - API 请求通过了认证中间件

□ 性能
  - 没有循环内 await（改为 Promise.all）
  - 数据库查询使用了 select 而非 include
  - 前端没有不必要的 re-render

□ 可维护性
  - 函数不超过 50 行
  - 文件不超过 300 行
  - 复杂逻辑有注释说明

## AI Code Review 模板

### PR 信息
- **分支：** feat/task-kanban-dnd
- **AI 生成比例：** 约 80%
- **修改文件数：** 12

### AI 生成部分审查重点
1. [ ] 错误处理是否完整？（AI 常忽略边界条件）
2. [ ] 是否有 N+1 查询风险？
3. [ ] 状态管理逻辑是否一致？
4. [ ] 类型定义是否正确对应 API 响应？

### 人工修改部分
无额外修改

### 审查结论
- [ ] 批准
- [ ] 需要修改（见评论）
- [ ] 拒绝（理由）：

代码提交时自动检查：
├── ESLint      → 代码风格和潜在错误
├── Prettier    → 代码格式化
├── TypeScript  → 类型检查 (tsc --noEmit)
├── commitlint   → Commit 信息格式
└── Codex       → /review 自动审查

// package.json
{
  "lint-staged": {
    "*.{ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.prisma": [
      "prettier --write"
    ]
  }
}

# .husky/pre-commit
npx lint-staged
npx tsc --noEmit

# .husky/commit-msg
npx --no -- commitlint --edit $1

# .github/workflows/lint.yml
name: Code Standards

on: [pull_request]

jobs:
  standards:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npx eslint . --max-warnings 0
      - run: npx prettier --check .
      - run: npx tsc --noEmit
      - run: npx vitest run --coverage

提议（RFC）
  → 团队讨论（1 周）
    → 试行（2 周，可选参与）
      → 投票（多数通过）
        → 正式发布（更新 codex.yaml）
          → 回顾（季度）

# RFC: {提案标题}

## 背景
{为什么需要这个规范变更}

## 提案
{具体的规范变更描述}

## 影响范围
- 影响文件数：约 XX 个
- 影响开发流程：{描述}

## 迁移方案
{如何从旧规范迁移到新规范}

## 试行结果
{试行期的反馈和数据}

## 投票
- [ ] 同意
- [ ] 反对（理由）
- [ ] 弃权

请为你的团队项目编写完整的 codex.yaml，至少包含：
- naming 规范
- TypeScript 规则
- API 设计约定
- 测试要求
- Git 提交规范

为团队项目配置：
- Husky pre-commit hooks
- commitlint
- CI 规范门禁 workflow

针对你团队当前最大的规范痛点，撰写一份 RFC 提案