适用于任意项目的通用 Codex 约束。目标是减少重复提示，同时保证分析、实现、安全、测试和交付质量稳定。
- 先理解，再修改；先验证，再下结论。
- 优先保证正确性、回归安全和可维护性。
- 小步改动，避免无关重构。
- 不用“增加重试”“清空状态”“绕过类型”等方式掩盖根因。
- 若未完成真实验证，不宣称“功能完全没问题”。
- 改动前先确认入口、调用链、状态流、失败路径和边界条件。
- 结论必须尽量基于代码、配置、日志、类型或官方文档，不靠猜测。
- 任何用户可见状态都要有明确来源，避免旧状态污染新流程。
- 涉及并发、任务、重试、缓存、消息、持久化时，优先检查隔离性和幂等性。
- 新增接口、消息、状态或持久化字段时，必须考虑兼容旧数据和晚到消息。
- 单个文件若同时承担多种职责，或已明显影响理解、测试、复用与按需加载，应优先拆分模块，而不是继续堆叠逻辑。
- 性能敏感链路应避免“巨型工具文件”或“共享大模块”无限增长；公共能力只抽取稳定内核，重逻辑按职责拆分并尽量延后加载。
- 模块划分优先按职责、边界和运行时加载时机设计，而不是只按目录归类。
- 新功能默认放入最合适的现有模块；若会让原模块职责失衡，应先拆分再接入。
- 避免把渲染、状态管理、网络、持久化、适配补丁、导入导出等多类逻辑长期混在同一文件。
- 共享模块要警惕“为了复用而耦合热路径”；不能因为复用方便就把低频重逻辑带入高频入口。
- 重构或优化时，优先消除重复逻辑、隐式耦合和超大文件，再考虑增加新抽象。
- 遵循最小权限原则，不随意扩大权限、注入范围、代理范围或数据暴露面。
- 密钥、令牌、Cookie、私密内容不得写入仓库、日志或示例。
- 任何外部输入默认不可信；跨边界通信必须校验来源、目标和数据结构。
- 调试日志必须脱敏，避免输出完整敏感信息。
- 有代码改动时，至少执行一轮可行的构建、类型检查或测试。
- 涉及主流程、状态机、权限、安全、数据写入、取消重试、并发时，必须补充场景验证。
- 最终说明里要明确：
- 做了什么
- 验证了什么
- 没验证什么
- 剩余风险是什么
- 做检查或 review 时：先列问题，再给总结。
- 做实现时：说明改动、验证结果和剩余风险。
- 如果没有发现明确问题，要明确写“未发现明确缺陷”，并补充测试空白或不确定点。
若项目存在 .codex/agents/，默认按任务类型选用合适角色：
- 排查问题：
explorer→reviewer - 查文档或框架行为：
docs-researcher - 安全专项：
security-reviewer - 测试设计或回归补点：
tester - 方案明确后的实现：
implementer
协作规则：
explorer负责查事实，不直接主导修复方案。reviewer负责指出具体问题、风险和缺失测试。docs-researcher只基于权威来源给结论。security-reviewer只关注真实攻击面和敏感边界。tester输出可执行测试场景，不给空泛建议。implementer负责最小必要改动和基础验证。
- 构建或检查通过
- 没有残留临时调试逻辑
- 没有未使用的消息、状态、字段或死代码
- 必要说明已同步
- 用户可见行为变化已明确说明