# 票 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：

```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 对照（还原本票源码后复跑）确认**为既有失败**，
  与本票改动零交集。