Update embedded app debugging workflow

references/firmware-release.md

@@ -0,0 +1,25 @@
+# 简道云固件发布记录
+
+当用户要求预填、填写或核对“研发组 -> 固件发布”记录时使用本流程。以用户指定的固件包目录和当前项目工程为事实来源，不照抄上一次发布记录。用户若只授权预填，填写后核对字段即可；未经明确授权，不点击“提交”或“保存草稿”。
+
+## 确定本次发布资料
+
+1. 从用户提供的固件包路径检查当前版本目录及其现有资料，确认项目、版本、芯片/Sensor 等可以由资料直接核实的信息。不要用历史发布记录代替当前包内资料；有冲突时指出冲突，只询问无法从工程或发布资料查明的事项。
+2. 定位对应项目工程和工厂发布目录。版本差异的起点从该工厂目录 `change.log` 中读取最新时间点，不从上一个表单记录或手工猜测日期。
+3. 在项目工程目录运行系统环境可调用的 `git_history_by_date.py -d "<change.log 最新时间点>"`。脚本通常从 PATH 提供；不要假定脚本位于工程目录。保留脚本给出的扫描结果、项目目录标题、分组、顺序和提交说明。不得把按仓库目录组织的结果摊平、重排、遗漏扫描到的变更仓库，或用手工挑选记录代替扫描结果。
+4. 将脚本原始输出作为“相比上个版本的所有 git 提交记录”的依据。保留仓库目录分组和原有提交记录顺序；可清理明显的显示格式问题，但不得改写提交事实或把不同仓库的记录合并成一个主题列表。无提交的项目不自行补入。
+5. 填写 `git-repo版本信息` 等当前版本字段时，以当前工程和版本资料为准，并按该字段说明运行相应工程脚本（例如 `EmxGitInfo`）；不要把历史表单中的仓库版本复制成本次版本。
+
+## 归纳“所有影响到的功能项”
+
+1. 检查当前项目对应的功能清单（表单提示的《功能清单》或项目工程内实际使用的清单），结合本次扫描到的提交说明和受影响文件/配置，列出所有有依据的功能范围。不得只参考上一条发布记录已有的影响范围，也不得把其他产品的功能清单套用到当前项目。
+2. 把工程术语整理成测试人员可识别的功能名称和可观察行为。每项应能对应到本次提交或配置变化；提交说明只有配置默认值变化时，描述使用该默认值时受影响的行为，不扩大成未经证实的功能改动。产品特有的功能名称只在当前项目证据支持时使用，不写成通用规则。
+3. 对配置、依赖、构建文件、发布元数据等非直接业务功能改动，说明它们实际影响的配置加载、运行依赖、版本追溯等范围；若证据不足以确定设备侧功能影响，就说明为“版本/发布记录维护”等有限范围，不能臆造业务影响。
+4. 影响范围可按测试理解需要编号，但不能因此改变 Git 扫描记录原有的目录分组和顺序。检查是否覆盖每个相关仓库的功能改动，并排除扫描区间外的旧记录。
+5. 对不能从工程、功能清单或提交证据确认的影响保持克制；将推断明确标成待核实，或不写入影响项。若用户要求先预填供审核，可填写有证据的基础范围并指出无法确认的事项，不阻断已能完成的字段。
+
+## 填表与结束
+
+- 仅编辑用户指定的字段；根据当前固件包和工程资料填写，不用历史版本的数值填充未知项。
+- 输入多仓库 Git 记录时保留扫描器原始目录分组；注意长字段可能需要确认内容未被截断。
+- 预填完成后重新读取表单字段，确认文本内容和换行完整。用户只授权预填时，不点击“提交”或“保存草稿”，并在回复中明确说明记录仍未提交/保存。