diff --git a/.claude/commands/commit.md b/.claude/commands/commit.md
index e7a0ef384..19d78ba89 100644
--- a/.claude/commands/commit.md
+++ b/.claude/commands/commit.md
@@ -1,3 +1,11 @@
+---
+name: "commit"
+description: "提交当前变更到 Git"
+usage: "/commit"
+---
+
+# Commit Command
+
 提交当前变更到 Git。
 
 **此命令已迁移到官方插件，将调用 `commit-commands` 插件。**
diff --git a/.claude/commands/fix-permissions.md b/.claude/commands/fix-permissions.md
deleted file mode 100644
index 4d06a70ca..000000000
--- a/.claude/commands/fix-permissions.md
+++ /dev/null
@@ -1,88 +0,0 @@
-检查并修复项目中所有文件和文件夹的权限，确保符合项目规范。
-
-**用法：**
-- `/fix-permissions` - 检查并自动修复所有权限问题
-
-**执行步骤：**
-
-1. **获取参考文件的所有者信息**
-   ```bash
-   ls -l README.md | awk '{print $3":"$4}'
-   ```
-   - 从项目根目录的 `README.md` 动态获取正确的所有者信息
-   - README.md 是所有项目都有的通用文件
-   - 不硬编码用户名和用户组
-
-2. **统计当前文件权限分布**
-   ```bash
-   # 检查所有文件的所有者分布
-   find . -type f -print0 2>/dev/null | xargs -0 ls -l 2>/dev/null | awk '{print $3":"$4}' | sort | uniq -c | sort -rn
-
-   # 检查所有目录的所有者分布
-   find . -type d -print0 2>/dev/null | xargs -0 ls -ld 2>/dev/null | awk '{print $3":"$4}' | sort | uniq -c | sort -rn
-   ```
-
-3. **识别权限不一致的文件**
-   ```bash
-   # 找出所有者不是参考用户的文件
-   find . -type f -print0 2>/dev/null | xargs -0 ls -l 2>/dev/null | awk '$3 == "root" {print $9}'
-
-   # 找出所有者不是参考用户的目录
-   find . -type d -print0 2>/dev/null | xargs -0 ls -ld 2>/dev/null | awk '$3 == "root" {print $9}'
-   ```
-
-4. **修复文件权限**
-   ```bash
-   # 获取正确的所有者信息
-   OWNER_GROUP=$(ls -l README.md | awk '{print $3":"$4}')
-
-   # 修复所有文件权限
-   find . -type f -print0 2>/dev/null | xargs -0 ls -l 2>/dev/null | awk '$3 == "root" {print $9}' | xargs sudo chown $OWNER_GROUP
-
-   # 修复所有目录权限
-   find . -type d -print0 2>/dev/null | xargs -0 ls -ld 2>/dev/null | awk '$3 == "root" {print $9}' | xargs sudo chown $OWNER_GROUP
-   ```
-
-5. **最终验证**
-   ```bash
-   # 统计修复后的权限分布
-   find . \( -type f -o -type d \) -print0 2>/dev/null | xargs -0 ls -ld 2>/dev/null | awk '{print $3":"$4}' | sort | uniq -c | sort -rn
-
-   # 抽查几个之前有问题的文件
-   ls -ld ./.claude/settings.local.json ./framework/.claude/settings.local.json
-   ```
-
-6. **生成检查报告**
-   - 显示参考所有者信息
-   - 显示发现的问题文件和目录数量
-   - 显示修复的文件和目录列表
-   - 显示最终验证结果
-
-**规范说明：**
-
-根据 `.claude/project-rules.md` 中的规则 1：
-- 所有文件必须设置正确的所有者权限
-- 不要硬编码用户名和用户组
-- 动态从 `README.md` 等参考文件获取权限信息
-- README.md 是通用文件，适用于所有语言的项目
-- 确保用户可以自主修改所有文件
-
-**常见问题：**
-
-**为什么有些文件是 root 所有者？**
-- 可能是使用 `sudo` 创建的文件或目录
-- Git 操作时使用了 sudo 权限
-- Claude Code 创建文件时权限设置不当
-
-**修复后会影响 Git 吗？**
-- 不会影响 Git 历史和提交
-- 只改变文件系统级别的所有者
-- Git 内容和状态保持不变
-
-**需要 sudo 权限吗？**
-- 修复 root 所有者的文件时需要 sudo
-- 确保当前用户在 sudoers 列表中
-
-**参考文档：**
-- 项目规则：`.claude/project-rules.md` (规则 1)
-- 动态获取权限方法的详细说明
diff --git a/.claude/commands/test.md b/.claude/commands/test.md
index 7df251e42..4ad3c108d 100644
--- a/.claude/commands/test.md
+++ b/.claude/commands/test.md
@@ -1,3 +1,13 @@
+---
+name: "test"
+description: "执行完整的测试流程"
+usage: "/test"
+---
+
+# Test Command
+
+## 功能说明
+
 执行完整的测试流程，包括单元测试、构建验证和集成测试。
 
 **用法：**
diff --git a/.codex/README.md b/.codex/README.md
new file mode 100644
index 000000000..06a1be25c
--- /dev/null
+++ b/.codex/README.md
@@ -0,0 +1,129 @@
+# Codex 项目级 Prompts
+
+本目录提供仓库内的 Codex prompts（用于生成/管理 slash 命令的文档版本）。
+由于 Codex CLI 的自定义 prompts 只会从用户目录读取（默认 `~/.codex/prompts/`），
+这里的内容需要手动安装到本地目录后才会生效。
+
+## 安装到本地
+
+运行安装脚本，将本目录的 prompts 复制到 `~/.codex/prompts/`：
+
+```bash
+bash .codex/scripts/install-prompts.sh
+```
+
+安装完成后，使用 `/prompts:<name>` 调用（例如：`/prompts:analyze-issue`）。
+
+## 使用提示
+
+- 这些 prompts 以"仓库根目录"为默认上下文。
+- 作为全局 prompts 使用时，请先切换到目标仓库或显式指定路径（详见各命令文件中的"使用前：选择目标仓库"）。
+
+## Prompt 文件格式规范
+
+本目录下的 prompts 采用混合格式，既符合 Codex 官方规范，又保留完整的使用示例：
+
+### 混合格式（兼容官方标准）
+
+```yaml
+---
+description: 命令的功能描述
+usage: /prompts:command-name <参数>
+argument-hint: <参数>
+---
+```
+
+### 字段说明
+
+- **description** (必需): 描述 prompt 的功能，使用中文
+- **usage** (推荐): 完整的使用示例，包含命令名和参数
+  - 格式：`/prompts:command-name <参数>`
+  - 提供完整的调用示例供参考
+- **argument-hint** (可选): 仅参数部分的描述（Codex 官方格式）
+  - 使用 `<param>` 表示必需参数
+  - 使用 `[param]` 表示可选参数
+  - 使用 `[--flag=<value>]` 表示可选标志参数
+  - 仅包含参数部分，不含命令名称
+
+### 调用方式
+
+- 在 Codex CLI 中使用 `/prompts:filename` 调用（不含 .md 扩展名）
+- 例如：`/prompts:analyze-issue <issue-number>`
+
+### 示例
+
+**有参数的命令**：
+```yaml
+---
+description: 分析 GitHub Issue 并创建需求分析文档
+usage: /prompts:analyze-issue <issue-number>
+argument-hint: <issue-number>
+---
+```
+
+**有多个参数的命令**：
+```yaml
+---
+description: 升级项目依赖
+usage: /prompts:upgrade-dependency <package-name> <from-version> <to-version>
+argument-hint: <package-name> <from-version> <to-version>
+---
+```
+
+**无参数的命令**：
+```yaml
+---
+description: 执行完整的测试流程
+usage: /prompts:test
+---
+```
+
+### 格式说明
+
+- ✅ 兼容 Codex 官方格式（使用 `argument-hint`）
+- ✅ 保留完整使用示例（使用 `usage`）
+- ✅ 文件名即为 prompt 名称，无需 `name` 字段
+- ✅ 所有字段值不使用引号
+
+## 可用命令列表
+
+所有命令都支持 Codex CLI（通过 `/prompts:command-name` 调用）：
+
+**任务管理**：
+- `analyze-issue` - 分析 GitHub Issue 并创建需求分析文档
+- `plan-task` - 设计技术方案并输出实施计划
+- `implement-task` - 根据技术方案实施任务
+- `review-task` - 审查任务实现并输出代码审查报告
+- `refinement-task` - 处理代码审查反馈并修复问题
+- `complete-task` - 标记任务完成并归档到 completed 目录
+- `task-status` - 查看任务的当前状态和进度
+- `block-task` - 标记任务阻塞并记录阻塞原因
+
+**Git 操作**：
+- `commit` - 提交当前变更到 Git（提供最佳实践指南）
+- `create-pr` - 创建 Pull Request
+- `sync-pr` - 将任务处理进度同步到 PR 评论
+- `sync-issue` - 将任务处理进度同步到 Issue 评论
+- `refine-title` - 重构 Issue/PR 标题为 Conventional Commits 格式
+
+**依赖和安全**：
+- `upgrade-dependency` - 升级项目依赖
+- `analyze-security` - 分析 Dependabot 安全告警并创建修复任务
+- `close-security` - 关闭 Dependabot 安全告警（需提供合理理由）
+
+**其他**：
+- `test` - 执行完整的测试流程
+
+## 常见问题
+
+### Q: 为什么我无法使用 `/commit-commands:commit`？
+
+A: 这是 Claude Code 的官方插件命令，在 Codex CLI 中不可用。请使用 `/prompts:commit` 查看提交指南，然后手动执行 Git 命令。
+
+### Q: 如何进行代码审查？
+
+A: 使用 `/prompts:review-task <task-id>` 查看详细的审查清单，然后按照清单手动审查代码。Claude Code 用户可以使用 `/code-review:code-review` 进行自动审查。
+
+### Q: 命令文件中提到的插件功能我能用吗？
+
+A: 如果命令文件中标记为"Claude Code 插件"或"Codex CLI 不支持"，则这些功能仅适用于 Claude Code。请使用文档中提供的替代方法（通常是手动操作步骤）。
diff --git a/.codex/commands/analyze-issue.md b/.codex/commands/analyze-issue.md
new file mode 100644
index 000000000..62bbf763e
--- /dev/null
+++ b/.codex/commands/analyze-issue.md
@@ -0,0 +1,162 @@
+---
+description: 分析 GitHub Issue 并创建需求分析文档
+usage: /analyze-issue <issue-number>
+argument-hint: <issue-number>
+---
+
+# Analyze Issue Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+分析指定的 GitHub Issue，创建任务并输出需求分析文档。
+
+## ⚠️ CRITICAL: 状态更新要求
+
+执行此命令后，你**必须**立即更新任务状态。参见规则 7。
+
+## 执行流程
+
+### 1. 获取 Issue 信息
+
+```bash
+gh issue view <issue-number> --json number,title,body,labels
+```
+
+### 2. 创建任务目录和文件
+
+检查是否已存在该 Issue 的任务：
+- 在 `.ai-workspace/active/` 中搜索相关任务
+- 如果找到，询问是否重新分析
+- 如果没有，创建任务目录：`.ai-workspace/active/TASK-{yyyyMMdd-HHmmss}/`
+- 使用 `.ai-agents/templates/task.md` 模板创建任务文件：`task.md`
+
+### 3. 执行需求分析
+
+按照 `.ai-agents/workflows/feature-development.yaml` 中的 `requirement-analysis` 步骤：
+
+**必须完成的任务**：
+- [ ] 阅读并理解 Issue 描述
+- [ ] 搜索相关代码文件（使用 Glob/Grep 工具）
+- [ ] 分析代码结构和影响范围
+- [ ] 识别潜在的技术风险和依赖
+- [ ] 评估工作量和复杂度
+
+### 4. 输出分析文档
+
+创建 `.ai-workspace/active/{task-id}/analysis.md`，必须包含以下章节：
+
+```markdown
+# 需求分析报告
+
+## 需求理解
+{用自己的话重新描述需求，确保理解正确}
+
+## 相关文件列表
+- `{file-path}:{line-number}` - {说明}
+
+## 影响范围评估
+**直接影响**：
+- {影响的模块和文件}
+
+**间接影响**：
+- {可能影响的其他部分}
+
+## 技术风险
+- {风险描述和应对思路}
+
+## 依赖关系
+- {需要的依赖和其他模块的配合}
+
+## 工作量和复杂度评估
+- 复杂度：{高/中/低}
+- 工作量：{预估时间}
+- 风险等级：{高/中/低}
+```
+
+### 5. 更新任务状态
+
+更新 `.ai-workspace/active/{task-id}/task.md`：
+- `current_step`: requirement-analysis
+- `assigned_to`: codex
+- `updated_at`: {当前时间}
+- 标记 analysis.md 为已完成
+
+### 6. 告知用户
+
+输出格式：
+```
+✅ Issue #{number} 分析完成
+
+**任务信息**：
+- 任务ID: {task-id}
+- 任务标题: {title}
+- 工作流: feature-development
+
+**输出文件**：
+- 任务文件: .ai-workspace/active/{task-id}/task.md
+- 分析文档: .ai-workspace/active/{task-id}/analysis.md
+
+**下一步**：
+审查需求分析后，使用以下命令设计技术方案：
+/plan-task {task-id}
+```
+
+## ✅ 完成检查清单
+
+执行此命令后，确认：
+
+- [ ] 已创建任务文件 `.ai-workspace/active/{task-id}/task.md`
+- [ ] 已创建分析文档 `.ai-workspace/active/{task-id}/analysis.md`
+- [ ] 已更新 task.md 中的 `current_step` 为 requirement-analysis
+- [ ] 已更新 task.md 中的 `updated_at` 为当前时间
+- [ ] 已更新 task.md 中的 `assigned_to` 为你的名字
+- [ ] 已在"工作流进度"中标记 requirement-analysis 为完成 ✅
+- [ ] 已告知用户下一步操作（/plan-task）
+- [ ] 如果有关联 Issue，已在 task.md 中记录 Issue 编号
+
+## 参数说明
+
+- `<issue-number>`: GitHub Issue 编号（必需）
+
+## 使用示例
+
+```bash
+# 分析 Issue #207
+/analyze-issue 207
+```
+
+## 注意事项
+
+1. **Issue 验证**：
+   - 执行前检查 Issue 是否存在
+   - 如果 Issue 不存在，提示用户
+
+2. **任务冲突**：
+   - 如果已存在相关任务，询问用户：
+     - 重新分析（覆盖现有 analysis.md）
+     - 继续使用现有分析
+
+3. **工作流遵循**：
+   - 严格遵循 `.ai-agents/workflows/feature-development.yaml` 定义
+   - 输出文件必须符合工作流要求
+
+4. **人工检查点**：
+   - 分析完成后建议人工审查
+   - 确认需求理解正确后再进入下一步
+
+## 相关命令
+
+- `/plan-task <task-id>` - 设计技术方案
+- `/task-status <task-id>` - 查看任务状态
+
+## 错误处理
+
+- Issue 不存在：提示 "Issue #{number} 不存在，请检查 Issue 编号"
+- 网络错误：提示 "无法连接到 GitHub，请检查网络连接"
+- 权限错误：提示 "没有访问该仓库的权限"
diff --git a/.codex/commands/analyze-security.md b/.codex/commands/analyze-security.md
new file mode 100644
index 000000000..5666afd90
--- /dev/null
+++ b/.codex/commands/analyze-security.md
@@ -0,0 +1,256 @@
+---
+description: 分析 Dependabot 安全告警并创建修复任务
+usage: /analyze-security <alert-number>
+argument-hint: <alert-number>
+---
+
+# Analyze Security Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+分析指定的 Dependabot 安全告警，评估安全风险并创建修复任务，输出安全分析文档。
+
+## 执行流程
+
+### 1. 获取安全告警信息
+
+```bash
+gh api repos/{owner}/{repo}/dependabot/alerts/<alert-number>
+```
+
+提取关键信息：
+- `number`: 告警编号
+- `state`: 状态（open/dismissed/fixed）
+- `security_advisory`: 安全公告详情
+  - `ghsa_id`: GHSA ID
+  - `cve_id`: CVE ID（如果有）
+  - `severity`: 严重程度（critical/high/medium/low）
+  - `summary`: 漏洞摘要
+  - `description`: 详细描述
+  - `vulnerabilities`: 受影响的版本范围
+- `dependency`: 受影响的依赖
+  - `package.name`: 包名
+  - `package.ecosystem`: 生态系统（maven/pip/npm等）
+  - `manifest_path`: 依赖文件路径
+- `security_vulnerability.first_patched_version`: 首个修复版本
+- `security_vulnerability.vulnerable_version_range`: 受影响版本范围
+
+### 2. 创建任务文件
+
+检查是否已存在该安全告警的任务：
+- 在 `.ai-workspace/active/` 中搜索相关任务
+- 如果找到，询问是否重新分析
+- 如果没有，使用 `.ai-agents/templates/task.md` 模板创建新任务
+
+任务文件命名：`TASK-{yyyyMMdd-HHmmss}.md`
+
+任务元数据需包含：
+```yaml
+security_alert_number: <alert-number>
+severity: <critical/high/medium/low>
+cve_id: <CVE-ID>  # 如果有
+ghsa_id: <GHSA-ID>
+```
+
+### 3. 分析受影响范围
+
+**必须完成的分析**：
+- [ ] 识别受影响的依赖包和版本
+- [ ] 搜索项目中使用该依赖的所有位置（使用 Grep 工具）
+- [ ] 检查依赖文件（pom.xml, requirements.txt, package.json 等）
+- [ ] 分析是否直接使用了漏洞代码路径
+- [ ] 评估漏洞的实际影响（是否可被利用）
+- [ ] 识别依赖关系（直接依赖 vs 传递依赖）
+
+### 4. 制定修复方案
+
+根据漏洞严重程度和修复难度制定方案：
+
+**优先方案**：
+1. **升级到安全版本**
+   - 检查是否有修复版本
+   - 评估升级的兼容性风险
+   - 检查是否有破坏性变更
+
+2. **替换依赖**（如果无法升级）
+   - 寻找替代库
+   - 评估迁移成本
+
+3. **缓解措施**（临时方案）
+   - 配置调整
+   - 代码层面的防护
+   - 网络隔离等
+
+### 5. 输出分析文档
+
+创建 `{task_dir}/security-analysis.md`，必须包含以下章节：
+
+```markdown
+# 安全告警分析报告
+
+## 告警基本信息
+
+- **告警编号**: #{alert-number}
+- **严重程度**: {critical/high/medium/low} 🔴/🟠/🟡/🟢
+- **GHSA ID**: {ghsa-id}
+- **CVE ID**: {cve-id}
+- **告警状态**: {open/dismissed/fixed}
+
+## 漏洞详情
+
+### 漏洞描述
+{详细描述漏洞的性质和攻击方式}
+
+### 受影响的依赖
+- **包名**: {package-name}
+- **生态系统**: {maven/pip/npm/...}
+- **当前版本**: {current-version}
+- **受影响版本范围**: {vulnerable-range}
+- **首个修复版本**: {patched-version}
+
+### 依赖文件位置
+- `{manifest-path}` - {说明}
+
+## 影响范围评估
+
+### 直接影响
+- {项目中使用该依赖的模块和文件}
+
+### 漏洞可利用性分析
+- [ ] 是否直接使用了漏洞代码路径？
+- [ ] 是否有外部输入触发漏洞？
+- [ ] 当前配置是否暴露了漏洞？
+
+**结论**: {高/中/低风险 - 说明理由}
+
+## 修复方案
+
+### 推荐方案: {方案名称}
+
+**具体步骤**:
+1. {步骤1}
+2. {步骤2}
+...
+
+**兼容性评估**:
+- {是否有破坏性变更}
+- {需要的代码调整}
+
+**工作量预估**:
+- 复杂度: {高/中/低}
+- 预估时间: {时间}
+- 风险等级: {高/中/低}
+
+### 备选方案（如果有）
+{其他可能的修复方案}
+
+### 临时缓解措施（如果无法立即修复）
+{临时性的防护措施}
+
+## 测试策略
+
+- [ ] {测试项1}
+- [ ] {测试项2}
+- [ ] 验证漏洞已修复
+- [ ] 回归测试
+
+## 参考链接
+
+- GHSA Advisory: https://github.com/advisories/{ghsa-id}
+- CVE Details: https://cve.mitre.org/cgi-bin/cvename.cgi?name={cve-id}
+- {其他相关文档}
+```
+
+### 6. 更新任务状态
+
+更新 `.ai-workspace/active/{task-id}/task.md`：
+- `current_step`: security-analysis
+- `assigned_to`: codex
+- `updated_at`: {当前时间}
+- 标记 security-analysis.md 为已完成
+
+### 7. 告知用户
+
+输出格式：
+```
+🔒 安全告警 #{alert-number} 分析完成
+
+**漏洞信息**:
+- 严重程度: {severity}
+- CVE/GHSA: {cve-id} / {ghsa-id}
+- 受影响包: {package-name}
+
+**任务信息**:
+- 任务ID: {task-id}
+- 任务标题: {title}
+- 风险等级: {高/中/低}
+
+**输出文件**:
+- 任务文件: .ai-workspace/active/{task-id}/task.md
+- 分析文档: {task_dir}/security-analysis.md
+
+**修复建议**: {简短的修复建议摘要}
+
+**下一步**:
+审查安全分析后，使用以下命令设计修复方案：
+/plan-task {task-id}
+
+如果是误报，可以使用以下命令关闭告警：
+/close-security {alert-number}
+```
+
+## 参数说明
+
+- `<alert-number>`: Dependabot 安全告警编号（必需）
+
+## 使用示例
+
+```bash
+# 分析安全告警 #23
+/analyze-security 23
+```
+
+## 注意事项
+
+1. **告警验证**：
+   - 执行前检查告警是否存在
+   - 如果告警已关闭，询问用户是否继续分析
+
+2. **严重程度优先级**：
+   - Critical/High: 立即处理
+   - Medium: 计划处理
+   - Low: 可延后处理
+
+3. **依赖类型区分**：
+   - **直接依赖**: 在依赖文件中明确声明
+   - **传递依赖**: 由其他依赖引入，修复可能需要升级父依赖
+
+4. **误报识别**：
+   - 检查漏洞代码路径是否被使用
+   - 评估实际可利用性
+   - 如确认是误报，建议使用 `/close-security` 关闭
+
+5. **兼容性风险**：
+   - 特别注意跨大版本升级
+   - 查看 CHANGELOG 和 Migration Guide
+   - 评估对现有代码的影响
+
+## 相关命令
+
+- `/close-security <alert-number>` - 关闭安全告警（需提供理由）
+- `/plan-task <task-id>` - 设计修复方案
+- `/task-status <task-id>` - 查看任务状态
+- `/upgrade-dependency` - 升级依赖
+
+## 错误处理
+
+- 告警不存在：提示 "安全告警 #{number} 不存在，请检查告警编号"
+- 网络错误：提示 "无法连接到 GitHub，请检查网络连接"
+- 权限错误：提示 "没有访问该仓库的权限，请检查 GitHub CLI 认证状态"
+- API 限制：提示 "GitHub API 请求限制，请稍后重试"
diff --git a/.codex/commands/block-task.md b/.codex/commands/block-task.md
new file mode 100644
index 000000000..1b2ec41a0
--- /dev/null
+++ b/.codex/commands/block-task.md
@@ -0,0 +1,436 @@
+---
+description: 标记任务阻塞并记录阻塞原因
+usage: /block-task <task-id> [--reason <阻塞原因>]
+argument-hint: <task-id> [--reason=<reason>]
+---
+
+# Block Task Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+当任务遇到无法继续的问题时，使用此命令标记任务为阻塞状态，记录详细的阻塞原因，并将任务移动到 `blocked` 目录，等待问题解决。
+
+## ⚠️ CRITICAL: 状态更新要求
+
+执行此命令后，你**必须**立即更新任务状态并移动任务目录。参见规则 7。
+
+## 使用场景
+
+### 何时使用此命令
+
+在以下情况下应该标记任务为阻塞：
+
+**技术问题**：
+- ❌ 编译失败且无法修复
+- ❌ 测试失败且原因不明
+- ❌ 依赖库存在 Bug
+- ❌ 环境配置问题
+- ❌ 工具链问题
+
+**需求问题**：
+- ❓ 需求不明确，需要澄清
+- ❓ 发现需求冲突
+- ❓ 缺少必要的需求信息
+- ❓ 需要产品决策
+
+**资源问题**：
+- ⏳ 等待外部依赖
+- ⏳ 等待第三方 API 或服务
+- ⏳ 等待数据库迁移
+- ⏳ 等待基础设施就绪
+
+**决策问题**：
+- 🤔 需要架构决策
+- 🤔 需要安全审查
+- 🤔 需要性能优化方案选择
+- 🤔 需要人工审查和批准
+
+### 何时不使用此命令
+
+以下情况**不应该**标记为阻塞：
+
+- ✅ 代码审查发现问题 → 使用 `/refinement-task` 修复
+- ✅ 实现遇到困难但可以解决 → 继续实施
+- ✅ 测试失败但原因清楚 → 修复测试
+- ✅ 文档不完整 → 完善文档
+
+## 执行流程
+
+### 1. 验证任务存在
+
+检查任务文件是否存在：
+```bash
+ls -la .ai-workspace/active/{task-id}/task.md
+```
+
+如果任务不在 `active` 目录，检查是否已经在 `blocked` 或 `completed` 目录。
+
+### 2. 分析阻塞原因
+
+在标记阻塞前，必须仔细分析并记录以下信息：
+
+**问题描述**：
+- 遇到了什么具体问题？
+- 问题出现在哪个步骤？
+- 问题的表现形式是什么？
+
+**根本原因**：
+- 为什么会出现这个问题？
+- 问题的根源是什么？
+- 是否有错误日志或诊断信息？
+
+**尝试的解决方案**：
+- 已经尝试了哪些方法？
+- 为什么这些方法没有解决问题？
+
+**需要的帮助**：
+- 需要谁来帮助解决？
+- 需要什么资源或信息？
+- 预计解决问题需要多长时间？
+
+### 3. 更新任务状态 (CRITICAL)
+
+**必须更新** `.ai-workspace/active/{task-id}/task.md`：
+
+```yaml
+status: blocked
+current_step: {当前步骤，保持不变}
+updated_at: {当前时间，格式: yyyy-MM-dd HH:mm:ss}
+blocked_at: {当前时间，格式: yyyy-MM-dd HH:mm:ss}
+blocked_by: {当前AI}
+blocked_reason: {简短描述阻塞原因}
+```
+
+**在 task.md 中添加"阻塞信息"章节**（在 "注意事项" 之前插入）：
+
+```markdown
+---
+
+## ⚠️ 阻塞信息
+
+### 阻塞概要
+
+- **阻塞时间**: {当前时间}
+- **阻塞步骤**: {current_step}
+- **阻塞者**: {当前AI}
+- **阻塞类型**: {技术问题/需求问题/资源问题/决策问题}
+- **严重程度**: {高/中/低}
+- **预计解决时间**: {预估}
+
+### 问题描述
+
+{详细描述遇到的问题，包括错误信息、日志、截图等}
+
+### 根本原因
+
+{分析问题的根本原因}
+
+### 尝试的解决方案
+
+1. **尝试方法 1**: {描述}
+   - 结果: {失败/部分成功}
+   - 原因: {为什么没有解决}
+
+2. **尝试方法 2**: {描述}
+   - 结果: {失败/部分成功}
+   - 原因: {为什么没有解决}
+
+### 需要的帮助
+
+**需要谁**：{开发者/架构师/产品经理/运维/安全团队}
+
+**需要什么**：
+- 明确 XX 需求
+- 解决 XX 技术问题
+- 提供 XX 资源
+- 做出 XX 决策
+
+**附加信息**：
+{任何有助于解决问题的额外信息}
+
+### 解除阻塞条件
+
+满足以下条件后可以解除阻塞并继续：
+- [ ] 条件 1
+- [ ] 条件 2
+- [ ] 条件 3
+
+### 备用方案
+
+如果问题无法在合理时间内解决，可以考虑：
+- 方案 1: {描述}
+- 方案 2: {描述}
+
+---
+```
+
+### 4. 移动到阻塞目录 (CRITICAL)
+
+将任务从 `active` 目录移动到 `blocked` 目录：
+
+```bash
+# 确保 blocked 目录存在
+mkdir -p .ai-workspace/blocked
+
+# 移动任务目录
+mv .ai-workspace/active/{task-id} .ai-workspace/blocked/
+```
+
+**验证移动成功**：
+```bash
+# 验证源目录不存在
+test ! -d .ai-workspace/active/{task-id} && echo "已移除 active 目录" || echo "ERROR: active 目录仍存在"
+
+# 验证目标目录存在
+test -d .ai-workspace/blocked/{task-id} && echo "已移动到 blocked" || echo "ERROR: 移动失败"
+```
+
+### 5. 可选：同步到 Issue
+
+如果任务关联了 GitHub Issue，使用 `/sync-issue` 更新 Issue 状态：
+
+```bash
+/sync-issue {issue-number}
+```
+
+在 Issue 中添加阻塞说明：
+```markdown
+⚠️ 任务当前处于阻塞状态
+
+**阻塞时间**: {当前时间}
+**阻塞原因**: {简短描述}
+**需要帮助**: {需要什么}
+
+详细信息请查看任务文件：`.ai-workspace/blocked/{task-id}/task.md`
+```
+
+可以添加 `blocked` 标签到 Issue。
+
+### 6. 通知相关人员
+
+告知用户和相关人员任务已阻塞：
+
+**输出格式**：
+```
+⚠️  任务 {task-id} 已标记为阻塞
+
+**任务信息**：
+- 任务ID: {task-id}
+- 任务类型: {type}
+- 阻塞步骤: {current_step}
+- 阻塞时间: {当前时间}
+
+**阻塞原因**：
+{阻塞原因简短描述}
+
+**需要的帮助**：
+{需要谁来帮助，需要什么}
+
+**阻塞位置**：
+- `.ai-workspace/blocked/{task-id}/`
+
+**下一步**：
+1. 查看任务文件中的"阻塞信息"章节了解详情
+2. 解决阻塞问题
+3. 使用 /unblock-task 命令解除阻塞（如果实现了该命令）
+   或手动移回 active 目录：
+   ```bash
+   mv .ai-workspace/blocked/{task-id} .ai-workspace/active/
+   # 然后更新 task.md 中的 status 为 active，移除 blocked_* 字段
+   ```
+
+**关联资源**：
+- Issue: #{issue-number}（已同步）
+- 相关文档: {列出相关文档}
+```
+
+### 7. 创建阻塞日志（可选）
+
+在项目中维护一个阻塞任务列表：
+
+```bash
+# 添加到阻塞日志
+echo "{当前时间} | {task-id} | {阻塞原因} | {需要帮助}" >> .ai-workspace/logs/blocked-tasks.log
+```
+
+## ✅ 完成检查清单
+
+执行此命令后，确认：
+
+- [ ] 已详细分析阻塞原因
+- [ ] 已更新 task.md 中的 `status` 为 blocked
+- [ ] 已更新 task.md 中的 `updated_at` 为当前时间
+- [ ] 已添加 task.md 中的 `blocked_at` 字段
+- [ ] 已添加 task.md 中的 `blocked_by` 字段
+- [ ] 已添加 task.md 中的 `blocked_reason` 字段
+- [ ] 已在 task.md 中添加完整的"阻塞信息"章节
+- [ ] 已将任务从 active 移动到 blocked 目录
+- [ ] 已验证移动成功
+- [ ] 如果有关联 Issue，已同步更新
+- [ ] 已通知用户和相关人员
+- [ ] 已说明解除阻塞的条件
+
+## 解除阻塞
+
+当问题解决后，手动解除阻塞：
+
+```bash
+# 将任务移回 active 目录
+mv .ai-workspace/blocked/{task-id} .ai-workspace/active/
+```
+
+**更新 task.md**：
+```yaml
+status: active
+# 移除以下字段：
+# blocked_at
+# blocked_by
+# blocked_reason
+```
+
+**在"阻塞信息"章节添加解决记录**：
+```markdown
+### 解决记录
+
+- **解决时间**: {当前时间}
+- **解决者**: {解决者}
+- **解决方式**: {如何解决的}
+- **阻塞时长**: {从阻塞到解决的时间}
+```
+
+然后继续任务执行。
+
+## 常见问题
+
+### Q: 如果不确定是否应该标记为阻塞怎么办？
+
+A: 遵循以下原则：
+- 如果问题**你无法解决**，需要外部帮助 → 标记阻塞
+- 如果问题**你可以解决**，只是需要时间 → 不标记阻塞
+- 如果**不确定**，先尝试解决 1-2 小时，仍无进展再标记阻塞
+
+### Q: 可以在任何步骤标记阻塞吗？
+
+A: 可以。任何步骤遇到无法解决的问题都应该标记阻塞，而不是强行继续。
+
+### Q: 阻塞原因应该写多详细？
+
+A: 越详细越好。想象你在写一个故障报告，目标是让接手的人能快速理解问题并解决。
+
+### Q: 如果有多个阻塞问题怎么办？
+
+A: 在"阻塞信息"章节中列出所有问题，按优先级排序。
+
+### Q: 阻塞的任务还会被追踪吗？
+
+A: 会。应该定期检查 `blocked` 目录中的任务，确保问题得到关注和解决。
+
+### Q: 是否需要设置阻塞超时？
+
+A: 建议在"阻塞信息"中标注"预计解决时间"。如果超过预期时间仍未解决，应该：
+1. 重新评估问题
+2. 考虑备用方案
+3. 升级问题优先级
+
+## 阻塞类型和处理建议
+
+### 技术问题阻塞
+
+**特征**：编译失败、测试失败、工具问题
+**处理**：
+1. 收集详细的错误日志
+2. 搜索类似问题的解决方案
+3. 如果是工具 Bug，报告给工具维护者
+4. 考虑使用替代工具或方法
+
+### 需求问题阻塞
+
+**特征**：需求不清晰、需求冲突
+**处理**：
+1. 列出具体的疑问点
+2. 提供多个可能的解释
+3. 标注每个解释的影响
+4. 请产品经理或用户澄清
+
+### 资源问题阻塞
+
+**特征**：等待外部依赖、服务不可用
+**处理**：
+1. 明确等待的资源和预计时间
+2. 检查是否有临时替代方案
+3. 考虑并行进行其他工作
+4. 跟踪资源的准备进度
+
+### 决策问题阻塞
+
+**特征**：需要架构决策、方案选择
+**处理**：
+1. 列出所有可行方案
+2. 分析每个方案的优缺点
+3. 提供推荐方案和理由
+4. 请相关人员做出决策
+
+## 注意事项
+
+### 及时标记
+
+- 不要拖延。一旦确定问题无法解决，立即标记阻塞
+- 不要试图"硬推"。强行继续可能导致更大问题
+
+### 清晰沟通
+
+- 阻塞信息要详细、准确、客观
+- 避免使用模糊的描述，如"有些问题"、"不太行"
+- 提供具体的错误信息、日志、复现步骤
+
+### 主动跟进
+
+- 标记阻塞后，要主动跟进问题解决进度
+- 定期更新阻塞状态
+- 如果有新的信息或尝试，及时更新"阻塞信息"章节
+
+## 相关命令
+
+- `/task-status` - 查看任务状态，包括阻塞任务
+- `/sync-issue` - 同步阻塞状态到 GitHub Issue
+- `/unblock-task` - 解除阻塞（如果实现了该命令）
+
+## 工作流位置
+
+此命令可以在任何工作流步骤中使用，当遇到无法继续的问题时执行。
+
+## 示例
+
+```bash
+# 标记任务为阻塞，并指定原因
+/block-task TASK-20260103-135501 --reason "编译失败：缺少依赖 org.example:foo:1.2.3"
+
+# 仅标记为阻塞，后续手动编辑详细原因
+/block-task TASK-20260103-135501
+```
+
+## 统计和监控
+
+建议定期检查阻塞任务：
+
+```bash
+# 列出所有阻塞任务
+ls -la .ai-workspace/blocked/
+
+# 统计阻塞任务数量
+ls -1 .ai-workspace/blocked/ | wc -l
+
+# 查看阻塞任务的阻塞时长
+# 可以编写脚本分析 blocked_at 字段
+```
+
+对于长期阻塞的任务，考虑：
+1. 重新评估优先级
+2. 寻求额外资源
+3. 考虑取消任务
diff --git a/.codex/commands/close-security.md b/.codex/commands/close-security.md
new file mode 100644
index 000000000..38b080312
--- /dev/null
+++ b/.codex/commands/close-security.md
@@ -0,0 +1,287 @@
+---
+description: 关闭 Dependabot 安全告警（需提供合理理由）
+usage: /close-security <alert-number>
+argument-hint: <alert-number>
+---
+
+# Close Security Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+关闭指定的 Dependabot 安全告警。在关闭前会要求用户确认并提供合理的理由，确保不会误关闭真实的安全风险。
+
+## 执行流程
+
+### 1. 获取安全告警信息
+
+```bash
+gh api repos/{owner}/{repo}/dependabot/alerts/<alert-number>
+```
+
+验证告警状态：
+- 如果已经是 `dismissed` 或 `fixed` 状态，提示用户并退出
+- 如果是 `open` 状态，继续执行
+
+### 2. 展示告警详情
+
+向用户展示告警的关键信息：
+```
+🔒 安全告警 #{alert-number}
+
+严重程度: {severity} 🔴/🟠/🟡/🟢
+漏洞: {summary}
+受影响包: {package-name} ({ecosystem})
+当前版本: {current-version}
+受影响范围: {vulnerable-version-range}
+修复版本: {first-patched-version}
+
+GHSA: {ghsa-id}
+CVE: {cve-id}
+```
+
+### 3. 询问关闭理由
+
+使用 `AskUserQuestion` 工具让用户选择关闭理由：
+
+**问题**: "为什么要关闭这个安全告警？"
+
+**选项**:
+1. **误报 (False Positive)**
+   - 描述: 漏洞代码路径在项目中未被使用，或配置已确保无法触发
+   - 对应 API 参数: `dismissed_reason: "no_bandwidth"`  <!-- GitHub API 中 "no_bandwidth" 通常用于低风险或误报 -->
+
+2. **无法利用 (Not Exploitable)**
+   - 描述: 虽然依赖有漏洞，但在当前项目场景下无法被利用
+   - 对应 API 参数: `dismissed_reason: "tolerable_risk"`
+
+3. **已有缓解措施 (Mitigated)**
+   - 描述: 已通过其他方式（配置、网络隔离等）缓解了风险
+   - 对应 API 参数: `dismissed_reason: "tolerable_risk"`
+
+4. **无修复版本且风险可接受 (No Fix Available)**
+   - 描述: 目前没有修复版本，且评估后认为风险可接受
+   - 对应 API 参数: `dismissed_reason: "no_bandwidth"`
+
+5. **测试或开发依赖 (Dev Dependency Only)**
+   - 描述: 仅在测试或开发环境使用，生产环境不受影响
+   - 对应 API 参数: `dismissed_reason: "tolerable_risk"`
+
+6. **取消**
+   - 描述: 不关闭告警
+   - 操作: 退出命令
+
+### 4. 要求详细说明
+
+如果用户选择关闭（非"取消"），要求用户提供详细的文字说明：
+
+```
+请提供详细的关闭理由（将记录到 GitHub）:
+```
+
+**说明要求**：
+- 最少 20 个字符
+- 清晰说明为什么此告警可以安全关闭
+- 如果是误报，说明为什么代码路径不会被触发
+- 如果有缓解措施，说明具体措施是什么
+
+### 5. 最终确认
+
+显示即将提交的信息，要求最终确认：
+
+```
+⚠️ 即将关闭安全告警 #{alert-number}
+
+告警: {summary}
+严重程度: {severity}
+关闭理由类别: {选择的理由}
+详细说明: {用户输入的说明}
+
+是否确认关闭？(y/N)
+```
+
+- 如果用户输入 `y` 或 `yes`，继续执行
+- 否则，取消操作
+
+### 6. 执行关闭操作
+
+使用 GitHub API 关闭告警：
+
+```bash
+gh api --method PATCH \
+  repos/{owner}/{repo}/dependabot/alerts/<alert-number> \
+  -f state=dismissed \
+  -f dismissed_reason="{API参数}" \
+  -f dismissed_comment="{用户的详细说明}"
+```
+
+**API 参数映射**：
+- `dismissed_reason` 的有效值（根据 GitHub API）:
+  - `fix_started`: 修复工作已开始
+  - `inaccurate`: 告警不准确（误报）
+  - `no_bandwidth`: 暂无资源处理
+  - `not_used`: 受影响的代码未使用
+  - `tolerable_risk`: 可接受的风险
+
+**选项到 API 参数的映射**：
+- 误报 → `not_used` 或 `inaccurate`
+- 无法利用 → `tolerable_risk`
+- 已有缓解措施 → `tolerable_risk`
+- 无修复版本且风险可接受 → `tolerable_risk`
+- 测试或开发依赖 → `not_used`
+
+### 7. 记录到任务（如果存在）
+
+检查是否有相关的安全分析任务：
+- 搜索 `.ai-workspace/active/`、`.ai-workspace/blocked/`、`.ai-workspace/completed/` 中包含 `security_alert_number: <alert-number>` 的任务
+- 如果找到，在任务文件中添加关闭记录：
+
+```yaml
+closed_at: {当前时间}
+closed_reason: {关闭理由类别}
+closed_comment: {用户的详细说明}
+```
+
+并将任务移动到 `completed/` 或 `dismissed/` 目录（根据理由）
+
+### 8. 告知用户
+
+输出格式：
+```
+✅ 安全告警 #{alert-number} 已关闭
+
+**告警信息**:
+- 漏洞: {summary}
+- 严重程度: {severity}
+- 受影响包: {package-name}
+
+**关闭信息**:
+- 关闭理由: {关闭理由类别}
+- 详细说明: {用户的详细说明}
+- 关闭时间: {当前时间}
+
+**查看链接**:
+https://github.com/{owner}/{repo}/security/dependabot/{alert-number}
+
+⚠️ 注意: 如果将来发现此告警应该修复，可以在 GitHub 网页上重新打开。
+```
+
+## 参数说明
+
+- `<alert-number>`: Dependabot 安全告警编号（必需）
+
+## 使用示例
+
+```bash
+# 关闭安全告警 #23
+/close-security 23
+```
+
+## 关闭理由示例
+
+### 示例 1: 误报 - 代码路径未使用
+
+```
+关闭理由: 误报 (False Positive)
+
+详细说明:
+经过代码分析，该漏洞涉及的 langchain.load.dumps/loads API 在我们的项目中
+完全没有被使用。项目仅使用 langchain 的基础 LLM 调用功能，不涉及序列化操作。
+
+验证方法:
+- grep -r "langchain.load" 未找到任何匹配
+- grep -r "dumps\|loads" 仅发现 json 库的使用
+```
+
+### 示例 2: 开发依赖
+
+```
+关闭理由: 测试或开发依赖 (Dev Dependency Only)
+
+详细说明:
+log4j 仅在测试环境中使用，用于测试日志输出功能。生产环境使用 logback
+作为日志框架，不受此漏洞影响。
+
+验证:
+- pom.xml 中 log4j 的 scope 为 test
+- 生产部署配置使用 logback.xml
+```
+
+### 示例 3: 已有缓解措施
+
+```
+关闭理由: 已有缓解措施 (Mitigated)
+
+详细说明:
+虽然依赖存在 TLS 主机名验证问题，但我们的 Socket Appender 配置仅允许
+连接到内网受信任的日志服务器（IP 白名单），且通过 VPN 隔离，无法从公网访问。
+
+缓解措施:
+- 网络隔离: 日志服务器仅在 VPN 内可访问
+- IP 白名单: log4j.xml 配置明确指定可信 IP
+- 监控: 有异常连接告警
+```
+
+## 注意事项
+
+1. **谨慎关闭高危告警**：
+   - Critical/High 严重程度的告警需要特别谨慎
+   - 必须有充分的技术分析支持
+   - 建议先进行安全分析（使用 `/analyze-security`）
+
+2. **理由必须真实准确**：
+   - 关闭记录会保存在 GitHub 中
+   - 可能被安全审计或团队审查
+   - 不要为了清空告警而随意关闭
+
+3. **定期复查**：
+   - 被关闭的告警应定期复查
+   - 项目代码变更可能导致之前的理由失效
+   - 新版本可能提供修复方案
+
+4. **优先考虑修复**：
+   - 关闭应该是最后选择
+   - 优先考虑升级、替换或缓解
+   - 只在确实无法修复或确认无风险时关闭
+
+5. **团队沟通**：
+   - 重要的关闭决定应与团队讨论
+   - 在 Issue 或 PR 中记录决策过程
+   - 确保相关人员知晓
+
+## 相关命令
+
+- `/analyze-security <alert-number>` - 分析安全告警
+- `/plan-task <task-id>` - 设计修复方案
+- `/upgrade-dependency` - 升级依赖
+
+## 错误处理
+
+- 告警不存在：提示 "安全告警 #{number} 不存在，请检查告警编号"
+- 告警已关闭：提示 "安全告警 #{number} 已经是 {state} 状态"
+- 权限错误：提示 "没有权限修改安全告警，请检查 GitHub CLI 认证状态"
+- API 错误：提示 "关闭失败: {错误信息}"
+- 用户取消：提示 "已取消关闭操作"
+
+## 最佳实践
+
+1. **先分析再关闭**：
+   ```bash
+   # 推荐的工作流程
+   /analyze-security 23    # 先进行详细分析
+   # 审查分析报告
+   /close-security 23      # 确认后再关闭
+   ```
+
+2. **记录决策过程**：
+   - 在关闭说明中引用分析文档
+   - 说明谁做的决定、基于什么分析
+
+3. **建立复查机制**：
+   - 定期（如每季度）复查已关闭的告警
+   - 在项目升级时重新评估
diff --git a/.codex/commands/commit.md b/.codex/commands/commit.md
new file mode 100644
index 000000000..cbfbe2af8
--- /dev/null
+++ b/.codex/commands/commit.md
@@ -0,0 +1,421 @@
+---
+description: 提交当前变更到 Git（提供最佳实践指南）
+usage: /prompts:commit
+---
+
+# Commit Command
+
+提交当前变更到 Git。
+
+**此命令提供 Git 提交的最佳实践指南。**
+
+**用法：**
+- `/prompts:commit` - 查看提交指南
+
+**功能说明：**
+
+本命令会引导你完成以下步骤：
+1. 检查并更新版权头年份（CRITICAL）
+2. 分析变更内容并生成提交信息
+3. 执行 Git 提交操作
+4. 更新任务状态（如适用）
+
+**注意事项：**
+- 不要提交包含敏感信息的文件（.env, credentials 等）
+- 确保提交消息清晰描述了变更内容
+- 遵循项目的 commit message 规范
+- 提交前必须检查版权头年份（见下文）
+
+---
+
+## ⚠️ 提交前的版权头年份检查（CRITICAL）
+
+**强制要求**：在执行提交之前，**必须**检查并更新所有修改文件的版权头年份。参见项目规则第 5 条。
+
+### 检查流程
+
+**步骤 1：自动获取当前年份**
+```bash
+# 动态获取当前年份（绝对不要硬编码）
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+CURRENT_YEAR=$(date +%Y)
+echo "当前年份: $CURRENT_YEAR"
+```
+
+**步骤 2：检查修改的文件**
+```bash
+# 查看即将提交的文件
+git status --short
+
+# 或查看已暂存的文件
+git diff --cached --name-only
+```
+
+**步骤 3：检查版权头**
+
+对于每个修改的文件：
+```bash
+# 检查文件是否包含版权头
+grep -l "Copyright" <modified_file>
+
+# 查看版权年份
+grep "Copyright.*[0-9]\{4\}" <modified_file>
+```
+
+**步骤 4：更新版权年份**
+
+如果文件包含版权头且年份不是当前年份，使用 `Edit` 工具更新：
+
+**常见格式：**
+- `Copyright (C) 2024-2025` → `Copyright (C) 2024-<CURRENT_YEAR>`
+- `Copyright (C) 2024` → `Copyright (C) 2024-<CURRENT_YEAR>`
+- `Copyright (C) 2025` → `Copyright (C) <CURRENT_YEAR>`（如果已是当前年）
+
+**示例：**
+```bash
+# 示例输出：命令返回 2026
+
+# 格式 1：年份范围
+Edit(
+  file_path="src/example.java",
+  old_string="Copyright (C) 2024-2025 FIT Framework",
+  new_string="Copyright (C) 2024-2026 FIT Framework"
+)
+
+# 格式 2：单一年份
+Edit(
+  file_path="src/another.java",
+  old_string="Copyright (C) 2024 FIT Framework",
+  new_string="Copyright (C) 2024-2026 FIT Framework"
+)
+```
+
+### 检查清单
+
+在执行 `git commit` 之前，必须确认：
+
+- [ ] 已使用 `date +%Y` 动态获取当前年份
+- [ ] 不需要也不允许手动输入年份
+- [ ] 已检查所有即将提交的修改文件
+- [ ] 对于包含版权头的文件，已检查年份是否为当前年份
+- [ ] 如果年份不是当前年份，已使用 `Edit` 工具更新
+- [ ] **绝对不要**硬编码年份（如 2026）
+- [ ] **只更新修改的文件**，不批量更新项目中所有文件
+
+### 为什么必须这样做
+
+- **法律合规**：确保版权声明的准确性和法律有效性
+- **项目规范**：遵循 FIT Framework 的项目规范
+- **自动化**：动态获取年份确保在任何时间点执行都是正确的
+- **避免遗漏**：提交前检查确保不会遗漏任何文件
+
+### 完整示例
+
+```bash
+# 1. 获取当前年份
+CURRENT_YEAR=$(date +%Y)
+# 输出：2026
+
+# 2. 查看修改的文件
+git status --short
+# M src/main/java/com/fit/Example.java
+# M src/test/java/com/fit/ExampleTest.java
+
+# 3. 检查第一个文件的版权头
+grep "Copyright" src/main/java/com/fit/Example.java
+# Copyright (C) 2024-2025 FIT Framework
+
+# 4. 更新版权头（使用 Edit 工具）
+Edit(
+  file_path="src/main/java/com/fit/Example.java",
+  old_string="Copyright (C) 2024-2025 FIT Framework",
+  new_string="Copyright (C) 2024-2026 FIT Framework"
+)
+
+# 5. 检查第二个文件的版权头
+grep "Copyright" src/test/java/com/fit/ExampleTest.java
+# Copyright (C) 2024-2025 FIT Framework
+
+# 6. 更新版权头（使用 Edit 工具）
+Edit(
+  file_path="src/test/java/com/fit/ExampleTest.java",
+  old_string="Copyright (C) 2024-2025 FIT Framework",
+  new_string="Copyright (C) 2024-2026 FIT Framework"
+)
+
+# 7. 验证更新
+grep "Copyright" src/main/java/com/fit/Example.java
+# Copyright (C) 2024-2026 FIT Framework
+
+# 8. 现在可以安全提交
+/commit
+```
+
+### 违反此规则的后果
+
+如果不更新版权头年份：
+- 版权声明过时，可能影响法律效力
+- 违反项目规范，PR 审查不通过
+- 需要额外的修复提交，增加工作量
+
+**这是一个 CRITICAL 规则，必须在每次提交前执行。**
+
+---
+
+## ⚠️ 提交后的任务状态更新（CRITICAL）
+
+提交代码后，你**必须**根据情况更新任务状态。参见规则 7。
+
+### 情况 1：这是最终提交（任务完成）
+
+如果这是任务的最后一次提交，所有工作已完成：
+
+```bash
+# 执行 /complete-task 归档任务
+/complete-task <task-id>
+```
+
+**检查清单**：
+- [ ] 所有代码已提交
+- [ ] 所有测试通过
+- [ ] 代码审查已通过
+- [ ] 任务的所有工作流步骤已完成
+- [ ] 已执行 `/complete-task` 归档任务
+
+### 情况 2：还需要继续工作（任务未完成）
+
+如果提交后还有后续工作（如等待审查、需要修复等）：
+
+**必须更新**：
+- 更新 `task.md` 中的 `updated_at` 为当前时间
+- 在任务中记录本次提交的内容和下一步计划
+
+**示例**：
+```markdown
+## 交接信息
+
+### 最近的提交
+
+- **提交时间**: {当前时间}
+- **提交内容**: {简要描述}
+- **提交哈希**: {commit-hash}
+- **下一步**: {说明接下来要做什么}
+```
+
+### 情况 3：提交后需要审查
+
+如果提交后需要代码审查：
+
+**必须更新**：
+- 更新 `task.md` 中的 `current_step` 为 `code-review`
+- 更新 `task.md` 中的 `updated_at` 为当前时间
+- 在"工作流进度"中标记实现步骤为完成 ✅
+- 通知用户进行代码审查
+
+**下一步命令**：
+```bash
+/review-task <task-id>
+```
+
+### 情况 4：提交后需要创建 PR
+
+如果提交后需要创建 Pull Request：
+
+**建议流程**：
+1. 手动推送分支：`git push origin <branch-name>`
+2. 使用 `gh pr create` 创建 PR
+3. PR 创建后，更新任务状态
+
+**必须更新**：
+- 更新 `task.md` 中的 `updated_at`
+- 在任务中记录 PR 编号
+- 如果 PR 合并后任务完成，执行 `/complete-task`
+
+### 违反此规则的后果
+
+如果提交后不更新任务状态：
+- 任务状态与实际进度不一致
+- 无法追踪任务是否完成
+- 已完成的任务可能被遗忘在 `active` 目录
+
+**这是一个 CRITICAL 要求，必须遵守。**
+
+---
+
+## 执行 Git 提交
+
+在完成版权头检查后，执行以下步骤进行提交。
+
+### 步骤 1：查看变更
+
+```bash
+# 查看工作区状态
+git status
+
+# 查看已暂存的变更
+git diff --cached
+
+# 如果还没暂存，先暂存文件
+git add <file-path>
+```
+
+### 步骤 2：分析变更并生成提交信息
+
+参考最近的提交风格：
+```bash
+# 查看最近 10 个提交
+git log -10 --oneline
+
+# 查看最近的提交消息格式
+git log -3 --format="%s"
+```
+
+**提交消息格式建议**：
+- 使用项目规范的格式（如 Conventional Commits）
+- 第一行简明扼要（50字符以内）
+- 如需详细说明，空一行后添加正文
+- 说明改动的原因，而非改动的内容
+
+### 步骤 3：创建提交
+
+使用 HEREDOC 格式保证提交消息格式正确：
+
+```bash
+git commit -m "$(cat <<'EOF'
+<type>(<scope>): <subject>
+
+<body>
+
+Co-Authored-By: Codex CLI <noreply@openai.com>
+EOF
+)"
+```
+
+**示例**：
+```bash
+git commit -m "$(cat <<'EOF'
+docs: 更新 Codex 命令配置说明
+
+- 移除对 Claude Code 插件的引用
+- 添加基于 Git 命令的实际操作步骤
+- 保留版权头检查和任务状态更新规则
+
+Co-Authored-By: Codex CLI <noreply@openai.com>
+EOF
+)"
+```
+
+### 步骤 4：验证提交
+
+```bash
+# 查看最后一次提交
+git log -1
+
+# 查看提交的内容
+git show HEAD
+```
+
+### 步骤 5：推送到远程（如需要）
+
+```bash
+# 推送到远程分支
+git push origin <branch-name>
+
+# 如果是新分支，使用 -u 设置上游
+git push -u origin <branch-name>
+```
+
+---
+
+## 完整示例
+
+以下是完整的提交流程示例：
+
+```bash
+# 1. 获取当前年份
+CURRENT_YEAR=$(date +%Y)
+echo "当前年份: $CURRENT_YEAR"
+
+# 2. 查看修改的文件
+git status --short
+
+# 3. 检查版权头（假设修改了 Example.java）
+grep "Copyright" src/main/java/com/fit/Example.java
+
+# 4. 如需要，更新版权头（使用 Edit 工具）
+
+# 5. 暂存文件
+git add src/main/java/com/fit/Example.java
+
+# 6. 查看暂存的变更
+git diff --cached
+
+# 7. 参考最近的提交格式
+git log -3 --oneline
+
+# 8. 创建提交
+git commit -m "$(cat <<'EOF'
+feat(core): 添加用户认证功能
+
+- 实现 JWT 令牌生成和验证
+- 添加登录和登出接口
+- 更新相关测试用例
+
+Co-Authored-By: Codex CLI <noreply@openai.com>
+EOF
+)"
+
+# 9. 验证提交
+git log -1
+
+# 10. 推送到远程
+git push origin feature/user-auth
+```
+
+---
+
+## 相关命令
+
+- `/prompts:review-task <task-id>` - 代码审查（提交前）
+- `/prompts:create-pr <target-branch>` - 创建 Pull Request（提交后）
+- `/prompts:complete-task <task-id>` - 归档任务（工作完成后）
+
+---
+
+## 常见问题
+
+### Q: 如何撤销上一次提交？
+
+```bash
+# 撤销提交但保留更改
+git reset --soft HEAD~1
+
+# 撤销提交并删除更改
+git reset --hard HEAD~1
+```
+
+### Q: 如何修改上一次提交消息？
+
+```bash
+# 如果还没推送到远程
+git commit --amend
+
+# 修改提交消息后强制推送（谨慎使用）
+git push --force origin <branch-name>
+```
+
+### Q: 提交后发现遗漏了文件怎么办？
+
+```bash
+# 暂存遗漏的文件
+git add <forgotten-file>
+
+# 追加到上一次提交（如果还没推送）
+git commit --amend --no-edit
+```
diff --git a/.codex/commands/complete-task.md b/.codex/commands/complete-task.md
new file mode 100644
index 000000000..61ceb91cb
--- /dev/null
+++ b/.codex/commands/complete-task.md
@@ -0,0 +1,303 @@
+---
+description: 标记任务完成并归档到 completed 目录
+usage: /complete-task <task-id>
+argument-hint: <task-id>
+---
+
+# Complete Task Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+标记任务为已完成状态，更新任务元数据，并将任务从 `active` 目录移动到 `completed` 目录进行归档。
+
+## ⚠️ CRITICAL: 状态更新要求
+
+执行此命令后，你**必须**立即更新任务状态并移动任务目录。参见规则 7。
+
+## 前置条件
+
+在执行此命令前，请确认以下条件全部满足：
+
+- [ ] 所有工作流步骤已完成
+- [ ] 代码已审查通过（review.md 显示批准）
+- [ ] 代码已提交到 Git
+- [ ] 代码已合并到目标分支（如果需要）
+- [ ] 所有测试通过
+- [ ] Issue 已同步更新（如果有关联 Issue）
+- [ ] PR 已合并（如果有 PR）
+
+**如果以上条件未全部满足，请勿执行此命令。**
+
+## 执行流程
+
+### 1. 验证任务存在
+
+检查任务文件是否存在：
+```bash
+ls -la .ai-workspace/active/{task-id}/task.md
+```
+
+如果任务不在 `active` 目录，检查是否已经在 `completed` 或 `blocked` 目录。
+
+### 2. 读取并验证任务状态
+
+读取 `.ai-workspace/active/{task-id}/task.md`，检查：
+
+**工作流进度**：
+- 所有步骤是否标记为完成 ✅
+- `current_step` 是否为最后一步（如 `finalize` 或 `code-review`）
+
+**任务状态**：
+- `status` 是否为 `active`（即将改为 `completed`）
+- 是否有未解决的阻塞问题
+
+**文件完整性**：
+- [ ] `analysis.md` 或 `security-analysis.md` 存在（如果是 feature-development 或 security-fix）
+- [ ] `plan.md` 存在（如果是 feature-development）
+- [ ] `implementation.md` 存在
+- [ ] `review.md` 存在且显示批准
+
+如果发现任何问题，提示用户并**停止执行**。
+
+### 3. 更新任务状态 (CRITICAL)
+
+**必须更新** `.ai-workspace/active/{task-id}/task.md`：
+
+```yaml
+status: completed
+current_step: finalize
+updated_at: {当前时间，格式: yyyy-MM-dd HH:mm:ss}
+completed_at: {当前时间，格式: yyyy-MM-dd HH:mm:ss}
+```
+
+**在工作流进度中标记所有步骤完成**：
+```markdown
+## 工作流进度
+
+- [x] requirement-analysis (codex, {日期})
+- [x] technical-design (codex, {日期})
+- [x] implementation (codex, {日期})
+- [x] code-review (codex, {日期})
+- [x] finalize (codex, {当前日期})  ← 标记为完成
+```
+
+**添加完成总结**（在 task.md 末尾添加）：
+```markdown
+---
+
+## 任务完成总结
+
+### 完成信息
+
+- **完成时间**: {当前时间}
+- **完成者**: {当前AI}
+- **关联 PR**: #{pr-number}（如果有）
+- **关联 Issue**: #{issue-number}（如果有）
+- **目标分支**: {分支名}
+
+### 交付成果
+
+- [x] 需求分析文档: `analysis.md`
+- [x] 技术方案文档: `plan.md`
+- [x] 实现报告: `implementation.md`
+- [x] 代码审查报告: `review.md`
+- [x] 代码提交: {commit-hash}
+- [x] PR 合并: #{pr-number}
+
+### 任务完成标准
+
+- [x] 功能完整实现
+- [x] 代码审查通过
+- [x] 所有测试通过
+- [x] 文档完整
+- [x] 代码已合并
+
+### 备注
+
+{如有需要，添加备注}
+```
+
+### 4. 归档任务 (CRITICAL)
+
+将任务从 `active` 目录移动到 `completed` 目录：
+
+```bash
+# 确保 completed 目录存在
+mkdir -p .ai-workspace/completed
+
+# 移动任务目录
+mv .ai-workspace/active/{task-id} .ai-workspace/completed/
+```
+
+**验证移动成功**：
+```bash
+# 验证源目录不存在
+test ! -d .ai-workspace/active/{task-id} && echo "已移除 active 目录" || echo "ERROR: active 目录仍存在"
+
+# 验证目标目录存在
+test -d .ai-workspace/completed/{task-id} && echo "已归档到 completed" || echo "ERROR: 归档失败"
+```
+
+### 5. 可选：同步到 Issue
+
+如果任务关联了 GitHub Issue，使用 `/sync-issue` 更新 Issue 状态：
+
+```bash
+/sync-issue {issue-number}
+```
+
+在 Issue 中添加完成总结：
+```markdown
+✅ 任务已完成
+
+**完成时间**: {当前时间}
+**关联 PR**: #{pr-number}
+**任务 ID**: {task-id}
+
+所有工作已完成，任务已归档到 `.ai-workspace/completed/{task-id}`。
+```
+
+### 6. 可选：更新里程碑
+
+如果任务是里程碑的一部分，更新里程碑进度：
+- 在项目管理工具中标记任务完成
+- 更新里程碑的完成百分比
+
+### 7. 告知用户
+
+输出格式：
+```
+🎉 任务 {task-id} 已完成并归档
+
+**任务信息**：
+- 任务ID: {task-id}
+- 任务类型: {type}
+- 工作流: {workflow}
+- 完成时间: {当前时间}
+
+**归档位置**：
+- `.ai-workspace/completed/{task-id}/`
+
+**关联资源**：
+- PR: #{pr-number}（已合并）
+- Issue: #{issue-number}（已同步）
+- Commit: {commit-hash}
+
+**交付成果**：
+- ✅ 需求分析文档
+- ✅ 技术方案文档
+- ✅ 实现报告
+- ✅ 代码审查报告
+- ✅ 代码提交并合并
+
+**统计信息**：
+- 修改文件: {文件数量}
+- 代码行数: +{新增行数} -{删除行数}
+- 工作时长: {从创建到完成的时间}
+
+任务已成功归档！🎊
+```
+
+## ✅ 完成检查清单
+
+执行此命令后，确认：
+
+- [ ] 已验证所有前置条件满足
+- [ ] 已更新 task.md 中的 `status` 为 completed
+- [ ] 已更新 task.md 中的 `current_step` 为 finalize
+- [ ] 已更新 task.md 中的 `updated_at` 为当前时间
+- [ ] 已添加 task.md 中的 `completed_at` 字段
+- [ ] 已在"工作流进度"中标记所有步骤为完成 ✅
+- [ ] 已添加"任务完成总结"章节
+- [ ] 已将任务从 active 移动到 completed 目录
+- [ ] 已验证移动成功
+- [ ] 如果有关联 Issue，已同步更新
+- [ ] 已告知用户任务完成
+
+## 常见问题
+
+### Q: 如果任务还有未完成的步骤怎么办？
+
+A: **不要执行此命令**。请完成所有步骤后再归档任务。如果某个步骤无法完成，应该使用 `/block-task` 标记为阻塞。
+
+### Q: 如果代码已提交但 PR 未合并怎么办？
+
+A: 等待 PR 合并后再执行此命令。任务完成意味着代码已经合并到主分支。
+
+### Q: 如果审查发现问题但选择不修复怎么办？
+
+A: 必须在 `review.md` 中说明原因并获得批准。如果有阻塞问题未修复，不能标记任务完成。
+
+### Q: 已归档的任务还能修改吗？
+
+A: 可以读取但不建议修改。如果发现问题，应该创建新任务进行修复。
+
+### Q: 如果任务是多人协作完成的怎么办？
+
+A: 在"任务完成总结"中列出所有贡献者。`completed_by` 字段记录最后归档操作的执行者。
+
+### Q: 需要同时关闭 Issue 吗？
+
+A: 使用 `/sync-issue` 会更新 Issue 状态，但是否关闭由用户决定。通常任务完成后应该关闭 Issue。
+
+## 注意事项
+
+### 不要过早归档
+
+只有在**真正完成**所有工作后才归档任务。常见的"未完成"情况：
+- ❌ 代码已提交但测试失败
+- ❌ PR 已创建但未合并
+- ❌ 审查未通过
+- ❌ 还有已知问题待修复
+- ❌ 文档不完整
+
+### 确保数据完整
+
+归档前确认所有文档都已创建：
+- `analysis.md` 或 `security-analysis.md`
+- `plan.md`
+- `implementation.md`
+- `review.md`
+
+### 验证移动成功
+
+移动目录后必须验证：
+- 源目录 (`active/{task-id}`) 不存在
+- 目标目录 (`completed/{task-id}`) 存在且内容完整
+
+## 相关命令
+
+- `/task-status` - 查看任务状态，确认是否满足完成条件
+- `/sync-issue` - 同步任务状态到 GitHub Issue
+- `/block-task` - 如果发现任务无法完成，使用此命令标记阻塞
+
+## 工作流位置
+
+此命令对应 `.ai-agents/workflows/feature-development.yaml` 中的 **finalize** 步骤。
+
+## 示例
+
+```bash
+# 标记 TASK-20260103-135501 为完成并归档
+/complete-task TASK-20260103-135501
+```
+
+## 回滚操作
+
+如果误操作归档了任务，可以手动回滚：
+
+```bash
+# 将任务移回 active 目录
+mv .ai-workspace/completed/{task-id} .ai-workspace/active/
+
+# 更新任务状态
+# 编辑 task.md，将 status 改回 active，移除 completed_at
+```
+
+但请谨慎操作，误归档通常说明流程有问题。
diff --git a/.codex/commands/create-pr.md b/.codex/commands/create-pr.md
new file mode 100644
index 000000000..121110b57
--- /dev/null
+++ b/.codex/commands/create-pr.md
@@ -0,0 +1,91 @@
+---
+description: 创建 Pull Request
+usage: /create-pr <target-branch>
+argument-hint: <target-branch>
+---
+
+# Create PR Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+创建 Pull Request 到指定分支。目标分支必须由用户明确提供。
+
+## 用法
+
+- `/create-pr main` - 创建PR到 main 分支
+- `/create-pr 3.6.x` - 创建PR到 3.6.x 分支
+- `/create-pr <target-branch>` - 创建PR到指定目标分支
+
+## 执行步骤
+
+### 1. 确认目标分支
+
+- 目标分支必须由用户明确提供（如 `main`, `3.5.x`, `develop`）
+- 如果未提供目标分支，提示用户补充并停止执行
+- 命令格式为 `/create-pr <target-branch>`，参数部分即为合入的目标分支
+
+### 2. 读取 PR 模板
+
+必须执行：
+```bash
+Read(".github/PULL_REQUEST_TEMPLATE.md")
+```
+
+### 3. 查看最近 3 个 merged PR 作为参考
+
+必须执行：
+```bash
+gh pr list --limit 3 --state merged --json number,title,body
+```
+
+### 4. 分析当前分支的完整变更
+
+- 运行 `git status` 查看当前状态
+- 运行 `git log <target-branch>..HEAD --oneline` 查看所有提交
+- 运行 `git diff <target-branch>...HEAD --stat` 查看变更统计
+- 运行 `git diff <target-branch>...HEAD` 查看详细变更（如果需要）
+
+### 5. 检查远程分支状态
+
+```bash
+git rev-parse --abbrev-ref --symbolic-full-name @{u}
+```
+
+### 6. 如果分支未推送，先推送
+
+```bash
+git push -u origin <current-branch>
+```
+
+### 7. 根据模板创建 PR
+
+- 按照 `.github/PULL_REQUEST_TEMPLATE.md` 格式填写所有部分
+- 参考最近的 PR 格式和风格
+- 使用 HEREDOC 格式传递 body
+- PR 结尾必须添加：`🤖 Generated with [Codex CLI](https://developers.openai.com/codex/cli)`
+
+```bash
+gh pr create --base <target-branch> --title "<标题>" --body "$(cat <<'EOF'
+<完整的PR描述>
+EOF
+)"
+```
+
+## 注意事项
+
+- 必须严格遵循 PR 模板格式
+- 所有必填项都要填写完整
+- 参考最近的 merged PR 的格式和风格
+- 确保 PR 标题格式正确（如：`[模块名] 简短描述`）
+
+## 相关命令
+
+- `/sync-pr <task-id>` - 同步进度到 PR
+- `/commit` - 提交代码
+- `/review-task` - 代码审查
diff --git a/.codex/commands/implement-task.md b/.codex/commands/implement-task.md
new file mode 100644
index 000000000..f5d8cb0c0
--- /dev/null
+++ b/.codex/commands/implement-task.md
@@ -0,0 +1,221 @@
+---
+description: 根据技术方案实施任务并输出实现报告
+usage: /implement-task <task-id>
+argument-hint: <task-id>
+---
+
+# Implement Task Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+根据技术方案实施任务，编写代码和测试，输出实现报告。
+
+## ⚠️ CRITICAL: 状态更新要求
+
+执行此命令后，你**必须**立即更新任务状态。参见规则 7。
+
+## 执行流程
+
+### 1. 验证前置条件
+
+检查必需文件：
+- `.ai-workspace/active/{task-id}/task.md` - 任务文件
+- `{task_dir}/plan.md` - 技术方案
+
+如果任一文件不存在，提示用户先完成前置步骤。
+
+### 2. 读取技术方案
+
+仔细阅读 `plan.md`，理解：
+- 技术方案和实现策略
+- 详细的实施步骤
+- 需要创建/修改的文件清单
+- 测试策略
+
+### 3. 执行代码实现
+
+按照 `.ai-agents/workflows/feature-development.yaml` 中的 `implementation` 步骤：
+
+**必须完成的任务**：
+- [ ] 按照方案实现功能代码
+- [ ] 编写完整的单元测试
+- [ ] 本地运行测试验证功能
+- [ ] 更新相关文档和注释
+- [ ] 遵循项目编码规范
+
+**实施原则**：
+1. **严格遵循方案**：不要偏离技术方案
+2. **分步实施**：按照 plan.md 中的步骤顺序执行
+3. **及时测试**：每完成一个步骤就运行测试
+4. **保持简洁**：不要过度设计或添加额外功能
+
+### 4. 运行测试验证
+
+```bash
+# 根据项目类型运行测试
+mvn test -pl :{module-name}  # Maven 项目
+npm test                      # Node.js 项目
+pytest                        # Python 项目
+```
+
+确保所有测试通过。
+
+### 5. 输出实现报告
+
+创建 `{task_dir}/implementation.md`，必须包含以下章节：
+
+```markdown
+# 实现报告
+
+## 已修改文件列表
+
+### 新增文件
+- `{file-path}` - {说明}
+
+### 修改文件
+- `{file-path}` - {修改内容摘要}
+
+## 关键代码说明
+
+### {模块/功能名称}
+**文件**: `{file-path}:{line-number}`
+
+**实现逻辑**：
+{重要逻辑的解释}
+
+**关键代码**：
+```{language}
+{关键代码片段}
+```
+
+## 测试结果
+
+### 单元测试
+- 测试文件: `{test-file-path}`
+- 测试用例数: {数量}
+- 通过率: {百分比}
+
+**测试输出**：
+```
+{测试运行结果}
+```
+
+### 集成测试
+{如果有}
+
+## 与方案的差异
+
+{如果实现与方案有差异，说明原因}
+
+## 待审查事项
+
+**需要 reviewer 特别关注的点**：
+- {关注点1}
+- {关注点2}
+
+## 已知问题
+
+{实现过程中发现的问题或待优化项}
+
+## 下一步建议
+
+{对代码审查的建议或后续优化方向}
+```
+
+### 6. 更新任务状态
+
+更新 `.ai-workspace/active/{task-id}/task.md`：
+- `current_step`: implementation
+- `assigned_to`: {当前 AI}
+- `updated_at`: {当前时间}
+- 标记 implementation.md 为已完成
+- 在工作流进度中标记代码实现为完成
+
+### 7. 告知用户
+
+输出格式：
+```
+✅ 任务 {task-id} 实现完成
+
+**实现概要**：
+- 修改文件: {数量} 个
+- 新增文件: {数量} 个
+- 测试通过: {数量}/{总数}
+
+**输出文件**：
+- 实现报告: {task_dir}/implementation.md
+
+**下一步**：
+使用以下命令进行代码审查：
+/prompts:review-task {task-id}
+```
+
+## ✅ 完成检查清单
+
+执行此命令后，确认：
+
+- [ ] 已完成所有代码实施
+- [ ] 已创建实现报告 `{task_dir}/implementation.md`
+- [ ] 已更新 task.md 中的 `current_step` 为 implementation
+- [ ] 已更新 task.md 中的 `updated_at` 为当前时间
+- [ ] 已更新 task.md 中的 `assigned_to` 为你的名字
+- [ ] 已在"工作流进度"中标记 technical-design 为完成 ✅
+- [ ] 已在"工作流进度"中标记 implementation 为进行中
+- [ ] 已在 task.md 中标记 implementation.md 为已完成
+- [ ] 已告知用户下一步操作（/review-task）
+
+## 参数说明
+
+- `<task-id>`: 任务ID，格式为 TASK-{yyyyMMdd-HHmmss}（必需）
+
+## 使用示例
+
+```bash
+# 实施任务
+/implement-task TASK-20251227-104654
+```
+
+## 注意事项
+
+1. **前置条件**：
+   - 必须先完成技术方案设计（plan.md 存在）
+   - 方案必须经过人工审查批准
+
+2. **实施规范**：
+   - 严格按照 plan.md 中的步骤执行
+   - 不要添加计划外的功能
+   - 遵循项目编码规范
+
+3. **测试要求**：
+   - 所有新增代码必须有单元测试
+   - 测试覆盖率不低于原有水平
+   - 所有测试必须通过
+
+4. **代码质量**：
+   - 遵循项目编码规范
+   - 添加必要的注释
+   - 保持代码简洁
+
+5. **Git 操作**：
+   - **不要**自动执行 git commit
+   - 实现完成后等待代码审查
+   - 审查通过后才能提交
+
+## 相关命令
+
+- `/prompts:plan-task <task-id>` - 设计技术方案（前置步骤）
+- `/prompts:review-task <task-id>` - 代码审查（后续步骤）
+- `/prompts:task-status <task-id>` - 查看任务状态
+
+## 错误处理
+
+- 任务不存在：提示 "任务 {task-id} 不存在"
+- 缺少技术方案：提示 "技术方案不存在，请先执行 /plan-task"
+- 测试失败：输出测试错误，询问是否继续
+- 编译失败：输出编译错误，停止实施
diff --git a/.codex/commands/plan-task.md b/.codex/commands/plan-task.md
new file mode 100644
index 000000000..857f54aa2
--- /dev/null
+++ b/.codex/commands/plan-task.md
@@ -0,0 +1,209 @@
+---
+description: 为任务设计技术方案并输出实施计划
+usage: /plan-task <task-id>
+argument-hint: <task-id>
+---
+
+# Plan Task Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+为指定任务设计技术方案,输出详细的实施计划。
+
+## ⚠️ CRITICAL: 状态更新要求
+
+执行此命令后，你**必须**立即更新任务状态。参见规则 7。
+
+## 执行流程
+
+### 1. 查找任务文件
+
+按以下优先级搜索任务：
+- 查找 `.ai-workspace/active/{task-id}/task.md`（优先）
+- 如果不存在，查找 `.ai-workspace/blocked/{task-id}/task.md`
+- 如果不存在，查找 `.ai-workspace/completed/{task-id}/task.md`
+- 如果都不存在，提示用户任务不存在
+
+找到后记录任务状态（status）和任务目录路径（task_dir）。
+
+### 2. 读取需求分析
+
+读取 `{task_dir}/analysis.md`：
+- 如果不存在，提示用户需要先执行需求分析
+- 如果存在，读取并理解需求
+
+### 3. 设计技术方案
+
+按照 `.ai-agents/workflows/feature-development.yaml` 中的 `technical-design` 步骤：
+
+**必须完成的任务**：
+- [ ] 设计技术实现方案
+- [ ] 选择合适的技术栈和设计模式
+- [ ] 制定详细的实施步骤
+- [ ] 列出需要创建/修改的文件清单
+- [ ] 设计测试策略
+- [ ] 评估性能和安全影响
+
+### 4. 输出方案文档
+
+创建 `{task_dir}/plan.md`，必须包含以下章节：
+
+```markdown
+# 技术方案和实施计划
+
+## 方案决策
+
+### 方案对比分析
+{如果有多个方案，对比分析各方案的优劣}
+
+### 最终选择
+- **方案**：{选择的方案}
+- **理由**：{选择理由}
+
+## 技术方案
+
+### 核心实现策略
+{详细的实现策略}
+
+### 关键技术点
+- {技术点1}
+- {技术点2}
+
+## 实施步骤
+
+### 步骤 1: {步骤名称}
+**操作**：{具体操作}
+**预期结果**：{预期结果}
+
+### 步骤 2: {步骤名称}
+...
+
+## 文件清单
+
+### 需要创建的文件
+- `{file-path}` - {说明}
+
+### 需要修改的文件
+| 序号 | 文件路径 | 修改内容 | 预计行数 |
+|------|----------|----------|----------|
+| 1 | {path} | {内容} | {行数} |
+
+## 测试策略
+
+### 单元测试
+- {测试范围和验收标准}
+
+### 集成测试
+- {测试范围和验收标准}
+
+## 性能考虑
+{性能影响分析和优化建议}
+
+## 安全考虑
+{安全风险评估和防护措施}
+
+## 回滚方案
+{如果实施失败，如何回滚}
+
+## 风险控制
+| 风险 | 等级 | 应对措施 |
+|------|------|----------|
+| {风险} | {等级} | {措施} |
+
+## 预期产出
+- {产出1}
+- {产出2}
+```
+
+### 5. 更新任务状态
+
+更新 `.ai-workspace/active/{task-id}/task.md`：
+- `current_step`: technical-design
+- `assigned_to`: codex
+- `updated_at`: {当前时间}
+- 标记 plan.md 为已完成
+- 在工作流进度中标记技术方案设计为完成
+
+### 6. 告知用户
+
+输出格式：
+```
+✅ 任务 {task-id} 技术方案设计完成
+
+**方案概要**：
+- 最终方案: {方案名称}
+- 工作量: {预估}
+- 风险等级: {等级}
+
+**输出文件**：
+- 方案文档: {task_dir}/plan.md
+
+**下一步**：
+⚠️  **人工审查检查点** - 请审查技术方案是否合理
+
+审查通过后，使用以下命令开始实施：
+/implement-task {task-id}
+```
+
+## ✅ 完成检查清单
+
+执行此命令后，确认：
+
+- [ ] 已创建方案文档 `{task_dir}/plan.md`
+- [ ] 已更新 task.md 中的 `current_step` 为 technical-design
+- [ ] 已更新 task.md 中的 `updated_at` 为当前时间
+- [ ] 已更新 task.md 中的 `assigned_to` 为你的名字
+- [ ] 已在"工作流进度"中标记 requirement-analysis 为完成 ✅
+- [ ] 已在"工作流进度"中标记 technical-design 为进行中
+- [ ] 已在 task.md 中标记 plan.md 为已完成
+- [ ] 已告知用户这是人工检查点，需要审查后再继续
+
+## 参数说明
+
+- `<task-id>`: 任务ID，格式为 TASK-{yyyyMMdd-HHmmss}（必需）
+
+## 使用示例
+
+```bash
+# 为任务设计技术方案
+/plan-task TASK-20251227-104654
+```
+
+## 注意事项
+
+1. **前置条件**：
+   - 必须先完成需求分析（analysis.md 存在）
+   - 如果没有，提示用户先执行 `/analyze-issue`
+
+2. **人工检查点**：
+   - 这是一个**必须**的人工检查点
+   - 方案设计完成后等待人工审查
+   - 审查通过后才能进入实施阶段
+
+3. **方案质量**：
+   - 充分思考，不要急于实施
+   - 考虑多个方案并对比
+   - 详细列出实施步骤
+
+4. **文档完整性**：
+   - 确保所有必需章节都包含
+   - 实施步骤要详细可执行
+   - 测试策略要具体明确
+
+## 相关命令
+
+- `/analyze-issue <number>` - 分析 Issue（前置步骤）
+- `/implement-task <task-id>` - 实施任务（后续步骤）
+- `/task-status <task-id>` - 查看任务状态
+
+## 错误处理
+
+- 任务不存在：提示 "任务 {task-id} 不存在，请检查任务ID"
+- 缺少需求分析：提示 "需求分析文档不存在，请先执行 /analyze-issue"
+- plan.md 已存在：询问是否覆盖或创建新版本
diff --git a/.codex/commands/refine-title.md b/.codex/commands/refine-title.md
new file mode 100644
index 000000000..eac842641
--- /dev/null
+++ b/.codex/commands/refine-title.md
@@ -0,0 +1,97 @@
+---
+description: 深度分析 Issue 或 PR 内容，并将其标题重构为 Conventional Commits 格式
+usage: /refine-title <id>
+argument-hint: <id>
+---
+
+# Refine Title Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+针对指定的 GitHub Issue 或 PR，读取其详细描述（Body）、标签（Labels）以及代码变更（如果是 PR），深度理解其意图，然后生成符合 `type(scope): subject` 规范的新标题并执行修改。
+
+## 执行流程
+
+### 1. 识别对象与获取信息
+
+尝试判断 ID 是 Issue 还是 PR，并获取详细信息。
+
+```bash
+# 尝试获取 Issue 信息
+gh issue view <id> --json number,title,body,labels,state
+
+# 如果提示是 PR，或者查不到 Issue 但存在同号 PR，则获取 PR 信息
+gh pr view <id> --json number,title,body,labels,state,files
+```
+
+### 2. 智能分析
+
+根据获取到的 JSON 数据进行分析：
+
+1.  **确定 Type (类型)**：
+    - 阅读 `body` 中的 "变更类型" 或描述。
+    - 检查 `labels` (如 `type: bug` -> `fix`, `type: feature` -> `feat`)。
+    - 如果是 PR，分析 `files` (仅文档变动 -> `docs`，仅测试变动 -> `test`)。
+
+2.  **确定 Scope (范围)**：
+    - 阅读 `body` 提及的模块。
+    - 检查 `labels` (如 `in: fit` -> `fit`)。
+    - 如果是 PR，分析 `files` 路径 (如 `framework/fit/java/...` -> `fit`)。
+
+3.  **生成 Subject (摘要)**：
+    - **忽略原标题**（避免受干扰），直接从 `body` 中提炼核心意图。
+    - 确保简练（20字以内）、中文描述、无句号。
+
+### 3. 生成建议与交互
+
+输出分析结果供用户确认：
+
+```text
+🔍 分析对象: Issue #<id> / PR #<id>
+
+当前标题: [原标题]
+--------------------------------------------------
+🧠 分析依据:
+- 原始意图: (从 Body 提取的一句话摘要)
+- 推断类型: Fix (依据: 标签 type:bug, Body 关键词 "修复")
+- 推断范围: fit (依据: 涉及文件路径 framework/fit/...)
+--------------------------------------------------
+✨ 建议标题: fix(fit): 修复并发场景下的空指针异常
+```
+
+询问用户：*"是否确认修改？(y/n)"*
+
+### 4. 执行修改
+
+用户确认（y）后，根据对象类型执行命令：
+
+```bash
+# 如果是 Issue
+gh issue edit <id> --title "<new-title>"
+
+# 如果是 PR
+gh pr edit <id> --title "<new-title>"
+```
+
+## 参数说明
+
+- `<id>`: Issue 或 PR 的编号（必需）。
+
+## 使用示例
+
+```bash
+# 智能重命名 Issue #1024
+/refine-title 1024
+```
+
+## 优势
+
+相比于批量修改 (`/normalize-titles`)，本命令：
+1. **修正错误**：如果原标题是 "Help me"，此命令能读懂内容并改为 "fix(core): 修复启动报错"。
+2. **更精准的 Scope**：通过分析 PR 的文件变动，能自动判断是 `fit` 还是 `waterflow`，无需人工指定。
diff --git a/.codex/commands/refinement-task.md b/.codex/commands/refinement-task.md
new file mode 100644
index 000000000..3a1603f35
--- /dev/null
+++ b/.codex/commands/refinement-task.md
@@ -0,0 +1,253 @@
+---
+description: 处理代码审查反馈并修复问题
+usage: /refinement-task <task-id>
+argument-hint: <task-id>
+---
+
+# Refinement Task Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+处理代码审查中发现的问题，修复代码后重新进入审查流程。此命令用于 code-review 步骤发现需要修改的情况。
+
+## ⚠️ CRITICAL: 状态更新要求
+
+执行此命令后，你**必须**立即更新任务状态。参见规则 7。
+
+## 执行流程
+
+### 1. 验证前置条件
+
+检查必需文件：
+- `.ai-workspace/active/{task-id}/task.md` - 任务文件
+- `{task_dir}/review.md` - 审查报告（或 review-supplement.md）
+- `{task_dir}/implementation.md` - 实现报告
+
+如果任一文件不存在，提示用户先完成前置步骤。
+
+### 2. 读取审查报告
+
+仔细阅读审查报告（`review.md` 或 `review-supplement.md` 或 `review-final.md`），提取需要修复的问题：
+
+**问题分类**：
+1. **🔴 必须修复（Blocker）** - 阻塞问题，必须修复才能合并
+2. **🟡 建议修改（Major）** - 重要建议，强烈推荐修复
+3. **🟢 优化建议（Minor）** - 可选优化，可以考虑修复
+
+**提取信息**：
+- 问题标题
+- 文件路径和行号
+- 问题描述
+- 修复建议
+
+### 3. 使用 TodoWrite 规划修复任务
+
+根据审查报告创建修复任务清单：
+
+```
+使用 TodoWrite 工具创建 todos：
+- [ ] 修复问题 1: {问题标题}
+- [ ] 修复问题 2: {问题标题}
+- [ ] 修复问题 3: {问题标题}
+...
+```
+
+**优先级**：
+1. 先修复所有 🔴 必须修复的问题
+2. 再修复 🟡 建议修改的问题
+3. 最后考虑 🟢 优化建议
+
+### 4. 执行代码修复
+
+按优先级逐个修复问题：
+
+**修复流程**：
+1. 读取相关文件，理解问题上下文
+2. 按照审查建议修复代码
+3. 确保修复不引入新问题
+4. 在 TodoWrite 中标记该问题为已完成
+
+**修复原则**：
+- 严格按照审查建议修复
+- 如果建议不明确，询问用户
+- 如果发现新问题，一并修复
+- 保持代码风格一致
+
+### 5. 运行测试（如果有测试失败）
+
+如果审查报告中提到测试问题：
+
+```bash
+# 运行单元测试
+mvn test
+
+# 运行特定测试
+mvn test -Dtest=TestClassName
+
+# 运行集成测试
+mvn verify
+```
+
+确保所有测试通过后再继续。
+
+### 6. 更新任务状态 (CRITICAL)
+
+**必须更新** `.ai-workspace/active/{task-id}/task.md`：
+
+```yaml
+current_step: refinement
+assigned_to: {当前AI，例如 codex}
+updated_at: {当前时间，格式: yyyy-MM-dd HH:mm:ss}
+```
+
+**在工作流进度中标记**：
+```markdown
+## 工作流进度
+
+- [x] requirement-analysis (已完成)
+- [x] technical-design (已完成)
+- [x] implementation (已完成)
+- [x] code-review (已完成 - 发现问题)
+- [x] refinement (正在修复)  ← 标记为进行中
+- [ ] finalize (待执行)
+```
+
+### 7. 创建修复报告
+
+创建 `{task_dir}/refinement-report.md`，记录修复情况：
+
+```markdown
+# 代码修复报告
+
+## 修复概要
+
+- **修复者**: {修复者}
+- **修复时间**: {时间}
+- **修复范围**: {修复的问题数量}
+- **修复来源**: 代码审查反馈
+
+## 修复内容
+
+### 🔴 已修复的阻塞问题
+
+#### 1. {问题标题}
+**原问题**: {问题描述}
+**修复方式**: {详细说明修复了什么}
+**修改文件**: `{file-path}:{line-number}`
+
+### 🟡 已修复的建议问题
+
+#### 1. {问题标题}
+**原问题**: {问题描述}
+**修复方式**: {详细说明修复了什么}
+**修改文件**: `{file-path}:{line-number}`
+
+### 🟢 已采纳的优化建议
+
+#### 1. {优化标题}
+**原建议**: {建议描述}
+**实施方式**: {详细说明如何实施}
+**修改文件**: `{file-path}:{line-number}`
+
+## 未修复的问题（如果有）
+
+### {问题标题}
+**原因**: {为什么没有修复}
+**计划**: {如何处理}
+
+## 测试结果
+
+- [ ] 单元测试通过
+- [ ] 集成测试通过
+- [ ] 回归测试通过
+- [ ] 新增测试（如果需要）
+
+## 下一步
+
+代码已修复，准备重新进入审查流程。
+```
+
+### 8. 准备重新审查
+
+修复完成后，告知用户：
+
+**输出格式**：
+```
+✅ 任务 {task-id} 代码修复完成
+
+**修复内容**：
+- 必须修复: {数量} 项 ✅
+- 建议修改: {数量} 项 ✅
+- 优化建议: {数量} 项 ✅
+
+**输出文件**：
+- 修复报告: {task_dir}/refinement-report.md
+
+**下一步**：
+请执行以下操作之一：
+1. 使用 /review-task {task-id} 重新审查代码
+2. 如果你对修复有信心且修改较小，可以直接 /commit 提交
+3. 如果修复涉及大量更改，建议重新审查
+```
+
+## ✅ 完成检查清单
+
+执行此命令后，确认：
+
+- [ ] 已读取审查报告并提取所有问题
+- [ ] 已使用 TodoWrite 创建修复任务清单
+- [ ] 已按优先级修复所有问题
+- [ ] 所有测试通过（如果有测试）
+- [ ] 已更新 task.md 中的 `current_step` 为 refinement
+- [ ] 已更新 task.md 中的 `updated_at` 为当前时间
+- [ ] 已更新 task.md 中的 `assigned_to` 为你的名字
+- [ ] 已在"工作流进度"中标记 refinement 为进行中
+- [ ] 已创建 refinement-report.md 记录修复情况
+- [ ] 已告知用户下一步操作（重新审查或提交）
+
+## 常见问题
+
+### Q: 如果审查报告太长，有很多问题怎么办？
+
+A: 优先修复 🔴 阻塞问题。如果问题太多，建议：
+1. 先修复所有阻塞问题
+2. 提交一次修复，重新审查
+3. 根据新的审查结果继续修复
+
+### Q: 如果不同意审查意见怎么办？
+
+A: 与用户沟通：
+1. 说明你的理由
+2. 提供替代方案
+3. 由用户决定是否修复
+
+### Q: 修复后需要更新实现报告吗？
+
+A: 不需要。创建 refinement-report.md 即可。实现报告保留原样，记录初始实现情况。
+
+### Q: 可以跳过某些建议修改吗？
+
+A: 可以，但必须在 refinement-report.md 中说明原因。阻塞问题必须全部修复。
+
+## 相关命令
+
+- `/review-task` - 重新审查修复后的代码
+- `/implement-task` - 如果需要重大修改，回到实现步骤
+- `/commit` - 如果修复较小且有信心，可以直接提交
+
+## 工作流位置
+
+此命令对应 `.ai-agents/workflows/feature-development.yaml` 中的 **refinement** 步骤。
+
+## 示例
+
+```bash
+# 处理 TASK-20260103-135501 的审查反馈
+/refinement-task TASK-20260103-135501
+```
diff --git a/.codex/commands/review-task.md b/.codex/commands/review-task.md
new file mode 100644
index 000000000..d14ba8bab
--- /dev/null
+++ b/.codex/commands/review-task.md
@@ -0,0 +1,329 @@
+---
+description: 审查任务实现并输出代码审查报告
+usage: /review-task <task-id> [--pr-number]
+argument-hint: <task-id> [--pr-number=<number>]
+---
+
+# Review Task Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+审查任务的代码实现，检查代码质量、规范合规性、测试覆盖等，输出审查报告。
+
+## ⚠️ CRITICAL: 状态更新要求
+
+执行此命令后，你**必须**立即更新任务状态。参见规则 7。
+
+## 执行流程
+
+### 1. 验证前置条件
+
+检查必需文件：
+- `.ai-workspace/active/{task-id}/task.md` - 任务文件
+- `{task_dir}/implementation.md` - 实现报告
+
+如果任一文件不存在，提示用户先完成前置步骤。
+
+### 2. 读取实现报告
+
+仔细阅读 `implementation.md`，了解：
+- 已修改的文件列表
+- 实现的关键功能
+- 测试情况
+- 实现者标注的需要关注的点
+
+### 3. 执行代码审查
+
+按照 `.ai-agents/workflows/feature-development.yaml` 中的 `code-review` 步骤：
+
+**必须审查的内容**：
+- [ ] 代码质量和编码规范（遵循 CLAUDE.md）
+- [ ] Bug 和潜在问题检测
+- [ ] 测试覆盖率和测试质量
+- [ ] 错误处理和边界情况
+- [ ] 性能和安全问题
+- [ ] 代码注释和文档
+- [ ] 与技术方案的一致性
+
+**审查原则**：
+1. **严格但公正**：指出问题，但也认可优点
+2. **具体明确**：给出具体的文件和行号
+3. **提供建议**：不仅指出问题，还要提供改进建议
+4. **分级处理**：区分必须修复和建议优化
+
+### 4. 调用专业审查工具（可选，仅适用于 Claude Code）
+
+⚠️ **注意**：以下工具仅在 **Claude Code 环境**中可用。如果你在使用 **Codex CLI**，请**跳过此步骤**，依赖步骤 3 中的手动审查清单进行完整审查。
+
+**如果使用 Claude Code**，可以调用以下插件进行更深度的审查：
+
+**方案1：快速审查**（推荐用于日常 PR）
+```bash
+/code-review:code-review <pr-number>
+```
+（Claude Code 插件，Codex CLI 不支持）
+- 5个并行 Sonnet 代理
+- CLAUDE.md 规范合规性
+- Bug 检测与历史上下文分析
+
+**方案2：深度审查**（推荐用于重要功能）
+```bash
+/pr-review-toolkit:review-pr
+```
+（Claude Code 插件，Codex CLI 不支持）
+- 6个专业审查代理
+- 代码注释准确性、测试覆盖、错误处理、类型设计等多维度审查
+
+**Codex CLI 用户**：请使用步骤 3 中的手动审查清单，这已经涵盖了代码审查的所有重要方面。
+
+### 5. 输出审查报告
+
+创建 `{task_dir}/review.md`，必须包含以下章节：
+
+```markdown
+# 代码审查报告
+
+## 审查概要
+
+- **审查者**: {审查者}
+- **审查时间**: {时间}
+- **审查范围**: {文件数量和主要模块}
+- **总体评价**: {通过/需要修改/不通过}
+
+## 审查发现
+
+### 🔴 必须修复（Blocker）
+
+#### 1. {问题标题}
+**文件**: `{file-path}:{line-number}`
+**问题描述**: {详细描述}
+**修复建议**: {具体建议}
+**严重程度**: 高
+
+### 🟡 建议修改（Major）
+
+#### 1. {问题标题}
+**文件**: `{file-path}:{line-number}`
+**问题描述**: {详细描述}
+**修复建议**: {具体建议}
+**严重程度**: 中
+
+### 🟢 优化建议（Minor）
+
+#### 1. {优化点}
+**文件**: `{file-path}:{line-number}`
+**建议**: {优化建议}
+
+## 优点与亮点
+
+- {做得好的地方1}
+- {做得好的地方2}
+
+## 规范检查
+
+### CLAUDE.md 合规性
+- [ ] 编码规范
+- [ ] 命名规范
+- [ ] 注释规范
+- [ ] 测试规范
+
+### 代码质量指标
+- 圈复杂度: {评估}
+- 代码重复: {评估}
+- 测试覆盖率: {百分比}
+
+## 测试审查
+
+### 测试覆盖
+- 单元测试: {评价}
+- 边界情况: {是否覆盖}
+- 异常情况: {是否覆盖}
+
+### 测试质量
+- 测试命名: {评价}
+- 断言充分性: {评价}
+- 测试独立性: {评价}
+
+## 安全审查
+
+- SQL 注入风险: {检查结果}
+- XSS 风险: {检查结果}
+- 权限控制: {检查结果}
+- 敏感信息泄露: {检查结果}
+
+## 性能审查
+
+- 算法复杂度: {评估}
+- 数据库查询: {优化建议}
+- 资源释放: {检查结果}
+
+## 与方案的一致性
+
+- [ ] 实现符合技术方案
+- [ ] 未偏离设计意图
+- [ ] 无计划外功能
+
+## 总结与建议
+
+### 是否批准
+- [ ] ✅ 批准合并（无阻塞问题）
+- [ ] ⚠️ 修改后批准（有建议修改项）
+- [ ] ❌ 需要重大修改（有阻塞问题）
+
+### 下一步行动
+{根据审查结果给出下一步建议}
+```
+
+### 6. 更新任务状态
+
+更新 `.ai-workspace/active/{task-id}/task.md`：
+- `current_step`: code-review
+- `assigned_to`: {审查者}
+- `updated_at`: {当前时间}
+- 标记 review.md 为已完成
+- 在工作流进度中标记代码审查为完成
+
+### 7. 告知用户
+
+输出格式：
+```
+✅ 任务 {task-id} 代码审查完成
+
+**审查结果**：
+- 必须修复: {数量} 项
+- 建议修改: {数量} 项
+- 优化建议: {数量} 项
+- 总体评价: {评价}
+
+**输出文件**：
+- 审查报告: {task_dir}/review.md
+
+**下一步**：
+{根据审查结果给出建议}
+
+例如：
+- 如果无阻塞问题：使用 /commit 提交代码
+- 如果有需要修改项：修复问题后重新审查
+- 如果需要重大修改：回到 /implement-task 重新实施
+```
+
+## ✅ 完成检查清单
+
+执行此命令后，确认：
+
+- [ ] 已完成代码审查
+- [ ] 已创建审查报告 `{task_dir}/review.md`
+- [ ] 已更新 task.md 中的 `current_step` 为 code-review
+- [ ] 已更新 task.md 中的 `updated_at` 为当前时间
+- [ ] 已更新 task.md 中的 `assigned_to` 为你的名字（审查者）
+- [ ] 已在"工作流进度"中标记 implementation 为完成 ✅
+- [ ] 已在"工作流进度"中标记 code-review 为进行中
+- [ ] 已在 task.md 中标记 review.md 为已完成
+- [ ] 已告知用户下一步操作（根据审查结果）
+- [ ] 如果审查通过，告知用户可以使用 /commit 提交
+- [ ] 如果需要修复，告知用户使用 /refinement-task 修复问题
+
+## 参数说明
+
+- `<task-id>`: 任务ID，格式为 TASK-{yyyyMMdd-HHmmss}（必需）
+- `--pr-number`: 可选，如果已创建 PR，提供 PR 编号可以调用插件进行更深度审查
+
+## 使用示例
+
+### 示例1：基础代码审查
+
+```bash
+# 在完成代码实施后，对任务进行审查
+/review-task TASK-20251227-104654
+```
+
+**预期输出**：
+```
+✅ 任务 TASK-20251227-104654 代码审查完成
+
+**审查结果**：
+- 必须修复: 2 项
+- 建议修改: 3 项
+- 优化建议: 5 项
+- 总体评价: 需要修改
+
+**输出文件**：
+- 审查报告: .ai-workspace/active/TASK-20251227-104654/review.md
+
+**下一步**：
+发现 2 个必须修复的问题，请修复后重新审查
+```
+
+### 示例2：结合 PR 进行深度审查
+
+```bash
+# 如果已创建 PR，可以调用专业审查工具
+/review-task TASK-20251227-104654 --pr-number 123
+```
+
+这会在基础审查后，额外调用 `/pr-review-toolkit:review-pr` 进行多维度深度审查。
+
+### 示例3：完整工作流
+
+```bash
+# 1. 分析 Issue
+/analyze-issue 207
+
+# 2. 设计技术方案
+/plan-task TASK-20251227-104654
+
+# 3. 实施功能
+/implement-task TASK-20251227-104654
+
+# 4. 代码审查 ← 当前步骤
+/review-task TASK-20251227-104654
+
+# 5. 如果审查通过，提交代码
+/commit
+
+# 6. 创建 Pull Request
+/create-pr
+```
+
+## 注意事项
+
+1. **前置条件**：
+   - 必须先完成代码实现（implementation.md 存在）
+   - 建议运行测试确保功能正常
+
+2. **审查标准**：
+   - 严格遵循 CLAUDE.md 中的编码规范
+   - 重点关注安全性和性能问题
+   - 确保测试覆盖充分
+
+3. **审查深度**：
+   - 日常功能：基础审查即可
+   - 重要功能：建议使用 `--pr-number` 调用专业审查工具
+
+4. **客观公正**：
+   - 既要指出问题，也要认可优点
+   - 提供具体的改进建议
+   - 区分严重程度
+
+## 相关命令
+
+**Codex CLI 命令**：
+- `/prompts:implement-task <task-id>` - 实施任务（前置步骤）
+- `/prompts:commit` - 提交代码（后续步骤）
+- `/prompts:refinement-task <task-id>` - 修复审查发现的问题
+
+**Claude Code 环境下可选**：
+- `/code-review:code-review <pr-number>` - 深度 PR 审查（插件）
+- `/pr-review-toolkit:review-pr` - 专业多维度审查（插件）
+
+## 错误处理
+
+- 任务不存在：提示 "任务 {task-id} 不存在"
+- 缺少实现报告：提示 "实现报告不存在，请先执行 /implement-task"
+- PR 不存在：提示 "PR #{number} 不存在，请检查 PR 编号"
diff --git a/.codex/commands/sync-issue.md b/.codex/commands/sync-issue.md
new file mode 100644
index 000000000..1b0dd55f7
--- /dev/null
+++ b/.codex/commands/sync-issue.md
@@ -0,0 +1,282 @@
+---
+description: 将任务处理进度同步到 GitHub Issue 评论
+usage: /sync-issue <task-id>
+argument-hint: <task-id>
+---
+
+# Sync Issue Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+将任务的处理进度摘要同步到对应的 GitHub Issue 评论板中，确保 Issue 中的信息有逻辑、完整且易于追踪。
+
+## 执行流程
+
+### 1. 验证任务存在
+
+按以下优先级搜索任务：
+- 查找 `.ai-workspace/active/{task-id}/task.md`（优先）
+- 如果不存在，查找 `.ai-workspace/blocked/{task-id}/task.md`
+- 如果不存在，查找 `.ai-workspace/completed/{task-id}/task.md`
+- 如果都不存在，提示用户任务不存在
+
+找到后记录任务状态（status）和任务目录路径（task_dir）。
+
+### 2. 读取任务信息
+
+从任务文件中获取：
+- Issue 号码（`issue_number` 字段）
+- 任务标题和描述
+- 当前步骤（`current_step`）
+- 任务状态（`status`）
+- 创建和更新时间
+
+### 3. 读取上下文文件
+
+检查并读取以下文件（如果存在）：
+- `{task_dir}/analysis.md` - 需求分析
+- `{task_dir}/plan.md` - 技术方案
+- `{task_dir}/implementation.md` - 实现报告
+- `{task_dir}/review.md` - 审查报告
+
+### 4. 生成进度摘要
+
+根据当前状态生成清晰的进度摘要：
+
+**基本格式**：
+```markdown
+## 🤖 任务进度更新
+
+**任务ID**: {task-id}
+**更新时间**: {当前时间}
+**当前状态**: {状态描述}
+
+### ✅ 已完成
+
+- [x] 需求分析 - {完成时间}
+  - {核心要点摘要 1-2 条}
+- [x] 技术方案设计 - {完成时间}
+  - {方案选择和关键决策 1-2 条}
+- [ ] 代码实现（进行中）
+- [ ] 代码审查
+- [ ] 最终提交
+
+### 📋 当前进展
+
+{当前步骤的详细说明}
+
+### 🎯 下一步
+
+{下一步计划}
+
+### 📂 相关文件
+
+- 任务文件: `.ai-workspace/{status}/{task-id}/task.md`
+- 需求分析: `.ai-workspace/{status}/{task-id}/analysis.md`
+- 技术方案: `.ai-workspace/{status}/{task-id}/plan.md`
+
+---
+*由 Codex CLI 自动生成 - [任务管理系统](../.ai-agents/README.md)*
+```
+
+**摘要原则**：
+- **简洁**：每个阶段只提取核心要点，避免冗长
+- **逻辑清晰**：按时间顺序展示进展
+- **突出关键决策**：技术方案选择、重要发现等
+- **面向人类阅读**：避免技术细节，使用易懂的语言
+
+### 5. 同步到 Issue
+
+使用 `gh` 命令将摘要发布到 Issue：
+
+```bash
+gh issue comment {issue-number} --body "$(cat <<'EOF'
+{生成的进度摘要}
+EOF
+)"
+```
+
+### 6. 更新任务状态
+
+在任务文件中记录同步时间：
+- 添加或更新 `last_synced_at` 字段
+- 记录同步的 Issue 评论链接（如果 gh 返回）
+
+### 7. 告知用户
+
+输出格式：
+```
+✅ 任务进度已同步到 Issue #{issue-number}
+
+**同步内容**：
+- 已完成步骤: {数量}
+- 当前状态: {状态}
+- 下一步: {下一步说明}
+
+**查看链接**：
+https://github.com/{owner}/{repo}/issues/{issue-number}
+```
+
+## 参数说明
+
+- `<task-id>`: 任务ID，格式为 TASK-{yyyyMMdd-HHmmss}（必需）
+
+## 使用示例
+
+```bash
+# 同步任务进度到对应的 Issue
+/sync-issue TASK-20251227-104654
+
+# 也可以简写
+/sync-issue TASK-20251227-104654
+```
+
+## 进度摘要示例
+
+### 示例 1：需求分析完成
+
+```markdown
+## 🤖 任务进度更新
+
+**任务ID**: TASK-20251227-104654
+**更新时间**: 2025-12-29 15:30:00
+**当前状态**: 需求分析已完成，等待技术方案设计
+
+### ✅ 已完成
+
+- [x] 需求分析 - 2025-12-29 10:46:54
+  - 分析了 fastjson 到 fastjson2/Jackson 的迁移方案
+  - 评估了迁移范围：fit-value-fastjson 插件（ohscript 模块除外）
+
+### 📋 当前进展
+
+需求分析已完成并输出到文档。待人工审查后进入技术方案设计阶段。
+
+### 🎯 下一步
+
+1. 人工审查需求分析（建议）
+2. 设计技术方案（使用 `/plan-task TASK-20251227-104654`）
+
+---
+*由 Codex CLI 自动生成 - [任务管理系统](../.ai-agents/README.md)*
+```
+
+### 示例 2：技术方案完成
+
+```markdown
+## 🤖 任务进度更新
+
+**任务ID**: TASK-20251227-104654
+**更新时间**: 2025-12-29 16:00:00
+**当前状态**: 技术方案设计完成，等待人工审查
+
+### ✅ 已完成
+
+- [x] 需求分析 - 2025-12-29 10:46:54
+- [x] 技术方案设计 - 2025-12-29 15:05:00
+  - **选择方案**: 升级到 fastjson2
+  - **理由**: API 兼容性好，迁移成本低，支持直接操作 Java 对象
+  - **工作量**: 预计 0.5-1 天（仅需修改包名和版本号）
+
+### 📋 当前进展
+
+技术方案已设计完成。方案详细说明了实施步骤、测试策略和风险控制。
+
+### 🎯 下一步
+
+⚠️ **人工审查检查点（必需）**
+
+请审查技术方案是否合理，审查通过后使用：
+```
+/implement-task TASK-20251227-104654
+```
+
+---
+*由 Codex CLI 自动生成 - [任务管理系统](../.ai-agents/README.md)*
+```
+
+### 示例 3：实现完成
+
+```markdown
+## 🤖 任务进度更新
+
+**任务ID**: TASK-20251227-104654
+**更新时间**: 2025-12-29 18:30:00
+**当前状态**: 代码实现完成，等待代码审查
+
+### ✅ 已完成
+
+- [x] 需求分析 - 2025-12-29 10:46:54
+- [x] 技术方案设计 - 2025-12-29 15:05:00
+- [x] 代码实现 - 2025-12-29 18:20:00
+  - 修改文件: 3 个
+  - 新增测试: 5 个
+  - 测试通过率: 100%
+
+### 📋 当前进展
+
+已完成代码实现并通过所有测试。实现报告包含详细的修改说明和测试结果。
+
+### 🎯 下一步
+
+使用以下命令进行代码审查：
+```
+/prompts:review-task <task-id>
+```
+
+或手动审查后提交：
+```
+/prompts:commit
+```
+
+---
+*由 Codex CLI 自动生成 - [任务管理系统](../.ai-agents/README.md)*
+```
+
+## 注意事项
+
+1. **Issue 号必须存在**：
+   - 任务文件中必须有 `issue_number` 字段
+   - 如果没有，提示用户手动指定或更新任务文件
+
+2. **摘要生成原则**：
+   - 面向项目管理者和其他开发者阅读
+   - 突出关键决策和进展
+   - 避免过多技术细节
+   - 保持逻辑清晰
+
+3. **同步时机**：
+   - 完成重要阶段后（分析、设计、实现、审查）
+   - 遇到阻塞问题时
+   - 长时间任务的定期更新
+
+4. **评论格式**：
+   - 使用 Markdown 格式
+   - 使用 emoji 增强可读性
+   - 包含时间戳
+   - 添加 Codex CLI 签名
+
+5. **避免频繁同步**：
+   - 不要在每个小步骤都同步
+   - 建议在完成一个完整阶段后同步
+   - 避免产生过多评论
+
+## 相关命令
+
+- `/analyze-issue <number>` - 分析 Issue 并创建任务
+- `/plan-task <task-id>` - 设计技术方案
+- `/implement-task <task-id>` - 实施任务
+- `/task-status <task-id>` - 查看任务状态
+
+## 错误处理
+
+- 任务不存在：提示 "任务 {task-id} 不存在，请检查任务ID"
+- 缺少 Issue 号：提示 "任务文件中缺少 issue_number 字段"
+- gh 命令失败：提示 "同步失败，请检查 GitHub CLI 是否已登录"
+- 网络错误：提示 "网络连接失败，请稍后重试"
diff --git a/.codex/commands/sync-pr.md b/.codex/commands/sync-pr.md
new file mode 100644
index 000000000..002d72e69
--- /dev/null
+++ b/.codex/commands/sync-pr.md
@@ -0,0 +1,322 @@
+---
+description: 将任务处理进度同步到 Pull Request 评论
+usage: /sync-pr <task-id>
+argument-hint: <task-id>
+---
+
+# Sync PR Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+将任务的处理进度摘要同步到对应的 Pull Request 评论区中，方便审查者了解开发进展和关键决策。
+
+## 执行流程
+
+### 1. 验证任务存在
+
+检查任务文件是否存在：
+- 查找 `.ai-workspace/active/{task-id}/task.md`
+- 如果不存在，检查 `completed/` 和 `blocked/` 目录
+- 如果都不存在，提示用户任务不存在
+
+### 2. 读取任务信息
+
+从任务文件中获取：
+- PR 号码（`pr_number` 字段）
+- 任务标题和描述
+- 当前步骤（`current_step`）
+- 任务状态（`status`）
+- 创建和更新时间
+- 关联的 Issue（`issue_number`，如果有）
+
+### 3. 读取上下文文件
+
+检查并读取以下文件（如果存在）：
+- `{task_dir}/analysis.md` - 需求分析
+- `{task_dir}/plan.md` - 技术方案
+- `{task_dir}/implementation.md` - 实现报告
+- `{task_dir}/review.md` - 审查报告
+
+### 4. 生成进度摘要
+
+根据当前状态生成清晰的进度摘要：
+
+**基本格式**：
+```markdown
+## 🤖 开发进度更新
+
+**任务ID**: {task-id}
+**更新时间**: {当前时间}
+**当前状态**: {状态描述}
+
+### ✅ 已完成
+
+- [x] 需求分析 - {完成时间}
+  - {核心要点摘要 1-2 条}
+- [x] 技术方案设计 - {完成时间}
+  - {方案选择和关键决策 1-2 条}
+- [x] 代码实现 - {完成时间}
+  - 修改文件: {数量}
+  - 新增测试: {数量}
+- [ ] 代码审查（进行中）
+- [ ] 最终合并
+
+### 📋 当前进展
+
+{当前步骤的详细说明}
+
+### 🎯 下一步
+
+{下一步计划}
+
+### 📊 技术要点
+
+{关键的技术决策和实现细节，方便审查者理解}
+
+### 📂 相关文档
+
+- 任务文件: `.ai-workspace/active/{task-id}/task.md`
+- 需求分析: `{task_dir}/analysis.md`
+- 技术方案: `{task_dir}/plan.md`
+- 实现报告: `{task_dir}/implementation.md`
+
+---
+*由 Codex CLI 自动生成 - [任务管理系统](../.ai-agents/README.md)*
+```
+
+**摘要原则**：
+- **面向审查者**：突出技术决策和实现要点
+- **简洁清晰**：每个阶段只提取核心要点
+- **逻辑连贯**：按开发流程展示进展
+- **便于审查**：说明关键变更的原因和影响
+
+### 5. 同步到 PR
+
+使用 `gh` 命令将摘要发布到 PR 评论：
+
+```bash
+gh pr comment {pr-number} --body "$(cat <<'EOF'
+{生成的进度摘要}
+EOF
+)"
+```
+
+### 6. 更新任务状态
+
+在任务文件中记录同步时间：
+- 添加或更新 `last_synced_to_pr_at` 字段
+- 记录同步的 PR 评论链接（如果 gh 返回）
+
+### 7. 告知用户
+
+输出格式：
+```
+✅ 任务进度已同步到 PR #{pr-number}
+
+**同步内容**：
+- 已完成步骤: {数量}
+- 当前状态: {状态}
+- 下一步: {下一步说明}
+
+**查看链接**：
+https://github.com/{owner}/{repo}/pull/{pr-number}
+```
+
+## 参数说明
+
+- `<task-id>`: 任务ID，格式为 TASK-{yyyyMMdd-HHmmss}（必需）
+
+## 使用示例
+
+```bash
+# 同步任务进度到对应的 PR
+/sync-pr TASK-20251227-104654
+```
+
+## 进度摘要示例
+
+### 示例 1：代码实现完成，等待审查
+
+```markdown
+## 🤖 开发进度更新
+
+**任务ID**: TASK-20251227-104654
+**更新时间**: 2025-12-29 18:30:00
+**当前状态**: 代码实现完成，请审查
+
+### ✅ 已完成
+
+- [x] 需求分析 - 2025-12-29 10:46:54
+  - 评估了 fastjson 到 fastjson2 的迁移方案
+  - 确定迁移范围：fit-value-fastjson 插件
+
+- [x] 技术方案设计 - 2025-12-29 15:05:00
+  - 选择升级到 fastjson2（API 兼容性好）
+  - 预估工作量：0.5-1 天
+
+- [x] 代码实现 - 2025-12-29 18:20:00
+  - 修改文件: 3 个（pom.xml + 2个源文件）
+  - 新增测试: 5 个单元测试
+  - 测试通过率: 100%
+
+### 📋 当前进展
+
+代码实现已完成并通过所有测试。主要变更：
+- 升级 `fastjson` 依赖到 `fastjson2` 2.0.43
+- 更新包名导入路径
+- 验证 API 兼容性
+
+### 🎯 下一步
+
+请审查以下内容：
+- 依赖版本选择是否合理
+- 包名更新是否完整
+- 测试覆盖是否充分
+
+### 📊 技术要点
+
+**依赖升级**:
+```xml
+- <dependency>com.alibaba:fastjson:1.2.83</dependency>
++ <dependency>com.alibaba.fastjson2:fastjson2:2.0.43</dependency>
+```
+
+**API 兼容性**: fastjson2 保持了与 fastjson 的 API 兼容，仅需修改包名：
+- `com.alibaba.fastjson.*` → `com.alibaba.fastjson2.*`
+
+**测试策略**: 增加了边界情况测试，确保序列化/反序列化行为一致
+
+### 📂 相关文档
+
+- 任务文件: `.ai-workspace/active/TASK-20251227-104654/task.md`
+- 需求分析: `.ai-workspace/active/TASK-20251227-104654/analysis.md`
+- 技术方案: `.ai-workspace/active/TASK-20251227-104654/plan.md`
+- 实现报告: `.ai-workspace/active/TASK-20251227-104654/implementation.md`
+
+---
+*由 Codex CLI 自动生成 - [任务管理系统](../.ai-agents/README.md)*
+```
+
+### 示例 2：审查完成，准备合并
+
+```markdown
+## 🤖 开发进度更新
+
+**任务ID**: TASK-20251227-104654
+**更新时间**: 2025-12-30 10:15:00
+**当前状态**: 审查通过，准备合并
+
+### ✅ 已完成
+
+- [x] 需求分析 - 2025-12-29 10:46:54
+- [x] 技术方案设计 - 2025-12-29 15:05:00
+- [x] 代码实现 - 2025-12-29 18:20:00
+- [x] 代码审查 - 2025-12-30 10:00:00
+  - 审查通过，无阻塞性问题
+  - 修复了 2 处代码风格问题
+
+### 📋 当前进展
+
+代码审查已完成，所有反馈已处理：
+- ✅ 代码质量检查通过
+- ✅ 测试覆盖率达标
+- ✅ 无安全隐患
+- ✅ 文档已更新
+
+### 🎯 下一步
+
+准备合并到主分支。合并后将：
+- 关闭相关 Issue #207
+- 更新版本说明
+
+### 📊 审查总结
+
+**代码变更**: 3 个文件，+156 -89 行
+**测试覆盖**: 新增 5 个测试，覆盖率 95%
+**破坏性变更**: 无
+**向后兼容**: 是
+
+---
+*由 Codex CLI 自动生成 - [任务管理系统](../.ai-agents/README.md)*
+```
+
+## 注意事项
+
+1. **PR 号必须存在**：
+   - 任务文件中必须有 `pr_number` 字段
+   - 如果没有，提示用户手动指定或更新任务文件
+
+2. **摘要生成原则**：
+   - 面向代码审查者
+   - 突出技术决策和实现要点
+   - 说明关键变更的原因
+   - 避免过度技术细节
+
+3. **同步时机**：
+   - 代码实现完成，准备审查时
+   - 处理完审查反馈后
+   - 重大进展或决策变更时
+   - PR 长时间等待审查时的进度提醒
+
+4. **评论格式**：
+   - 使用 Markdown 格式
+   - 使用 emoji 增强可读性
+   - 包含时间戳
+   - 添加 Codex CLI 签名
+
+5. **避免频繁同步**：
+   - 不要在每个小改动都同步
+   - 建议在完成重要阶段后同步
+   - 避免产生过多评论
+
+6. **与 Issue 同步的关系**：
+   - `/sync-issue` 面向项目管理者和干系人
+   - `/sync-pr` 面向代码审查者和开发者
+   - 两者内容侧重点不同
+
+## 相关命令
+
+- `/create-pr` - 创建 Pull Request
+- `/sync-issue <task-id>` - 同步进度到 Issue
+- `/review-task` - 代码审查
+- `/commit` - 提交代码
+
+## 错误处理
+
+- 任务不存在：提示 "任务 {task-id} 不存在，请检查任务ID"
+- 缺少 PR 号：提示 "任务文件中缺少 pr_number 字段"
+- PR 不存在：提示 "Pull Request #{pr-number} 不存在"
+- PR 已关闭：提示 "Pull Request #{pr-number} 已关闭"
+- gh 命令失败：提示 "同步失败，请检查 GitHub CLI 是否已登录"
+- 网络错误：提示 "网络连接失败，请稍后重试"
+
+## 最佳实践
+
+1. **开发完成后立即同步**：
+   ```bash
+   # 推荐的工作流程
+   /implement-taskTASK-xxx    # 实现功能
+   /sync-pr TASK-xxx      # 同步进度，请求审查
+   ```
+
+2. **处理审查反馈后再次同步**：
+   ```bash
+   # 修复审查问题后
+   git commit -m "fix: address review comments"
+   /sync-pr TASK-xxx      # 告知审查者已处理
+   ```
+
+3. **长时间等待时提醒**：
+   - PR 等待审查超过 2 天，同步进度提醒
+   - 说明紧急程度和阻塞情况
+
+4. **团队协作**：
+   - 在进度摘要中 @mention 相关审查者
+   - 说明需要特别关注的部分
+   - 标注重要的技术决策
diff --git a/.codex/commands/task-status.md b/.codex/commands/task-status.md
new file mode 100644
index 000000000..c2133b68b
--- /dev/null
+++ b/.codex/commands/task-status.md
@@ -0,0 +1,193 @@
+---
+description: 查看任务的当前状态和进度
+usage: /task-status <task-id>
+argument-hint: <task-id>
+---
+
+# Task Status Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+查看指定任务的当前状态、进度和上下文文件。
+
+## 执行流程
+
+### 1. 读取任务文件
+
+读取 `.ai-workspace/active/{task-id}/task.md`（如果任务已完成，也检查 `completed/` 目录）
+
+### 2. 检查上下文文件
+
+检查以下文件是否存在：
+- `analysis.md` - 需求分析
+- `plan.md` - 技术方案
+- `implementation.md` - 实现报告
+- `review.md` - 审查报告
+
+### 3. 分析当前状态
+
+根据任务文件和上下文文件，确定：
+- 当前执行到哪个步骤
+- 哪些步骤已完成
+- 哪些步骤待执行
+- 当前负责的 AI
+- 是否等待人工审查
+
+### 4. 输出状态报告
+
+输出格式化的状态信息：
+
+```
+📋 任务状态报告
+
+**基本信息**：
+- 任务ID: {task-id}
+- 任务标题: {title}
+- 任务类型: {type}
+- 相关Issue: #{issue-number}
+- 创建时间: {created_at}
+- 更新时间: {updated_at}
+
+**当前状态**：
+- 工作流: {workflow}
+- 当前步骤: {current_step}
+- 执行者: {assigned_to}
+- 状态: {status}
+
+**工作流进度**：
+✅ 需求分析 (完成于 {date})
+✅ 技术方案设计 (完成于 {date})
+⏳ 代码实现 (进行中)
+⏸️  代码审查 (待开始)
+⏸️  问题修复 (待开始)
+
+**上下文文件**：
+✅ analysis.md (2.5 KB)
+✅ plan.md (8.3 KB)
+⏳ implementation.md (进行中)
+❌ review.md (未创建)
+
+**文件路径**：
+- 任务文件: .ai-workspace/active/{task-id}/task.md
+- 上下文目录: {task_dir}/
+
+**下一步建议**：
+{根据当前状态给出建议}
+```
+
+## 参数说明
+
+- `<task-id>`: 任务ID，格式为 TASK-{yyyyMMdd-HHmmss}（必需）
+
+## 使用示例
+
+```bash
+# 查看任务状态
+/task-status TASK-20251227-104654
+
+# 也可以简写
+/task-status TASK-20251227-104654
+```
+
+## 状态说明
+
+### 任务状态
+
+- `active` - 进行中
+- `blocked` - 被阻塞
+- `completed` - 已完成
+
+### 步骤状态
+
+- ✅ 已完成
+- ⏳ 进行中
+- ⏸️ 待开始
+- ❌ 失败/阻塞
+
+### 下一步建议
+
+根据当前状态自动生成建议：
+
+**如果在需求分析阶段**：
+```
+继续完成需求分析，完成后使用：
+/plan-task {task-id}
+```
+
+**如果需求分析完成，等待人工审查**：
+```
+⚠️  等待人工审查需求分析
+审查通过后使用：
+/plan-task {task-id}
+```
+
+**如果在技术方案设计阶段**：
+```
+继续完成技术方案设计，完成后等待人工审查
+```
+
+**如果方案设计完成，等待人工审查**：
+```
+⚠️  等待人工审查技术方案
+审查通过后使用：
+/implement-task {task-id}
+```
+
+**如果在代码实现阶段**：
+```
+继续完成代码实现，完成后使用：
+/review-task {task-id}
+```
+
+**如果实现完成，待审查**：
+```
+使用以下命令进行代码审查：
+/review-task {task-id}
+```
+
+**如果审查完成，待提交**：
+```
+使用以下命令提交代码：
+/commit
+```
+
+**如果任务被阻塞**：
+```
+⚠️  任务被阻塞
+阻塞原因: {原因}
+请解决阻塞问题后继续
+```
+
+## 注意事项
+
+1. **多目录查找**：
+   - 优先在 `active/` 目录查找
+   - 如果没找到，检查 `completed/` 目录
+   - 如果还没找到，检查 `blocked/` 目录
+
+2. **简洁输出**：
+   - 输出信息清晰、结构化
+   - 使用 emoji 增强可读性
+   - 突出关键信息
+
+3. **智能建议**：
+   - 根据当前状态给出下一步建议
+   - 提示人工检查点
+   - 提供具体的命令示例
+
+## 相关命令
+
+- `/analyze-issue <number>` - 分析 Issue
+- `/plan-task <task-id>` - 设计技术方案
+- `/implement-task <task-id>` - 实施任务
+
+## 错误处理
+
+- 任务不存在：提示 "任务 {task-id} 不存在，请检查任务ID"
+- 任务文件损坏：提示 "任务文件格式错误"
diff --git a/.codex/commands/test.md b/.codex/commands/test.md
new file mode 100644
index 000000000..f53d2754d
--- /dev/null
+++ b/.codex/commands/test.md
@@ -0,0 +1,51 @@
+---
+description: 执行完整的测试流程
+usage: /prompts:test
+---
+
+# Test Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+执行完整的测试流程，包括单元测试、构建验证和集成测试。
+
+**用法：**
+- `/test` - 执行完整测试流程
+
+**执行方式：**
+
+使用自动化测试脚本执行完整的测试流程：
+```bash timeout=900000
+./.ai-agents/scripts/run-test.sh
+```
+
+**测试流程包括：**
+
+1. **清理构建产物** - 删除之前的 build 目录
+2. **执行单元测试和构建** - 运行 `mvn clean install` 执行全量单元测试
+3. **创建动态插件目录** - 创建 `dynamic-plugins` 目录
+4. **启动 FIT 服务** - 使用 `build/bin/fit start` 启动服务
+5. **验证健康检查接口** - 访问 `/actuator/plugins` 接口
+6. **验证 Swagger 文档** - 访问 `/openapi.html` 页面
+7. **清理测试环境** - 停止服务并删除构建产物
+
+**测试报告：**
+
+脚本会自动生成测试报告，包含：
+1. ✅/✗ 单元测试结果
+2. ✅/✗ 构建状态
+3. ✅/✗ FIT 服务启动状态
+4. ✅/✗ 健康检查接口响应
+5. ✅/✗ Swagger 文档页面可访问性
+
+**注意事项：**
+
+1. **端口冲突**：确保 8080 端口未被占用
+2. **权限配置**：如需自动授权，请在本地 Codex 配置中放行相关命令
+3. **完全自动化**：整个测试流程无需手动确认，自动执行所有步骤
diff --git a/.codex/commands/upgrade-dependency.md b/.codex/commands/upgrade-dependency.md
new file mode 100644
index 000000000..4f050ddd0
--- /dev/null
+++ b/.codex/commands/upgrade-dependency.md
@@ -0,0 +1,239 @@
+---
+description: 升级项目依赖
+usage: /upgrade-dependency <package-name> <from-version> <to-version>
+argument-hint: <package-name> <from-version> <to-version>
+---
+
+# Upgrade Dependency Command
+
+## 使用前：自动识别仓库
+
+命令会默认使用当前工作目录所在的 Git 仓库作为目标，无需传入仓库参数。若当前目录不在 Git 仓库内，请先 `cd` 到目标仓库根目录后再执行。
+
+文中所有路径示例默认以仓库根目录为基准。
+
+## 功能说明
+
+升级项目中的指定依赖包到新版本，并验证变更。
+
+## 用法
+
+```bash
+/upgrade-dependency <package-name> <from-version> <to-version>
+```
+
+例如：
+```bash
+/upgrade-dependency swagger-ui 5.30.0 5.30.2
+```
+
+## 执行步骤
+
+### 1. 解析参数
+
+- **包名**：第一个参数
+- **原版本**：第二个参数
+- **新版本**：第三个参数
+
+### 2. 查找依赖文件
+
+使用 Grep 搜索包含该依赖的文件：
+
+```bash
+# 搜索包名
+grep -r "<package-name>" --include="pom.xml" --include="package.json" --include="build.gradle"
+
+# 搜索旧版本号
+grep -r "<from-version>" --include="pom.xml" --include="package.json" --include="build.gradle"
+```
+
+### 3. 更新依赖版本
+
+根据项目类型更新对应的依赖文件：
+
+**Maven 项目** (pom.xml):
+```xml
+<!-- 从 -->
+<dependency>
+    <groupId>...</groupId>
+    <artifactId>{package-name}</artifactId>
+    <version>{from-version}</version>
+</dependency>
+
+<!-- 更新为 -->
+<dependency>
+    <groupId>...</groupId>
+    <artifactId>{package-name}</artifactId>
+    <version>{to-version}</version>
+</dependency>
+```
+
+**Node.js 项目** (package.json):
+```json
+{
+  "dependencies": {
+    "{package-name}": "{to-version}"
+  }
+}
+```
+
+**Gradle 项目** (build.gradle):
+```groovy
+implementation '{group}:{package-name}:{to-version}'
+```
+
+### 4. 更新相关静态资源
+
+如果依赖包含静态资源（如 swagger-ui 的 HTML/CSS/JS 文件），同步更新：
+- 版本号引用
+- CDN 链接
+- 文档中的版本说明
+
+### 5. 验证变更
+
+#### 5.1 查看变更
+
+```bash
+git diff
+```
+
+确认变更正确，没有误改其他内容。
+
+#### 5.2 编译验证
+
+```bash
+# Maven 项目
+mvn clean package -Dmaven.test.skip=true
+
+# Node.js 项目
+npm install
+npm run build
+
+# Gradle 项目
+./gradlew clean build -x test
+```
+
+#### 5.3 运行测试（推荐）
+
+```bash
+# Maven 项目
+mvn test
+
+# Node.js 项目
+npm test
+
+# Gradle 项目
+./gradlew test
+```
+
+### 6. 输出变更摘要
+
+告知用户升级完成的情况：
+
+```
+✅ 依赖升级完成
+
+**依赖信息**:
+- 包名: {package-name}
+- 原版本: {from-version}
+- 新版本: {to-version}
+
+**变更文件**:
+- {file-path-1}
+- {file-path-2}
+
+**验证结果**:
+- 编译状态: {成功/失败}
+- 测试状态: {通过/失败/未运行}
+
+**下一步**:
+请人工检查变更内容，确认无误后提交：
+/commit
+```
+
+## 参数说明
+
+- `<package-name>`: 依赖包名称（必需）
+- `<from-version>`: 当前版本号（必需）
+- `<to-version>`: 目标版本号（必需）
+
+## 使用示例
+
+### 示例1：升级 Swagger UI
+
+```bash
+/upgrade-dependency swagger-ui 5.30.0 5.30.2
+```
+
+### 示例2：升级 Spring Boot
+
+```bash
+/upgrade-dependency spring-boot 2.7.0 2.7.18
+```
+
+### 示例3：升级 React
+
+```bash
+/upgrade-dependency react 18.2.0 18.3.1
+```
+
+## 注意事项
+
+1. **版本兼容性**：
+   - 升级前检查 CHANGELOG 和 Migration Guide
+   - 注意破坏性变更（Breaking Changes）
+   - 跨大版本升级需要特别谨慎
+
+2. **依赖关系**：
+   - 注意传递依赖的兼容性
+   - 某些依赖可能需要同步升级
+   - 检查依赖冲突
+
+3. **验证测试**：
+   - 升级后必须进行编译测试
+   - 建议运行完整的测试套件
+   - 检查是否有废弃 API 的警告
+
+4. **人工检查**：
+   - 升级完成后请人工检查变更内容
+   - 确认没有误改其他配置
+   - 检查无误后再提交代码
+
+5. **Git 操作**：
+   - **不要**自动执行 git commit
+   - 等待人工检查后再提交
+   - 提交信息应明确说明升级内容
+
+6. **安全升级**：
+   - 如果是安全漏洞修复，优先处理
+   - 在提交信息中注明相关的 CVE 或 GHSA ID
+
+## 相关命令
+
+- `/analyze-security <alert-number>` - 分析安全告警（如果是安全相关升级）
+- `/commit` - 提交代码
+- `/test` - 运行测试
+
+## 错误处理
+
+- 依赖文件未找到：提示 "未找到包含 {package-name} 的依赖文件"
+- 版本号未找到：提示 "未找到版本 {from-version}，请检查当前版本号"
+- 编译失败：提示 "升级后编译失败，请检查错误信息"
+- 测试失败：提示 "升级后测试失败，可能存在兼容性问题"
+
+## 最佳实践
+
+1. **小步升级**：
+   - 一次只升级一个依赖
+   - 避免同时升级多个相关依赖
+   - 每次升级都进行完整验证
+
+2. **记录变更**：
+   - 在提交信息中说明升级原因
+   - 关联相关的 Issue 或安全告警
+   - 记录重要的兼容性变更
+
+3. **回滚准备**：
+   - 确保有清晰的 git 历史
+   - 了解如何回滚到之前的版本
+   - 记录升级过程中的问题和解决方案
diff --git a/.codex/scripts/install-prompts.sh b/.codex/scripts/install-prompts.sh
new file mode 100755
index 000000000..383131f72
--- /dev/null
+++ b/.codex/scripts/install-prompts.sh
@@ -0,0 +1,73 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+SRC_DIR="$SCRIPT_DIR/../commands"
+DEST_DIR="$HOME/.codex/prompts"
+
+echo "📦 Codex Prompts 安装脚本"
+echo "源目录: $SRC_DIR"
+echo "目标目录: $DEST_DIR"
+echo ""
+
+# 创建目标目录
+mkdir -p "$DEST_DIR"
+
+# 检查源目录是否存在
+if [ ! -d "$SRC_DIR" ]; then
+  echo "❌ 错误: 源目录不存在: $SRC_DIR" >&2
+  exit 1
+fi
+
+# 检查是否有 .md 文件
+if ! ls "$SRC_DIR"/*.md >/dev/null 2>&1; then
+  echo "❌ 错误: 在源目录中未找到 .md 文件" >&2
+  exit 1
+fi
+
+# 统计文件数量
+FILE_COUNT=$(ls -1 "$SRC_DIR"/*.md 2>/dev/null | wc -l | tr -d ' ')
+echo "📝 发现 $FILE_COUNT 个 prompt 文件"
+
+# 检查是否有文件会被覆盖
+OVERWRITE_COUNT=0
+for file in "$SRC_DIR"/*.md; do
+  filename=$(basename "$file")
+  if [ -f "$DEST_DIR/$filename" ]; then
+    OVERWRITE_COUNT=$((OVERWRITE_COUNT + 1))
+  fi
+done
+
+if [ $OVERWRITE_COUNT -gt 0 ]; then
+  echo "⚠️  将覆盖 $OVERWRITE_COUNT 个已存在的文件"
+fi
+
+# 复制文件（强制覆盖）
+echo ""
+echo "🚀 开始安装..."
+cp -fv "$SRC_DIR"/*.md "$DEST_DIR"/ 2>&1 | sed 's/^/  /'
+
+echo ""
+echo "✅ 安装完成！共安装 $FILE_COUNT 个命令"
+echo ""
+echo "📍 Prompts 已安装到: $DEST_DIR"
+echo "💡 使用方式: /prompts:<name>"
+echo ""
+echo "📋 已安装的命令列表:"
+echo ""
+
+# 读取每个命令的描述并显示
+for file in "$DEST_DIR"/*.md; do
+  filename=$(basename "$file" .md)
+  # 尝试从文件中提取 description（YAML frontmatter 中的 description 字段）
+  description=$(grep -m 1 '^description:' "$file" 2>/dev/null | sed 's/^description: *//; s/^"//; s/"$//' || true)
+
+  if [ -n "$description" ]; then
+    printf "  /prompts:%-20s - %s\n" "$filename" "$description"
+  else
+    printf "  /prompts:%s\n" "$filename"
+  fi
+done | sort
+
+# 确保脚本成功退出
+exit 0