# 19: 预警处置模式面板

**What to build:** 在预警处置一级模式下同时展示当前预警、历史分析、预警效率、预警分析四个二级面板，并保持预警/报警双模式语义。

Blocked by: 13, 16

Status: resolved
Labels: ready-for-agent

- [x] 当前预警展示当前事件、工单状态和设备定位。
- [x] 历史分析展示历史事件趋势和时间范围筛选。
- [x] 预警效率展示处置率、响应时长、关闭时长和工单七态分布。
- [x] 预警分析展示多维事件分布和重点识别。
- [x] 四个面板均支持预警/报警切换。
- [x] 面板可独立展开/收起。
- [x] 有双模式映射和统计单测。

## 阶段诊断（2026-09-24）

已读正文、依赖票 13/16、所属 effort 规格与 map、已有实施记录。依赖已满足：13 与 16 均为 resolved；本票当前无评论、无实施记录，原先的 `ready-for-agent` 状态准确反映可执行性。

现状不是零代码而是半成品：`panelCatalog.js` 已声明四个 panelId，`eventStore`/`EventListPane` 只覆盖 `currentEvents`，`panelViews.js` 未注册预警处置面板，其余三块仍渲染占位。已有事件切换只证明当前列表，不证明历史趋势、效率指标或多维分析；当前列表也未把工单状态作为可见字段。现有 mock 已覆盖跨设备当前事件，但没有 #19 所需的 history-analysis、handling-efficiency、multidimensional-analysis 三类响应。

### 本次方案

- 新增预警处置领域适配与服务层：历史事件趋势（7/30/90 天范围）、处置效率（处置率/响应时长/关闭时长/工单七态）、多维事件分析（类型/等级/行业/区域/重点识别）。
- 扩展 `eventStore` 持有四块分区；预警/报警切换和时间范围由同一 store 驱动，四块面板共享，不在组件内各存一份。
- `panelViews` 注册三块通用块视图；新增共享面板内容组件提供切换与范围筛选，复用 `PanelBlocks`。
- 当前事件补可见工单状态，并继续通过事件详情复用设备定位；事件不创建独立地图标记。
- mock 按请求真实过滤 mode/family/range，并新增零依赖逻辑闸门覆盖映射、统计、切换同步与面板注册。

真实后端接线仍受 #25 的 J2（工单 0–7 口径）和 BT-5 真实适配器状态影响，本票先按已冻结前端 mock 契约落地，不把 mock 读数宣称为真实联调结果。

## 进度：100%

**已完成并关闭（前端 mock 阶段）。**

### 交付物

- `src/modules/cockpit/domain/warningResponsePanels.js`：历史分析、预警效率、多维分析的契约适配与视图计划；包含 7/30/90 天范围、处置率、响应/关闭时长、工单七态、类型/等级/行业/区域分布和重点识别。
- `src/modules/cockpit/services/warningResponseApi.js`：统一出口接入 `/events/history-analysis`、`/events/handling-efficiency`、`/events/multidimensional-analysis`，查询参数包含共享预警/报警族、行业和时间范围。
- `src/modules/cockpit/stores/eventStore.js`：四块面板独立分区；`mode` 与 `range` 由同一个 store 持有，切换时以 token 丢弃迟到响应。
- `src/modules/cockpit/domain/panelViews.js`、`CockpitShell.vue`、`components/WarningResponsePane.vue`：注册并挂载四块面板；三块聚合面板共用范围和族切换控件，现有 `CockpitPanel` 继续提供独立展开/收起。
- `components/EventListPane.vue` 与事件 mock：当前事件行显示关联工单状态，详情继续复用既有「定位关联设备」流程，不创建事件地图实体。
- `mocks/contractMocks.js`：新增三类聚合响应，按 `eventFamily`、行业和范围真实回显/过滤；当前事件样例补工单摘要。
- `.scratch/cockpit-shell-panel-layout/verify/t19-warning-response.mjs`：零依赖逻辑闸门，覆盖目录映射、三类契约适配、统计块、空/过期状态、mode 同步、视图注册与组件静态边界。

### 验收自查

- 当前事件、工单状态、事件详情定位链路：已接。
- 历史趋势与 7/30/90 天范围筛选：已接，范围控件与请求共用 `eventStore.range`。
- 处置率、响应/关闭时长、工单七态分布：已接；适配器同时兼容 `familyMetrics` 与效率聚合字段形状。
- 多维事件分布与重点识别：已接，四类分布块和重点清单均由领域视图计划提供。
- 预警/报警双模式：四块面板共用 `eventStore.mode`，不是组件各存状态。
- 面板展开/收起：沿用既有 `CockpitPanel` 与 `uiStore.expandedPanelIds`。
- 统计单测/逻辑闸门：已新增脚本，但按仓库 `AGENTS.md` 规则，本次没有自动运行脚本、build、dev server 或浏览器调试；因此不能宣称运行时/构建验证通过。

### 边界与下一步

当前交付是 mock 阶段。真实后端仍受 #25 的 J2 工单 0–7 状态口径和 BT-5 真实适配器/联调证据影响；这些不阻塞本票的前端契约实现，但在切 real 数据源前必须复核。下一步为维护者按授权运行 `node .scratch/cockpit-shell-panel-layout/verify/t19-warning-response.mjs`，再决定是否安排 dev/浏览器走查。

## Answer

预警处置模式四块面板已完成：当前事件继续支持预警/报警切换、工单状态与设备定位；历史分析支持趋势与 7/30/90 天范围；预警效率展示处置率、响应时长、关闭时长和七态工单分布；预警分析展示类型、等级、行业、区域分布与重点识别。四块面板共享 `eventStore.mode`，三块聚合面板共享 `eventStore.range`，均保持只读与独立展开/收起。交付以 mock 契约和零依赖逻辑闸门为依据，未运行 build/debug 命令（遵循项目规则）；真实接线边界保留在 #25/J2/BT-5。

## Comments

- 本会话已完成阶段诊断并确认原票为半成品，随后补齐四块预警处置面板、聚合服务、store、mock 与逻辑闸门。
- 收口时未摘除 `ready-for-agent` 标签，因为本地 tracker 既有 resolved 票仍保留该标签；权威状态已改为 `Status: resolved`。

## 重开记录（2026-09-29，由票 20 触发）— 需要维护者复核

> **本票被重开复核，不是要重做，而是因为票 20 发现本票交付面里有两处真缺陷。**
> 维护者 2026-09-29 裁定「以后端 `WorkOrderStatusEnum`（0–7）为唯一真理，删除其他不必要的字典」，
> 票 20 执行该裁定时在本票的交付面上查出下面两条。

### 缺陷 1：本票的「工单状态分布」用错了字典 —— 标签整体错位一格

本票的「预警效率」面板画 `FamilyMetrics.workOrderStates`（键是状态码），
而中文标签取自 `domain/workOrder.js` 的 `WORK_ORDER_STATES`。那份字典当时是**旧的 1–7 七态**，
把「已结案」标在码 6 上；但后端的 6 是「延期中」、5 才是「已结案」（见票 12 重开记录里的后端原文）。

后果：**本票那块分布图的每一根柱子的标签都是错的**（例如后端的 5 已结案被画成「待验收」）。
这是"已交付但从未被真机核对过"的读数 —— 逻辑闸门全绿是因为它只验了
`workOrderStates.length === 7`（数量对，语义错），没有对着后端字典逐码核对。

**票 20 已修**：字典对齐 0–7 后本面板自动跟随（它消费同一份 `WORK_ORDER_STATES`）；
面板标题「工单七态分布」改为中性的「工单状态分布」（0–7 是 8 个码，「七态」已不成立）。
`verify/t19-warning-response.mjs` 的 B2/C2 已同步（16/16 通过）。

### 缺陷 2：本票从未把新文件补进 t05 的静态守卫面（检查不到的荒地）

票 11/17/18 都各自把新增的组件与 domain 文件补进了 `verify/t05-adapter.mjs` 的
`pageAndStoreFiles` / `domainFiles`（"不补进去，新代码就是检查不到的荒地"是票 18 的原话），
而**票 19 漏了**：`components/WarningResponsePane.vue` 与 `domain/warningResponsePanels.js`
两个文件此前**不在任何静态守卫的扫描面里**。

**票 20 已按 Q8=C 的裁定处理**：先实测这两个文件是否干净（D1 零后端裸字段 / D2 零凭据 /
D3 不自己发请求 / D4 不反向 import service / D5 不跳登录页 —— **实测全部干净**），
干净才补进名单。t05 因此由 255 → **270** 项。若当时测出是脏的，就该归本票而不是塞进票 20 的 diff。

### 缺陷 3（顺带）：处置率"分母为 0"的虚假零值

本票的 `responseEfficiencyPanel` 原先照 `handlingRate` 直画：后端在没有可算事件时回
`state=EMPTY` + `value="0.0000"`，于是界面会显示「处置率 0.0%」，而真相是「没有可参与计算的事件」。
这是票 18 在在线率上用 M3/M14 两条变异测试专门守过的那一族错，本票漏了。

**票 20 已修**：`toHandlingEfficiency()` 补带 `handlingState`，新增并**导出**
`handlingRateView()` / `handlingRateHint()`（态势总览与预警效率共用同一条判据，
不各写一份），分母为 0 时显示 `—` 加一句说明。

### 本票验收面未受影响

票面七条验收的**前端交付面**逐条仍然成立（本票已 resolved 的结论不变）；
上面三条都是"实现与后端权威契约对不上"，不改变本票交付的功能范围。
复核通过后本票可再次 close（当前 `Status: resolved` 保持不变）。