feat:make codex better

AGENTS.md

@@ -4,6 +4,112 @@
 
 ## Coding 宪法
 
+# 语言
+
+- 和我对话的语言默认中文
+
+# 注意
+
+默认情况下，不要创建任何新的说明文档或文档文件。
+不要自动生成 README.md、设计文档、使用说明、架构说明等。
+只有在我明确要求"编写文档 / 生成 README / 写说明文档"时，才允许创建或修改文档。
+
+---
+
+# Workflow Orchestration
+
+## 1. 渐进式 Spec：按需复杂度
+
+不同复杂度的需求，走不同深度的流程——偶然复杂度应该尽可能压缩：
+
+| 需求规模                    | 流程                            |
+| --------------------------- | ------------------------------- |
+| 简单（改字段、修 bug）      | 直接执行，无需 Spec             |
+| 中等（3+ 步骤，有架构决策） | 写轻量 Spec，HARD-GATE 后再编码 |
+| 复杂（跨模块、多系统）      | 完整 Propose → Apply → Review |
+
+**Spec 三铁律**（仅中等及以上复杂度触发）：
+
+1. **No Spec, No Code** — 没有 Spec，不准写代码
+2. **Spec is Truth** — Spec 和代码冲突时，错的一定是代码
+3. **Reverse Sync** — 执行中发现偏差，先修 Spec，再修代码
+
+**HARD-GATE**：Spec 完整生成后，必须等用户显式确认才能开始编码。确认前禁止任何代码修改动作。
+
+**Research 必须有出处**：描述代码现状时，每个结论必须标注文件路径 + 函数名，不接受"通常来说"或无依据的推断。
+
+**Spec 分段确认**：不一口气生成完整 Spec。按段输出（现状分析 → 功能点 → 风险与决策），每段等用户确认后再继续。越早发现方向偏差，修正成本越低。
+
+## 2. Plan Node Default
+
+- 对任何中等及以上复杂度的任务，进入 plan mode
+- 出问题立刻停下重新规划，不要强行推进
+- Plan mode 同样适用于验证步骤，不只是构建阶段
+
+## 3. Subagent Strategy
+
+- 大量使用 subagent 保持主 context 窗口干净
+- Research、探索、并行分析交给 subagent
+- 复杂问题通过 subagent 投入更多计算
+- 每个 subagent 只做一件事，专注执行
+
+## 4. 执行自由度曲线
+
+| 阶段     | 自由度 | 原则                           |
+| -------- | ------ | ------------------------------ |
+| 调研     | 中     | 自由探索，但结论必须有代码出处 |
+| 方案设计 | 高     | 充分想象，提选项 + 给推荐      |
+| 规划     | 低     | 精确到文件路径和函数签名       |
+| 执行     | 零     | 严格按计划，有偏差立即停下问   |
+| 验收     | 中     | 自由检查，结论要有依据         |
+
+## 5. Self-Improvement Loop
+
+- 用户每次纠正后：将模式写入 `.codex/lessons.md`
+- 写规则防止同类错误重现
+- 每次会话开始时 review lessons 里的相关规则
+- 有价值的踩坑和领域发现，主动建议沉淀到项目知识库
+
+## 6. Verification 铁律
+
+- 任务未经验证，不得标记为完成
+- 必须展示可验证的证据（编译输出 / 测试结果 / 运行日志）
+- 禁止"应该没问题"等无证据声明
+- 必要时对比修改前后的行为差异
+
+## 7. Demand Elegance（适度）
+
+- 非简单修改时，停下来问一句："有没有更优雅的方式？"
+- 如果方案感觉 hacky："知道了这些之后，实现优雅方案"
+- 简单显而易见的修复直接做，不要过度设计
+
+## 8. Autonomous Bug Fixing
+
+- 给 bug 报告就去修，不要等手把手指导
+- 指向日志、报错、失败测试，然后解决它
+- 不需要用户切换上下文
+- CI 测试失败，主动去修
+
+---
+
+# Task Management
+
+1. **先写计划**：将计划写入 `.codex/todo.md`，使用可勾选的任务项
+2. **确认后执行**：中等及以上复杂度任务，HARD-GATE 后才开始实现
+3. **追踪进度**：完成一项立刻标记
+4. **解释变更**：每步给出高层次说明
+5. **记录结果**：在 `.codex/todo.md` 末尾添加 review 小节
+6. **沉淀教训**：用户纠正后更新 `.codex/lessons.md`
+
+---
+
+# Core Principles
+
+- **Simplicity First**：每次改动尽量简单。最小化影响范围。
+- **No Laziness**：找根因，不打补丁，用 senior developer 标准。
+- **Minimal Impact**：只改必要的代码，避免引入新问题。
+- **意图分离**：一次只处理一种意图——探索、决策、执行、审查不要混着来。
+
 ### 最优路径优先
 
 - 先基于当前目标、约束和上下文判断最优路径，再沿着这条路径推进。

AGENTS.md.template

@@ -1,9 +1,115 @@
 # AGENTS.md
 
-把这个文件放在项目根目录，用来把已安装的 Codex skills 注册给 Codex。项目级约束可以追加在文末的 `Project notes` 一节。
+把这个文件放在项目根目录，用来把已安装的 Codex skills 注册给 Codex。项目级约束可以追加在文末的 `Repo notes` 一节。
 
 ## Coding 宪法
 
+# 语言
+
+- 和我对话的语言默认中文
+
+# 注意
+
+默认情况下，不要创建任何新的说明文档或文档文件。
+不要自动生成 README.md、设计文档、使用说明、架构说明等。
+只有在我明确要求"编写文档 / 生成 README / 写说明文档"时，才允许创建或修改文档。
+
+---
+
+# Workflow Orchestration
+
+## 1. 渐进式 Spec：按需复杂度
+
+不同复杂度的需求，走不同深度的流程——偶然复杂度应该尽可能压缩：
+
+| 需求规模                    | 流程                            |
+| --------------------------- | ------------------------------- |
+| 简单（改字段、修 bug）      | 直接执行，无需 Spec             |
+| 中等（3+ 步骤，有架构决策） | 写轻量 Spec，HARD-GATE 后再编码 |
+| 复杂（跨模块、多系统）      | 完整 Propose → Apply → Review |
+
+**Spec 三铁律**（仅中等及以上复杂度触发）：
+
+1. **No Spec, No Code** — 没有 Spec，不准写代码
+2. **Spec is Truth** — Spec 和代码冲突时，错的一定是代码
+3. **Reverse Sync** — 执行中发现偏差，先修 Spec，再修代码
+
+**HARD-GATE**：Spec 完整生成后，必须等用户显式确认才能开始编码。确认前禁止任何代码修改动作。
+
+**Research 必须有出处**：描述代码现状时，每个结论必须标注文件路径 + 函数名，不接受"通常来说"或无依据的推断。
+
+**Spec 分段确认**：不一口气生成完整 Spec。按段输出（现状分析 → 功能点 → 风险与决策），每段等用户确认后再继续。越早发现方向偏差，修正成本越低。
+
+## 2. Plan Node Default
+
+- 对任何中等及以上复杂度的任务，进入 plan mode
+- 出问题立刻停下重新规划，不要强行推进
+- Plan mode 同样适用于验证步骤，不只是构建阶段
+
+## 3. Subagent Strategy
+
+- 大量使用 subagent 保持主 context 窗口干净
+- Research、探索、并行分析交给 subagent
+- 复杂问题通过 subagent 投入更多计算
+- 每个 subagent 只做一件事，专注执行
+
+## 4. 执行自由度曲线
+
+| 阶段     | 自由度 | 原则                           |
+| -------- | ------ | ------------------------------ |
+| 调研     | 中     | 自由探索，但结论必须有代码出处 |
+| 方案设计 | 高     | 充分想象，提选项 + 给推荐      |
+| 规划     | 低     | 精确到文件路径和函数签名       |
+| 执行     | 零     | 严格按计划，有偏差立即停下问   |
+| 验收     | 中     | 自由检查，结论要有依据         |
+
+## 5. Self-Improvement Loop
+
+- 用户每次纠正后：将模式写入 `.codex/lessons.md`
+- 写规则防止同类错误重现
+- 每次会话开始时 review lessons 里的相关规则
+- 有价值的踩坑和领域发现，主动建议沉淀到项目知识库
+
+## 6. Verification 铁律
+
+- 任务未经验证，不得标记为完成
+- 必须展示可验证的证据（编译输出 / 测试结果 / 运行日志）
+- 禁止"应该没问题"等无证据声明
+- 必要时对比修改前后的行为差异
+
+## 7. Demand Elegance（适度）
+
+- 非简单修改时，停下来问一句："有没有更优雅的方式？"
+- 如果方案感觉 hacky："知道了这些之后，实现优雅方案"
+- 简单显而易见的修复直接做，不要过度设计
+
+## 8. Autonomous Bug Fixing
+
+- 给 bug 报告就去修，不要等手把手指导
+- 指向日志、报错、失败测试，然后解决它
+- 不需要用户切换上下文
+- CI 测试失败，主动去修
+
+---
+
+# Task Management
+
+1. **先写计划**：将计划写入 `.codex/todo.md`，使用可勾选的任务项
+2. **确认后执行**：中等及以上复杂度任务，HARD-GATE 后才开始实现
+3. **追踪进度**：完成一项立刻标记
+4. **解释变更**：每步给出高层次说明
+5. **记录结果**：在 `.codex/todo.md` 末尾添加 review 小节
+6. **沉淀教训**：用户纠正后更新 `.codex/lessons.md`
+
+---
+
+# Core Principles
+
+- **Simplicity First**：每次改动尽量简单。最小化影响范围。
+- **No Laziness**：找根因，不打补丁，用 senior developer 标准。
+- **Minimal Impact**：只改必要的代码，避免引入新问题。
+- **意图分离**：一次只处理一种意图——探索、决策、执行、审查不要混着来。
+
 ### 最优路径优先
 
 - 先基于当前目标、约束和上下文判断最优路径，再沿着这条路径推进。
@@ -45,12 +151,14 @@
 
 ### How to use skills
 
-- Discovery: 以上列表就是当前项目注册给 Codex 的 skills。
+- Discovery: 以上列表就是当前仓库提供给 Codex 的 skills。
 - Trigger rules: 如果用户显式提到 skill 名称（例如 `/rr`、`$rr`、`rr skill`、`用 rr 评审`），或任务明显匹配 skill 描述，优先使用对应 skill。
 - Codex usage: 在 Codex 中优先使用 `/skill-name`；兼容历史 `$skill-name` 写法，也支持自然语言触发。
 - Missing/blocked: 如果某个 skill 文件不存在或无法读取，简短说明并回退到普通实现方式。
 - Context hygiene: 只按需打开 `SKILL.md`，不要一次性加载整个 skill 仓库。
 
-## Project notes
+### Repo notes
 
-- 在这里补充项目特定约束，例如技术栈、测试命令、代码风格、提交流程。
+- `./.claude/skills/` 保留给 Claude Code。
+- `./.codex/skills/` 是 Codex 的实际安装源。
+- 迁移或新增 skill 时，优先同步更新 `README.md`、`AGENTS.md`、`AGENTS.md.template`。