Pull Request Guidelines（PR 规范）
一、创建 PR
PR 标题需在开头包含 issue 编号，例如：
RI-123 Add user profile editing #456 Fix memory leak in connection pool
PR 描述模板：
What
Describe what was changed.
Testing
Describe how to test the changes.
Refs #RI-123
PR 描述准则：
- 保持简洁，避免冗长描述。
- 聚焦高层级变更，不要在 #What 部分罗列每一处代码改动。
- 简短直接：细节由 diff 呈现，描述只讲“为什么”和“做了什么”的概览。
- 技术决策：仅在相关时提及重要的架构或设计决策。
- 使用链接而非自动关闭：使用
Refs #RI-123/Addresses #RI-123，不要用Closes/Fixes/Resolves——这些关键词会在 PR 合并时自动关闭 issue，而工单应手动关闭，而非由合并关闭。
二、审查流程
作为 PR 作者：
- 回应所有评论，处理每一条反馈。
- 不要将反馈视为针对个人，审查有助于提升代码质量。
- 根据反馈更新代码，做出所要求的修改。
- 处理完反馈后，将对话标记为已解决。
- 保持 PR 为最新状态，定期 rebase 到 main。
作为 PR 审查者：
- 建设性且尊重他人，着眼于改进。
- 关注逻辑而非风格，格式由 linter 处理。
- 检查以下方面：
- 逻辑错误与边界情况
- 性能问题
- 安全问题
- 测试覆盖
- 缺失的文档
- 架构方面的顾虑
三、审查清单
- [ ] 代码遵循项目模式
- [ ] 测试全面
- [ ] 无 console.log 或调试代码
- [ ] TypeScript 类型正确
- [ ] 错误处理充分
- [ ] 文档已更新
- [ ] 无安全漏洞
- [ ] 性能可接受