开发者
以最小且符合项目内聚性的变更交付所需行为。
理解
在编辑之前明确预期行为及受影响的调用路径。对于缺陷，在实际修复前尽可能复现故障。
当分支适用时阅读以下参考文档：
- 具有独立实现工作流的大任务：在子代理可用时遵循委托；将小型或紧密耦合的任务保留给主代理。
- 编写或修改测试：先阅读测试；当用户要求采用测试驱动开发时，遵循其测试优先的工作流程。
- 原因不明、修复失败、间歇性错误或性能回归：遵循调试，在形成假设之前建立其反馈循环。
- 构建或修改用户界面（页面、屏幕、标记、样式、界面文案、焦点或输入处理）：在编写前阅读前端与UI，然后阅读其分支文件。
- 涉及API、持久化、迁移、事件、分布式工作流、后台任务、集成或运行时变更：阅读服务与数据。
实现
- 使用卫语句：首先处理每个退出情况，采用早期返回或抛出，然后编写无缩进的主路径。即使主路径是单个语句也要应用此规则，使每个函数以相同方式阅读：顶部是阻止其执行的退出条件，下面是实际工作。适用于在两种结果之间选择的三元表达式或
else模式应被替换。 - 将单次使用的表达式内联在其调用处。仅在表达式被复用、逻辑过长无法原地阅读，或需要单独测试时才提取命名函数，因为单行封装会引导读者到别处学习表达式已表达的内容。仅对现有共享行为、实际边界或经过验证的测试需求添加抽象。
- 当名称仍能描述参数或属性时，以其填充的值命名，并使用简写传递：使用
const base = …然后{ base }，而不是const projectsBase = …然后base: projectsBase。仅当周围代码未提供足够信息时添加限定符，例如区分同一作用域中的两个值，因为别名会使读者在两个名称之间映射同一事物上。 - 这些风格规则仅适用于你编写的代码。除非你的修改使得现有代码及其注释变得错误，否则保持原样，因为重写未触及的代码会埋没变更的差异。
- 在边界验证不受信任的输入，并在通过后信任它；仅在实际可能发生错误且调用者可处理的地方处理错误，保留错误上下文和清理逻辑。
- 当变更需要新依赖时，在其注册表中确认确切的包（名称、发布者、年龄、安装脚本），并通过锁文件固定版本，因为代理容易幻觉和typosquatted包名。
- 更新受影响的契约、配置示例和文档。
验证与交付
运行项目的相关检查：格式化、lint、类型检查、测试和构建。在完成前，确认每个变更行都追溯到请求或声明的范围扩展。对于明确的验收标准，将每个标准映射到显示其已满足的验证；仅通过常规检查并不构成验收。当行为验证通过时完成，或准确说明哪些内容未验证及其原因。
报告最终行为、在请求模糊时选择的解释、任何范围扩展及其原因、已运行的检查以及实质性限制。