Appearance
案例 A：现有上位机项目功能迭代
案例 A 来自现有项目的连续修改：串口保存、曲线刷新、状态判断和异常回退。它最重要的价值不是证明“现有项目都要走一套固定流程”，而是展示：同样是已有项目，任务类型不同，最短正确路径也不同。
按当前 V10 重看四类问题
| 案例 | 更接近的 V10 路由 | 不应该做什么 |
|---|---|---|
| 串口原始数据保存 | Execution / Data + Communication | 为加保存功能重构整个通信层 |
| ADC 曲线刷新 | Performance / Long-run + UI | 先换图表库、先全项目优化 |
| 电流状态误判 | Read-Only Trace → 视证据决定 Regression/Behavior | 看到阈值就直接改数字 |
| 修改引入乱码 | RegressionFix / Environment or Text Integrity | 在未知根因上继续叠补丁 |
所以“现有项目先看边界”在 V10 中不是“先做完整影响分析”，而是：
text
找到当前 Owner
→ 找直接 caller / consumer / sink
→ 判断是否跨业务语义
→ 足够后停止扩搜问题索引
01 通信接收与数据保存接收、保存、Stop/Dispose 怎样不互相拖累。02 实时数据显示刷新区分采集保存、业务计算和 UI 展示，并用实际基线判断性能。03 状态误判与回退Read-Only Trace、证据等级和可信基线。04 质量门复盘任务路由和验证等级独立，不给小改强加完整门禁。
这些案例共同留下的工程原则
先分任务查询、功能修改、性能、回归和新需求不是同一条流程。
先找最小证据链Owner / caller / sink 足够时停止，不为了“稳”无限扩搜。
行为与显示分开UI 状态不自动等于设备保护或流程后果。
回退描述要准确RolledBackToKnownGood 不等于 RegressionFixed。
通信和数据任务要看职责，不背固定实现
案例中的“接收线程不要被磁盘 I/O 拖住”是一种重要风险，但不要把它机械翻译成“所有项目必须 Channel + 后台单线程”。
真正需要确认的是：
- 接收路径是否有严格实时性要求；
- 数据是否可能丢；
- 保存顺序是否重要；
- Stop 时如何 drain/flush；
- 队列是否可能无限增长；
- 原始数据是否需要和业务结果追溯。
实现可以是 Channel、Buffer、Batch、独立 Writer 或项目已有机制，优先复用已经稳定的 seam。
曲线任务要先判断“慢在哪里”
实时曲线卡顿时不要先换库。先量化：
text
采样频率
UI 刷新频率
可见点数
一次 Dispatcher 更新耗时
CPU / 内存趋势再判断瓶颈是在采集、数据复制、集合通知、绘图、日志还是其它位置。
对应方法：性能与长稳诊断。
状态误判要区分三件事
text
DisplayOnly
DomainConstraint / Behavior
Interlock / Device Safety只有确认它属于哪一层，才能决定走 MicroPatch、BehaviorPatch 还是 V3 级别的安全修改。
状态误判案例已经按当前证据边界重写：电流状态误判与回退。
案例证据不要被“补完整”
真实案例里常见：
- 没保留完整 build 日志；
- 没做真机长稳；
- 只知道回退后恢复，尚不知道精确根因；
- 某个结论来自项目人员确认，而不是代码。
这些都应该明确写 Unverified / UserDecision / HardwarePending，而不是为了让案例更完整补出不存在的验证结果。
相关入口
一句话总结
已有项目的关键不是“先把整个项目分析完整”，而是先分清这次到底是查询、局部修改、行为变化、性能问题还是回归，再用最小证据链推进。