硬件问题必须先在受控本地环境读取完整明文串口日志，再决定哪些证据进入公开协作记录。不要把“不能公开秘密”误解成“调试时只能看摘要”；启动、分区、驱动、协议、崩溃和应用错误都应保持原始可读文本。
| 场景 | 日志要求 | 保存位置 |
|---|---|---|
| 本地调试控制台 | 保留完整明文输出，包括普通应用消息、错误、panic、版本、命令和指标。不得用泛化错误码替代诊断文本。 | 受控开发机或项目批准的私有调试存储 |
| 公开 Issue、PR 与仓库文档 | 保留支撑结论所需的完整非敏感输出与上下文，不因内容是“串口日志”而整体删减。 | Issue、PR 或稳定操作手册 |
公开前只移除真正不能传播的内容：token、密码、私钥、Wi-Fi 凭据、个人数据、原始私密语音、内存转储、完整设备备份及其他可恢复秘密。若必须替换字段，使用明确的 [REDACTED: reason]，不要把整行改成“已脱敏”或只给结论。
固件不得主动打印秘密。发现秘密进入串口输出时，先停止扩散，按 SECURITY.md 的私密路径报告，并修复日志源；这不是压缩正常调试日志的理由。
在本地日志中保存从烧录/复位开始到通过或失败结束的连续输出，并记录：
- 固件 commit、Profile、板卡、ESP-IDF 版本、串口参数和执行命令；
- 写入范围、分区表来源、镜像大小与校验值；
- 关键状态、错误原文、资源指标和通过/失败判定；
- 失败后的恢复动作与恢复后的启动结果。
不要只截取最终 PASS 行，也不要用截图替代可搜索文本。日志由多轮操作组成时，要标出每轮的开始、设备复位和结束，保证 Reviewer 能还原顺序。
硬件 PR 应附上最小但连续的文本证据：命令、环境、关键日志段、结果和回退结果。只要不含秘密，应用业务文本、驱动错误、panic 回溯、设备标识的非敏感部分和协议状态都应保留明文，不能因“脱敏”而失去诊断价值。
以下情况必须明确标注，而不是假装已通过：未接入真实凭据、仅运行 Mock、只验证数字 I/O、未完成物理声学观察、未做断电测试。完整的本地原始日志不需要上传公开仓库；公开摘录必须足以独立解释该判断。
具体烧录边界见 SparkBot 刷写与资源清单，SQLite 故障实验见 SQLite 实板验证与恢复。