structure-first

结构优先

找到负责人。追踪流程。修改责任范围最小的单元。验证契约。

运行时契约

1. 选择负责该行为或规则的最小当前单元，而不只是症状或输出所在的单元。说明意图和最低可观察完成条件。对于 Bug，在重构前先确认可观察到的故障。
2. 只追踪从调用方经过决策或状态，再到写入或效果，直至完成所需的路径，并采用符合代码习惯的形式。只有在不修改类型、测试、文档和配置会破坏行为、契约或有意义的验证时，才将它们纳入范围。
3. 指出结构需求——流程、生命周期、决策／效果／完成的责任归属、组合、迁移或边界契约——以及阻碍追踪或测试的摩擦。
4. 优先在局部进行针对性澄清。只有在结构调整能降低整体复杂度，或隔离出可独立变更的职责时，才调整结构；顶层更短并不一定更好，尤其是当辅助函数、包装器、上下文、状态、错误处理或生命周期只是掩盖了复杂性时。
5. 每个决策、写入方、效果和完成规则都应有一条易于发现且无竞争的解决路径。在同一次变更中移除旧的等效路径；否则，明确迁移负责人和退出条件。
6. 在最稳定且负有相应责任的单元验证可观察行为，而不是验证辅助函数的内部细节。如果证据表明契约的某一部分由其他单元负责，只重新审视涉及的最小单元。

保留、内联、合并、删除、重排、提取以及不做结构调整，都是有效的结果。不要添加面向未来用途的选项、配置、依赖、包装器或抽象。

对于性能工作，在现有复现中测量输入规模、重复操作、物化过程和各阶段耗时。在其责任归属处移除占主导地位且可避免的工作，然后使用同一复现对比行为和结果。

必要细节

在更改公共 I/O、决策／写入方／效果／完成的责任归属、异步／状态生命周期、表示含义或迁移路径之前，请阅读 结构边界。

当重要主张跨越身份、权威数据、表示形式、外部写入或运行时／异步边界时，或者 Bug、重构或功能需要边界证据时，请阅读 验证。

只有在有助于完成任务时，才报告当前单元、结构需求、所选结果、责任归属或迁移状态，以及验证情况。不要在规划或简单的局部工作中强行套用模板。