发布固件应用层开发 Skill

references/workflow.md

@@ -0,0 +1,106 @@
+# 开发流程
+
+修改文件、生成产物或执行命令前，按下面顺序处理。
+
+```text
+只读检查需求和工程
+→ 检查 Git 和 .gitignore
+→ 确认不清楚的需求
+→ 确认完整任务清单
+→ 确认当前任务的实现方案
+→ 开发当前任务
+→ 编译或静态检查
+→ 汇报代码和差异
+→ 等待用户确认和测试
+→ 处理下一个任务
+```
+
+## 1. 只读检查
+
+- 阅读当前需求、规格说明、功能清单、工程说明、构建脚本和相关代码。
+- 参考工程只用于了解做法，不能直接代替目标工程的要求。
+- 找出本次需要修改的应用模块，以及可能依赖的底层内容。
+- 查看 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. 当前任务明确要求打包或产物检查时，可以执行对应命令。
+9. 再次检查 Git 状态和差异，确认中间文件已被忽略。不得暂存或提交。
+10. 用简洁中文汇报结果，等待用户确认和测试。
+
+用户测试通过后，把任务状态改为“用户已确认”。用户发现问题后，在当前任务范围内修正；需求或范围发生变化时，重新确认受影响的任务和方案。
+
+## 6. 底层内容
+
+发现 PSP、BSP、Bootloader、内核、驱动、设备树、分区、GPIO/PQ、传感器底层配置、底层媒体或硬件初始化需要修改时：
+
+1. 不修改、不重新生成，也不做试验性改动。
+2. 列出需要底层处理的内容、原因和对应用代码的影响。
+3. 能独立完成的应用代码继续完成。
+4. 依赖底层的部分标记为“底层未处理”。
+5. 不写假接口、替代逻辑或临时流程。
+6. 不建立中心转交或跟踪步骤。
+
+底层内容以后准备好时，应用组负责按当前需求完成应用侧接入、编译、打包、联调和后续工作，但仍不修改底层文件。
+
+## 7. 外部操作
+
+以下工作属于应用组职责，但必须在实际执行前单独确认：
+
+- 烧录或控制样机。
+- 操作外部平台、实验室或流水线。
+- 正式发布、签名或上传。
+- 使用证书执行发布操作。
+- 认证和量产操作。
+
+Git 已跟踪的账号、密码、密钥和证书按 demo 数据直接使用，不需要安全确认或隐藏。外部操作仍需确认，确认的是操作范围和影响。