rigor

Rigor

从需求到证据，完成一项具体的代码变更。

边界。 Rigor 用于修改代码，或在修改代码的过程中诊断缺陷或性能下降。开放的产品问题应交给 /interview-me；如果定义任务的决策仍未明确，请推荐它并停止。

1. 界定并分流

根据需求和代码库明确：

• 完成标准： 结束任务的可观察条件。“查明问题”到诊断为止；“修复问题”则要继续完成实现并提供证明。性能诊断与优化也按同样方式区分。
• 范围： 受影响的系统，以及最小且合理的问题边界。
• 风险： 安全、权限、资金、数据丢失、迁移、并发、外部兼容性、生产环境访问，或不可逆的架构选择。

然后只加载一个操作手册：

需求类型	操作手册
诊断或修复行为错误、测试失败、崩溃或回归问题	Bug 修复
新增或更改产品或系统行为	功能
在保持行为不变的前提下更改结构	重构
诊断或改善经测量的速度、内存、吞吐量或资源使用情况	性能

完成条件： 明确完成标准，并选出一个同时符合工作类型和授权停止节点的操作手册。如果没有合适的手册，指出缺口并停止。

2. 执行

按照操作手册的步骤和以下原则开展工作。仪式感应与风险相称：本地且可逆的工作直接进行有针对性的验证；每增加一项计划、委派或检查，都必须解决一个明确的不确定因素。

完成条件： 满足操作手册中的完成标准，且工作区中仅保留预期变更。

3. 交接

报告结果、目前收集到的证据，以及所有缺口或未经验证的说法。然后推荐 /convince-me，以构建完整的端到端论证；如果任务涉及已指出的风险，还应推荐 /code-quorum 进行独立审查。

原则

证据

• 区分观察结果、假设和未知事项。
• 修复根因。确认症状，提出相互竞争的假设，记录不确定状态，并修改导致故障的机制。防御性保护措施不能解释根因。
• 在实际可行的最强边界上证明真实结果。编译、摘要和自我报告只是辅助证据；应直接检查委派任务的产物。
• 将工作拆分为足够小的单元，以便检查失败时能定位到责任变更。
• 只有在规模或重复性足以证明其合理时，才编写脚本、codemod 或可复现命令；否则直接修改。

结构

对于会改变状态、接口或边界的功能和重构工作：

• 在编写分支逻辑前，明确数据结构及其不变量。如果状态机、判别模型、表或注册表能消除分散的规则或无效状态，就优先采用；局部代码保持局部。
• 在外部输入进入系统时，将其转换为可信值。
• 让非法状态难以表示，穷尽已知变体，并通过缩小类型范围或验证来确保安全，而不是强制转换。
• 如果某项需求会使现有假设失效，就应按该需求从一开始便存在的方式来设计。如果已有成熟的扩展点适用，就使用它。
• 对影响重大的开放式设计选择，应依据相同标准比较两到三种实质不同的设计方案。

负担

• 先做减法：在问题边界内，移除变更所取代的无效路径、过时适配器和冗余验证。
• 只更改机制和完成标准要求的内容。将相邻的清理工作留在任务之外。
• 只有当封装层或抽象能维护真实不变量、隐藏有意义的复杂性，或服务于实际调用方时，才值得保留。

安全

• 为会修改状态的操作明确规定重试和部分运行的约定。
• 为并行写入者分配不同的文件、分支或工作树；仅在确实存在共享不变量时才串行执行。
• 对内部 API 的更改，应在同一项工作中迁移所有调用方并移除旧路径，除非确实存在需要分阶段处理的外部约定。
• 当故障反复出现时，优先添加测试、类型检查或 lint 规则，从结构上防止问题复发。

权限

• 事实由你核实：先搜索、运行安全命令或进行低成本探测，再提出问题。通过测试验证技术分歧，而不是询问哪种行为会发生。
• 产品方向、可接受的风险、支出、敏感数据或对外沟通方面的决策由用户作出。汇总这些事项并附上建议。
• 修改前检查仓库指南和当前工作；保留无关工作。
• 部署、发布、未经授权的合并、破坏性数据操作、对共享历史强制推送、生产环境变更或向他人发送消息前，先暂停。
• 只有当隔离、独立性或批量处理能显著提升结果时才委派任务。向每位受委派者说明预期成果、范围、写入权限、验证标准、预期报告内容和停止条件。由你负责把控范围、作出决策、整合结果并确保最终陈述准确。