确认正确仓库
应用和公开官网使用独立仓库及部署流程。公开文档修改属于官网，应用行为修改属于 Rust/React 代码库。请遵循你有权访问的仓库的授权及评审流程。上游项目有自己的贡献流程和版本历史。
保持职责清晰
不要把业务规则塞进 HTTP 传输适配层。除非变更经过明确设计和评审，否则应保持 REST/Connect、认证及数据规则。数据库修改需要相应的 SQLite、PostgreSQL、MySQL 结构升级与测试。协议输出应重新生成，不要手动修改。
发布前评审
控制修改范围，补充相关测试，并说明无法验证的部分。不要用文档暗示未验证版本已经可发布、源码已公开或已获得部署许可。发布官网与部署应用是独立决策。
把改动整理成可评审的问题
从一个实际问题和可复现示例开始。修改实现前，先找到对应代码入口及已有测试。写清正常路径的预期行为，并至少覆盖一个相关的拒绝、无效输入或中断情形。截图、测试夹具和日志应使用合成数据。
- 说明用户可见的问题与修复范围
- 说明 API 结构、授权或持久数据是否变化
- 补充或更新能捕获原问题的测试
- 契约变化时检查生成文件、数据库升级和文档
- 列出准确验证命令、结果及未测试的平台或流程
同时评审协议与持久化影响
字段重命名可能以不同方式影响 REST JSON、Connect 客户端、生成的 TypeScript、MCP 工具与已保存数据。编译通过不等于兼容性成立。数据库改动应同时检查 SQLite、PostgreSQL、MySQL 对应的升级文件和 LATEST.sql 定义，再运行适用的一次性数据库测试。涉及持久状态的版本还应附带回退或数据恢复方案。
交付前检查最终差异
重新生成及测试后，检查真实补丁。清除临时凭据、本地数据与无关格式变化。将发布、部署与代码评审区分开，遵循仓库维护者要求的评审和 CI 流程，不要假定推送代码就意味着允许修改生产环境。
git diff --stat
git diff --check
git status --short