City-Lifeline-Cockpit/.scratch/cockpit-real-data-wayfinding/verify/artifacts/t52/real-data-consequence.md

票 52 真实数据取证（单设备「全部未处理报警由未结束工单承接」）

• 后端仓库：E:\pipe-ner-server（Gogs shaoy/pipe-ner-server）
• 实施提交：3772220e（已推 origin/master，前一条 5d4d03c6 为编译解阻）
• 数据库：KingbaseES 192.168.110.30:54321 / pipi_ner（schema app_user），只读查询
• 取证时间：2026-10-17

1. 判定口径（维护者 2026-10-17 裁定）

设备存在报警（equipment_status.alarm_status = 1）、且该设备全部未处理报警 （alarm_data.alarm_status = 0）都满足：work_order_id 非空 且 对应工单 work_order.order_status ∈ {0,1,2,3,4,6}（未结束；5 已结案、7 已取消为终态） → 单设备状态判 WORK_ORDER；否则维持现行序（报警优先）。

2. 库内事实（复算 SQL 与结果）

未处理报警与其工单承接情况：

设备	未处理报警	其中已关联未结束工单	新规则判定
21119740	2	0	ALARM（维持现行序）
其余 8 台	0	0	无报警标志，走常规序

• alarm_data 全表 90 行，只涉 1 台设备 21119740（报警历史流水，重复报警一行一条）。
• 全表仅 2 行带 work_order_id，且这 2 行 alarm_status 都是 1（已处理）：
  • 89b53f56… → WO291（order_status=0 待派单，未结束）
  • e68a942d… → WO287（order_status=5 已结案）
• 「未处理 且 已关联工单」= 0 行。

复算 SQL：

with dev as (
  select eb.equipment_id, eb.equipment_code,
         (es.alarm_status = 1) as device_alarm
  from app_user.equipment_base eb
  left join app_user.equipment_status es on es.equipment_id = eb.equipment_id
),
u as (
  select d.equipment_code,
         count(a.id) as unhandled_cnt,
         count(a.work_order_id) as with_wo,
         count(*) filter (where a.work_order_id is not null
                            and w.order_status in (0,1,2,3,4,6)) as with_open_wo
  from dev d
  left join app_user.alarm_data a
         on a.device_code = d.equipment_code and a.alarm_status = 0
  left join app_user.work_order w on w.order_id = a.work_order_id
  group by d.equipment_code
)
select d.equipment_code, d.device_alarm,
       coalesce(u.unhandled_cnt,0) unhandled,
       coalesce(u.with_open_wo,0) covered,
       case when d.device_alarm and coalesce(u.unhandled_cnt,0) > 0
                  and u.unhandled_cnt = u.with_open_wo
            then 'WORK_ORDER(新规则命中)'
            when d.device_alarm then 'ALARM(维持现行序)'
            else '(无报警标志)' end as new_status
from dev d left join u on u.equipment_code = d.equipment_code
order by d.equipment_code;

实测输出：

equipment_code        |device_alarm|unhandled|covered|new_status
21119740              |t           |2        |0      |ALARM(维持现行序)
41010500001320000001  |f           |0        |0      |(无报警标志)
41010500000000000002  |f           |0        |0      |(无报警标志)
860347065467627       |f           |0        |0      |(无报警标志)
8652052334            |f           |0        |0      |(无报警标志)
TEST-CBLL222222222    |f           |0        |0      |(无报警标志)
TEST-CBYL5432168      |f           |0        |0      |(无报警标志)
TEST-CNXHS0000001     |f           |0        |0      |(无报警标志)
TEST-TCLLJ002215      |f           |0        |0      |(无报警标志)

3. 结论（如实记录，不夸大）

1. 新规则在当前真实数据上不改变任何设备的状态——因为今天不存在「未处理且已承接」的报警。 部署后的现场读数与部署前一致，这是正确行为，不是「没生效」。
2. 新规则的效果会在业务侧为未处理报警建单后显现：届时该设备由 ALARM 变 WORK_ORDER。
3. 票面举例不可复现：票面写「实测 21119740（alarm/warning/workOrderInProgress 三 true） 按裁定应为工单处置」——该设备 2 条未处理报警都没有工单承接，按裁定就应当是 ALARM。 票面那句话把「设备存在未结束工单」（workOrderInProgress，设备级任意一张）误当成了 「未处理报警已被工单承接」（逐条回联），二者不是同一事实。

4. 验证

• Cockpit*Test,BusinessCockpit*Test 512/512 全绿（基线 510 + 本票新增 2）。
• 变异闸 verify/t52-mutations.mjs 7/7 打红并按字节还原（基线绿 → 变异红 → 还原绿）。
• zksy-system 全量另有 2 失败 / 1 错误（AlarmLifecycleServiceTest、 WorkOrderServiceImplTest），已按 HEAD 对照（还原本票源码后复跑）确认为既有失败， 与本票改动零交集。