08 告警中心端到端实现任务

执行要求：直接完成告警列表、详情、证据、候选诊断、动作时间线和闭环写操作，运行状态冲突、权限、幂等、审计和前端构建验证后交付。

共同门禁：不执行数据库草案，不修改 V1，不 DROP/清库或插入客户测试数据；g5b2-mysql 仅用于 SHOW、SELECT 和 EXPLAIN。接口统一使用 X-Trace-Id，缺失时后端生成并写响应头；同一动作的前端日志、后端日志、错误响应、告警动作和审计必须同值。

1. 目标与完成判定

• 菜单：告警处置 / 告警中心。
• 路由：/alarms。
• 列表支持告警级别、类型、状态、CGI、时间范围、关键词、分页和稳定排序。
• 详情展示触发快照、静态/动态/预测证据、同小时证据完整性、候选原因、缺失证据、建议和追加式动作时间线。
• 支持认领、标记已读、提交排查、提交处置、验证、申请关闭和管理员终审关闭；重开目标状态未确认时继续返回 REOPEN_NOT_CONFIGURED。

2. 开工前必读与现状核对

1. 设置 PowerShell UTF-8，阅读仓库门禁、需求 V2.0 第 5.3~5.5/6.2 节、数据库设计第 9.5/10/11/12 节及告警 DDL。
2. 阅读 AlarmCenterPage、types、api/http、PageFeedback、StatusTag。
3. 阅读告警 Controller/Service/Mapper/XML、AlarmTransitions、ActorContext、异常处理和现有测试。
4. 用 rg 查找 AlarmSummary、AlarmDetail、actOnAlarm、tb_alarm_action 的所有调用方。
5. 当前已有 GET /api/v1/alarms、GET /api/v1/alarms/{alarmNo}、POST /api/v1/alarms/{alarmNo}/actions；在现有状态机上补齐。

3. 业务规则

• 列表只显示 record_status=PUBLISHED 告警；total 与列表筛选一致，默认 triggeredAt DESC、alarmNo 稳定排序。
• SLA_ALARM 和 DEVICE_ALARM 当前不支持，筛选和生成逻辑均不得提供。
• 告警证据是触发时快照，不能用当前新版阈值/基线覆盖历史。
• 候选诊断只允许需求定义的干扰、负荷/容量、切换、预测和证据不足规则，统一写“待核验”；不得输出确认根因、设备故障或邻区 RSSI 结论。
• 生命周期：NEW → CLAIMED → PROCESSING → PENDING_VERIFY → CLOSED；验证 FAILED 回 PROCESSING，PASSED/HIT/MISS 保持 PENDING_VERIFY 等待管理员关闭。
• ROLE_USER/ROLE_ADMIN 可认领和处置；只有 ROLE_ADMIN 可最终关闭。前端禁用按钮不能代替后端授权。
• expectedVersion 用于乐观锁；非法状态返回 409。
• 同一 actionCode+traceId 必须幂等，不重复动作、状态或审计。

4. 后端实施

1. 列表：白名单筛选、分页、排序和真实 total；关键词只匹配告警号、CGI、小区等明确字段。
2. 详情：按 alarmNo 返回 AlarmSummary、evidence、candidates、timeline，子列表按业务时间/排行/actedAt+id 稳定排序。
3. 动作请求校验 actionCode、expectedVersion、必要备注/工单/verificationResult 的长度和枚举。
4. Service 使用唯一 AlarmTransitions 状态机；数据库锁定当前 PUBLISHED 告警并执行版本条件更新。
5. 动作、告警状态和 tb_alarm_action 在同一事务提交；审计 request_id 使用同一 traceId。失败/冲突按仓库审计策略记录可读结果，不能因事务回滚伪称成功。
6. REQUEST_CLOSE 追加动作但保持 PENDING_VERIFY；CLOSE 仅管理员。REOPEN 在业务目标状态确认前稳定拒绝。
7. 错误响应包含稳定 code、中文 message、timestamp、traceId；日志不记录完整证据、工单敏感内容或堆栈。

5. 数据追溯

能力	主要来源
列表和当前生命周期	tb_alarm
触发快照和同小时证据	tb_alarm_evidence
候选原因/缺失/建议	tb_diagnosis_candidate
动作时间线/验证结果	tb_alarm_action
指标、阈值、基线、预测来源	tb_metric_publish_result、tb_threshold_rule、tb_baseline_result、tb_forecast_result
操作审计	tb_audit_log，request_id=traceId

6. 前端适配

• 筛选、分页和排序真实进入请求；详情按 alarmNo 加载，关闭抽屉不污染列表条件。
• 证据值按各自单位展示，N/A 和 missingEvidence 保留；候选卡片不得改名为“根因”。
• 按后端当前 status 和权限显示/禁用动作，但始终处理 403/409。
• 每次动作生成一个 traceId，POST、随后的列表/详情刷新复用该 traceId。
• 409 后刷新服务端当前版本并提示冲突，不覆盖用户备注或伪造成功。
• 页面只展示 traceId（请求号），错误提示使用服务端返回值。

7. 最小验证门禁

1. 后端测试覆盖全部合法迁移、非法迁移、普通用户关闭 403、expectedVersion 冲突、重复 traceId 幂等、验证失败回退和重开不支持。
2. Mapper 测试核对 FOR UPDATE、版本条件、动作唯一键、列表/count 同筛选和稳定排序。
3. 只读 EXPLAIN 告警列表/count、详情子表；不写客户数据。
4. 使用隔离测试库或 Mock Repository 验证写操作；真实业务库只做已授权的 HTTP 联调，不插测试告警。
5. 真实 HTTP 核对一次动作的请求/响应头、日志、tb_alarm_action.request_id 和 tb_audit_log.request_id 同 traceId。
6. 运行相关 Maven 测试、注解 SQL 禁止扫描和 cd frontend; npm run build。

8. 交付报告

列出修改文件、最终动作矩阵、接口契约、测试/HTTP/EXPLAIN/build 实际结果、审计 trace 证据和仍不支持的 SLA、设备告警、自动根因及重开原因。