Home Explore Help
Register Sign In
ChenJZ
/
City-Lifeline-Cockpit
1
0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Tree: bbcfa0d970
Branches Tags
City-Lifelin...
/
.scratch
/
cockpit-shell-panel-layout
/
issues
/
19-warning-response-panels.md

19-warning-response-panels.md 9.3 KB
History Raw

19: 预警处置模式面板

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

Blocked by: 13, 16

Status: resolved Labels: ready-for-agent

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

阶段诊断（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 保持不变）。