firmware-app-development/references/workflow.md

开发流程

修改文件、生成产物或执行命令前，按下面顺序处理。同一会话已确认的任务范围、实现方案和忽略规则持续有效；没有变化时不重复确认。用户反馈的当前任务内实现错误，按已有约定修正；新增需求、范围变化或尚未授权的外部操作再确认。

只读检查需求和工程
→ 检查 Git 和 .gitignore
→ 确认不清楚的需求
→ 确认完整任务清单
→ 确认当前任务的实现方案
→ 开发当前任务
→ 编译或静态检查
→ 汇报代码和差异
→ 等待用户确认和测试
→ 处理下一个任务

1. 只读检查

• 阅读当前需求、规格说明、功能清单、工程说明、构建脚本和相关代码。
• 核对用户指定的参考工程提交及其子模块或独立仓库版本。区分已提交基线与参考目录中的本地修改，不能无差别复制工作区。目标工程的已确认需求优先。
• 检查拟改文件相对参考基线的差异，每项改动应能对应产品差异、接口约定或当前任务内的问题证据。先复用已有实现，不以通用化、健壮性或防止潜在问题为由改变原有业务行为。
• 找出本次需要修改的应用模块、用户明确指定的底层内容，以及可能存在但尚未要求修改的底层依赖。
• 默认不把 PSP 或其他底层文件作为固定检查项。判断应用影响或定位明确指定的底层修改时，可以主动读取和检查。
• 查看 Git 状态，不修改任何文件。

需求冲突时，默认顺序是：

1. 用户当前明确要求。
2. 已确认的产品需求或规格。
3. 当前工程现有约定。
4. 参考工程做法。
5. 推测。

高优先级要求覆盖其他来源时，要简洁说明差异，不能悄悄改掉。

2. 检查 Git 和 .gitignore

正式任务清单生成前：

1. 确认当前目录属于用户已创建的 Git 仓库。
2. 如果不是 Git 仓库，停止修改，请用户先准备仓库。不得执行 git init。
3. 查看 git status、.gitignore 和项目已有的输出目录说明。
4. 请用户确认现有忽略规则，或确认建议新增的规则。
5. 忽略规则未确认前，不运行会生成相关中间文件的命令。

工作区不要求完全干净。记录已有修改并避开它们。当前任务必须修改同一文件且无法安全区分时，暂停并询问用户。

3. 确认需求

只询问需要用户决定的问题。一次列出当前能确认的全部问题，每项包括：

• 不清楚或冲突的地方。
• 可选做法。
• 建议做法和简短理由。
• 受影响的功能或任务。

等待用户回答后再生成正式任务清单。

4. 确认任务清单

• 任务清单只列任务名称、修改范围和状态。
• 只包含当前需求明确要求的工作。
• 用户明确指定的底层修改作为开发任务。没有明确要求修改的底层依赖只在“底层未处理内容”中说明。
• 在对话中展示完整清单并等待用户确认。
• 默认不创建流程文档。用户明确要求时才写入项目。

5. 逐项开发

每次只处理一个已确认任务：

1. 给出简短实现方案并等待用户确认。
2. 再次检查 Git 状态和应用层边界。
3. 只修改已确认范围内的应用代码、应用配置或明确指定的底层内容。
4. 关键逻辑添加必要的中文注释。
5. 不新增、不修改、不执行单元测试。
6. 不使用 Mock、Stub、假数据、假成功、临时兜底或绕行流程补齐缺失功能。
7. 可以执行编译、语法检查和项目已有的静态检查。确认退出结果和实际输出，不能只看“成功”字样。
8. 当前任务明确要求打包或产物检查时，可以执行对应命令。生成 Bootloader、内核、驱动或底层镜像前必须另行确认。
9. 再次检查 Git 状态和差异，确认中间文件已被忽略。不得暂存或提交。
10. 用简洁中文汇报结果，等待用户确认和测试。

用户要求恢复参考实现时，按文件核对并备份当前差异，只撤掉本次确认不需要的改动；不对整个仓库执行恢复或清理。恢复后检查实际差异，不能仅凭编译通过声称与基线一致。

用户测试通过后，把任务状态改为“用户已确认”。用户发现问题后，在当前任务范围内修正；需求或范围发生变化时，重新确认受影响的任务和方案。

6. 底层内容

默认以应用层为主。发现 PSP、BSP、Bootloader、内核、驱动、设备树、分区、GPIO/PQ、传感器配置、底层媒体或硬件初始化需要修改，但用户没有明确要求时：

1. 保持底层文件不变。
2. 列出需要修改的内容、原因和对应用代码的影响。
3. 能独立完成的应用代码继续完成。
4. 依赖底层的部分标记为“底层未处理”。
5. 不写假接口、替代逻辑或临时流程。
6. 不建立中心转交或跟踪步骤。

用户明确说出要修改的底层类型或目标时：

1. 将修改加入任务清单并确认。
2. 查找具体文件、字段、当前值和影响；不明确的内容集中询问。
3. 给出简短实现方案并等待确认。
4. 只修改确认范围。需要增加关联文件时，先说明文件、原因和影响并等待确认。
5. 修改后检查 Git 差异，运行项目已有的配置校验。
6. 编译和打包按任务要求执行。生成 Bootloader、内核、驱动或底层镜像前单独确认。

7. 外部操作

以下工作属于应用组职责，但必须在实际执行前单独确认：

• 烧录或控制样机。
• 操作外部平台、实验室或流水线。
• 正式发布、签名或上传。
• 使用证书执行发布操作。
• 认证和量产操作。
• 生成 Bootloader、内核、驱动或底层镜像。

Git 已跟踪的账号、密码、密钥和证书按 demo 数据直接使用，不需要安全确认或隐藏。外部操作仍需确认，确认的是操作范围和影响。