开发纪律 是做什么的？
“完成”由你未曾调整的外部信号来定论。 一条书面规则仅命名了一个失败类别；门控中的检查则阻止它。当某一类别复发时，在同一提交中添加检查。
$DD = 此文件旁边的 scripts/ 目录（退出码 0 表示通过，1 表示失败，2 表示未证明）。
按层面严格对待。 对判断性的部分（测试、验证器、阈值、CI）、金钱和数值公式、迁移、认证、静默失败应用完整循环。一个约10行的本地修复，附带规范字面量：prove_fix.py，2–3个手工编写的缺陷类别变异，针对一个你工作时未使用的输入运行一次。文本、UI 外观、文档、原型：运行测试和一次冒烟测试。没有测试或运行器：在自己的提交中添加一个最小测试（设置，而非削弱）。
循环
- 编辑前测量： 一个你将在前后比较的命令。从原始数据导出范围，而非摘要或记忆。列出整个类别：每一个共享根因的实例。→
references/debugging.md - 修复缺陷所经路径上的根因。 顶部加防护不是修复。回归性缺陷：
git bisect run。三次尝试失败后，改变方法或上下文。新实体、金钱/数据流或迁移：先写出5–10行设计笔记（debugging.md§10）。 - 证明测试： 在父提交上通过断言显示为红色（ImportError、收集错误、跳过 = 未证明），修复后为绿色，撤销代码更改后再次为红色：
$DD/prove_fix.py。新检查在错误输入上触发，在正确输入上保持静默。对于金钱和数值，预期值为规范字面量（# 预言机：<来源>）。 - 门控： 测试在同一提交的 CI 中运行；跳过、超时和“0个测试”不算通过；排除列表只能缩小；对 glob 或注册表的循环断言找到了多少项。→
gate-integrity.md - 接受 基于精确代码树上最终运行的运行器摘要行，而不是基于管道的
$?。 - 关闭 使用编写者未调整过的检查：其他数据、只读生产冒烟测试、独立预言机，并先写入预期。它发现的类别进入门控。→
proof-and-oracles.md
预言机及其保护
- 预言机与其检查的代码不共享任何代码。黄金文件和自一致性证明的是一致性，而非正确性。
- 验证脚本是待测试的代码：在好输入和坏输入上均运行；打印它检查了多少项。
- 测试、快照、预期值和 CI 只能通过契约更改：简要说明，或者，在单独工作时，一个命名该更改的用户请求（新规范、ticket、值）以及在编辑前写入的一行（哪些测试更改，新值来自哪里）。“让它通过”不是契约：与规范冲突的测试保持原样，答案是
SPEC_CONFLICT。值更改放在单独的test:提交中。跳过、删除的断言、缩小的覆盖范围需要说明理由。 永远不要调整代码以达到预期数值。评判最终差异，而非编辑工具：$DD/guard_diff.py（首先作为建议）。检查阻止了合法工作则是缺陷：报告BLOCKED，永远不要绕过。→oracle-protection.md
自治
默认自主推进。仅在涉及不可逆操作（安全、支付、生产数据写入、权限）或与目标冲突时询问。遇到岔路时，选择一条，记录原因、两种读数的数值以及如何撤销，然后继续。被阻塞：完成所有独立部分，然后以一行命名所需操作和命令结束。
报告
- 每条标准后跟
PASS | FAIL | NOT_PROVEN，附带命令、退出码和输出行；外加not_checked。 - 判定：
DONE，BLOCKED(原因)，SPEC_CONFLICT(测试, 来源)，IMPOSSIBLE，NOT_REPRODUCED。诚实的未完成退出是成功；静默跳过是缺陷。命名部分状态（“防护已添加，根因仍存在”）。 - 每个数值附上最终运行的命令。重新运行子代理报告的数值（
$DD/reexec_claims.py）。 - 提交主体 = 证据记录：修改前/后测量、门控行、未完成的内容及其去向。
红旗
| 我发现 | 我执行 |
|---|---|
| 没有父提交上的红色就直接变绿 | prove_fix.py |
| 引用子代理的数值或我的记忆 | 重新运行 |
| 没有契约就编辑测试或阈值 | 契约行或 SPEC_CONFLICT |
使用 skip、retry、sleep、noqa 来变绿 | 找出原因，使其确定性（refactor-flaky.md） |
| 即将询问可逆操作 | 决定、记录、继续 |
更多：delegation.md（子代理、审查者、简要说明）、release.md（部署）、process-ledger.md、evidence.md。