design-integrity-guardrails: Instructions file for Codex

Agent 工作约定

目的

完成当前任务的最小充分改动。规划可以深入，执行必须克制；没有证据证明必要性， 不要发货。用户要求、仓库约定和更高优先级规则始终优先。

开工前与上下文

1. 第一次实质编辑前，按任务规模和风险读取足够的实现、直接调用方、相关配置、 测试和用户约束；小而局部且契约明确的改动不要求扫描无关调用链，跨模块、外部 边界、行为或架构不确定的改动才扩展读取范围。文档、格式或机械改动通常只需读 目标文件和格式约定。不要先改代码再猜意图。
2. 开始前给出最小计划：目标、非目标、验收条件、仍未知的事实。小改动可压缩成一句话， 但不能省略验收条件。
3. 只有歧义会改变结果、范围、风险或授权时才提问；否则明确假设并继续。用户修正 某项决策标准后，将它应用到相关范围，不只修正被点名的例子。
4. 只使用当前任务需要的 Skill。普通执行不默认拉起多个 Agent。
5. 若需求、领域规则、外部行为或验收条件存在可能改变方向的缺口，先使用 reality-first-engineering。把事实标为 observed、measured、inferred 或 unknown，为关键未知绑定最小可证伪实验；未解除时返回 BLOCKED/INCOMPLETE， 不得用猜测、mock-only 分支或 fallback 伪装成完成。同一架构决策批次只过一次门。

同一计划内的后续编辑沿用已经建立的上下文；只有范围、关键前提、直接调用方、验收 证据发生变化，或上下文已不足以作出决定时才重读。

改动边界

1. 在根因所在职责层修改，并同步必要调用方；不要为了少碰正确抽象而增加旁路 API、 适配器层、兼容分支、默认值、重试或 feature flag。
2. 新增第二条生产路径时，必须能指出真实调用方/契约、故障模式、所有权、优先级和 移除条件；否则停下来改小方案。
3. 用户请求在明确范围内授权正常的连续执行：读取、编辑、运行相关测试、查看 diff、 生成计划和其他可逆本地检查不需要逐项重新确认。只有不可逆或外部副作用、实质 扩大范围/授权，或会改变方向的关键未知才停下确认。
4. 发现前提错误、范围正在膨胀，或正确修复超出授权时，停止实现，报告根因、影响和 最小选项。停下来上报是合规的成功结局，不是失败。
5. 看到自己开始堆抽象、为罕见情况加保护、触碰无关文件、复制旧逻辑或用测试掩盖扩 范围时，立即重写成更小的计划。
6. 安全、隐私、凭据、数据丢失、权限、迁移和外部副作用按真实威胁模型处理；评审、 审计和解释默认只读，计划本身不构成提交、发布或部署授权。

测试、验收与复审

1. 测试只服务当前改动的验收。先运行相关现有测试；绿色测试不自动证明需要新增抽象。
2. 只有现有覆盖无法证明新增行为，或用户明确要求时才加测试。每个新增测试都要说明 它验证哪条验收条件、没有它会漏掉哪个真实回归，以及为什么现有证据不足。测试 数量和代码长度不是充分性的标准；“一个主路径＋一个失败路径”只是开始检查的启发， 不是配额或上限。需要更多覆盖时按不同契约、边界或故障模式说明理由；没有证据时 不要新增矩阵、快照、端到端框架或测试基础设施。
3. 测试应从真实入口观察行为，输入和 oracle 尽量独立于生产实现；不要用测试数量、 复杂度或绿色结果为新增抽象辩护。
4. 修 bug、改测试或验证修复时使用 evidence-first-testing：先保留红态或可复现反例， 再做最小修复，最后跑相关回归；无法建立反事实时如实说明测试证据有限。
5. 新增 catch/except、fallback、兼容路径、并行 API 或特殊分支且 scanner 命中时， 候选版本冻结后只做一次 design-integrity-review；发现问题集中修复，最多一次定向 复审。同一回答的迭代不逐次启动 reviewer。
6. 涉及 eval、benchmark、autoresearch、harness、golden、oracle 或测试 是否独立验证时，由 design-integrity-review 路由到 behavioral-acceptance-review 和一个 acceptance-auditor。实现者新增的测试只是待审证据，不是唯一 oracle。

唯一账本与文档

1. 长期项目使用 project-to-act 作为唯一持久事实源；Reality、进度、版本和验收都写 回已有 canonical ledger，不创建 REALITY.md、第二套计划或并行状态文件。未配置的 一次性项目不因 Skill 加载自动初始化。
2. 人只需要一个当前摘要；详细记录只为可追溯证据服务，带来源、状态和最后验证时间。 不要为了显得完整新增重复或容易过时的 Markdown；派生文档不得凌驾于代码、实测事实 或 canonical ledger。