# 项目协作准则

本文件适用于整个 `health_project` 仓库。处理任务时按改动风险分级，验证强度与风险匹配，避免小改动套用重型流程。

## 默认规则

- 默认不执行 `git add`、`git commit`、`git push`、合并、回滚或创建分支；只有用户明确要求时才进行。
- 保留工作区中用户已有的未提交改动，不覆盖、不清理、不顺带重构。
- 数据库、上传文件、密钥、生产配置和用户数据不视为普通文件；任何写入、迁移、删除或恢复操作必须先获得用户明确确认。
- 只修改用户指定的端和功能范围。发现相邻问题可以说明，但不要擅自扩大修改范围。

## 小改动：快速处理

适用于颜色、字号、间距、圆角、文案、图标、单个组件简单布局等不涉及状态、接口和数据的调整。

1. 确认具体文件和修改范围。
2. 直接完成修改。
3. 执行格式化。
4. 进行一次快速编译或静态检查，二者按实际需要选择。
5. 简要说明改动结果。

不运行完整测试套件，不额外编写计划文档，不提交 Git。

## 中等改动：针对性验证

适用于页面交互、Provider、路由、表单逻辑、接口调用、跨端数据展示、启动脚本和配置修改。

1. 检查相关代码和现有改动。
2. 修改前简要说明方案。
3. 完成代码修改和格式化。
4. 运行静态检查或编译。
5. 只运行与本次改动直接相关的测试。
6. 必要时启动对应页面或接口验证一次。

默认不提交 Git。

## 大改动：完整验证

适用于完整新功能、多页面联动、登录、聊天、蓝牙、AI 核心流程、后端结构调整和大范围重构。

1. 阅读相关代码、文档和交接资料。
2. 与用户确认范围、交互和成功标准。
3. 分步骤实施，并在关键阶段做针对性检查。
4. 完成后运行 Flutter 和后端相关完整测试。
5. 汇总改动、验证结果和遗留问题。

## 高风险改动：确认后执行

适用于数据库迁移或数据修复、大量删除、用户数据、上传文件、签名、生产配置、部署，以及 Git 提交、推送、合并和回滚。

1. 先进行只读检查，确认精确目标和影响。
2. 向用户说明风险、影响范围和恢复方式。
3. 必要时先制作可验证的备份。
4. 获得用户明确确认后再执行。
5. 执行后进行完整验证并报告结果。

用户在具体任务中的直接指令始终优先于本文件。