Appearance
案例 A-03：电流状态误判与回退
先说明案例证据边界
本页保留的是一次真实脱敏排查与回退过程。能够确认的是：
- 页面出现“电流超限”显示；
- 找到了对应状态判断代码和阈值；
- 人工确认该显示在当时项目中的业务价值有限；
- 尝试修改后出现新的文本/XAML 异常；
- 最终回退到修改前可信基线。
不能从现有记录直接证明的内容，不写成已确认事实，例如：
- 乱码究竟由哪个编辑器、编码方式或保护软件机制导致；
- 删除该状态显示后整个试验流程一定长期无影响；
- 350 mA 在所有设备/工况下一定属于正常范围。
这类内容应保持 Inference / Unverified。
原始现象
一路电流约 350 mA，但界面状态显示“电流超限”。用户认为该显示与现场实际情况不一致，希望确认：
- 状态在哪里判断；
- 判断输入是什么；
- 阈值来自哪里；
- 这个状态是否会影响真实设备控制或试验流程。
这一步首先是 Read-Only Trace，不是立即修改阈值。
Read-Only Trace：先找到状态语义的来源
沿最短链路定位到 ViewModel 中的状态判断逻辑：当前值与 OverLimitCurrentA、WarningCurrentA 等阈值比较，再映射到界面状态。
当时记录显示这些阈值位于代码侧，没有看到明确的外部配置来源。由此只能得到：
text
SourceConfirmed:
当前界面状态依赖这组代码侧阈值。
Unknown:
这些阈值最初为什么这样定义，是否来自旧设备规格或历史调试值。不要把“硬编码”自动等同于“错误”。真正的问题是阈值依据没有被当前材料证明。
AI 初始建议与风险
AI 曾提出两种方向：
- 把硬编码阈值改成配置；
- 如果该显示没有业务价值，移除状态显示。
两者都不能立即执行。
改阈值的风险
如果状态还参与报警、记录、联锁或 MES，上层显示和底层控制可能共享同一语义。没有确认 ThresholdBasis 就换成另一个数字，只是把未知值替换成另一个未知值。
删除状态的风险
如果属性还被其他页面、序列化、历史记录或业务条件引用，删除 UI/属性可能产生跨层影响。
因此正确问题不是“改 350 还是删控件”，而是：
text
这个状态的 Owner 是谁？
它只用于 Display，还是 Domain Behavior？人工业务决策
在结合项目人员对现场用途的确认后，当时做出的业务判断是：该电流状态显示属于早期遗留展示，不承担设备保护职责，设备本身另有独立保护机制。
这是项目业务决策，不能由 AI 从代码命名自行推断。
如果今天重新做这类任务，建议继续沿固定链确认一次：
text
UI
→ Domain/Application
→ 外部接口/MES（若存在）
→ DeviceApply / Interlock
→ Focused references确认它确实是 DisplayOnly 后，再决定是否删除。
修改后出现新的异常
当时尝试删除相关 ViewModel 属性和 XAML 显示后，页面中文文本出现异常。
现有材料只能确认：
text
Observed:
修改后出现文本/XAML 异常。
Not Proven:
异常一定是“因为修改了包含中文字符的 XAML 区域”。编码方式、编辑器写回、DLP/E-SafeNet、文件被替换或其它文本完整性问题都可能产生类似现象。没有证据时不要编造单一根因。
为什么选择回退
这次任务的主要目标是处理状态显示，不是顺便调查编码环境。新的异常已经让修改证据链变脏，因此采用：
text
停止叠补丁
→ 回退本次改动
→ 恢复可信基线
→ readback / diff
→ 再决定是否另开编码问题调查回退不是“修复完成”，而是恢复到已知更可信的代码状态。
这一区分很重要：
RegressionFixed：新行为已经修复并有证据；RolledBackToKnownGood：撤销可疑改动，恢复旧基线；- 两者不能混写。
本案例实际能确认到什么程度
| 结论 | 状态 |
|---|---|
| 找到电流状态判断入口 | SourceConfirmed |
| 判断依赖代码侧阈值 | SourceConfirmed |
| 阈值设计依据 | Unverified |
| 人工认为该显示业务价值有限 | UserDecision |
| 删除后出现文本/XAML 异常 | Observed |
| 乱码具体根因 | Unverified |
| 已回退到修改前代码基线 | Verified by Git/diff（若有对应记录） |
| 删除状态后的长期试验行为 | HardwarePending / Unverified |
如果项目档案没有保留对应 Git/构建/现场记录，连“Verified”也应降级成 SourceConfirmed，不能靠案例文字本身抬高证据等级。
如果今天重新执行，应怎样更快
text
1. Read-Only Trace
找状态 owner、阈值来源和 consumers
2. 分类
DisplayOnly / DomainConstraint / Interlock
3. 如果确认 DisplayOnly
→ MicroPatch
→ 删除最小展示链
→ V1
4. 如果跨业务层
→ Execution / BehaviorPatch 或 DomainConstraint
→ focused consumers
→ V2/V3
5. 如果修改后出现新乱码
→ 不把两个问题混在一个补丁里
→ 回退或隔离文本完整性问题这样既不会为了一个状态标签做全仓库设计，也不会因为“看起来只是 UI”而跳过真实业务后果检查。
本案例最值得保留的经验
- Read-Only 先于修改。 用户问“为什么显示超限”时，先回答当前行为和依据。
- 硬编码不等于根因。 没有设计依据只能说明需要确认，不等于数值一定错。
- 显示、报警、联锁必须分层。 同一个“超限”文本可能只是 UI，也可能改变流程后果。
- Observed 与 RootCause 分开。 修改后乱码是现象，不自动等于已经知道编码根因。
- 回退是恢复基线，不等于修复完成。 最终报告要准确描述当前状态。
- 验证只写实际证据。 没有真机/长稳记录时保留
HardwarePending / Unverified。