# 异常处置通知路由

“异常处置”只展示需要当前用户判断、授权或处置的活动事项。通知表仍是用户收件箱，不替代 `domain_event_log`；列表按当前用户权限和已读状态过滤。

## 进入异常处置的类型

| 分类 | 通知类型 | 严重度 | 说明 |
| --- | --- | --- | --- |
| 任务异常 | `task_failed`、`run_delivery_degraded` | 严重 | 任务失败、连续超时、产物不完整或 Agent 投递持续失败 |
| 人工审核 | `access_approval_pending`、`action_approval_pending` | 警告 | 数据访问授权、工单派发或设备动作审批 |
| 业务告警 | 活动的 `workbench.alerts` | 告警定义 | 压力、流量、水质、设备或通信等仍未解除的业务异常 |
| 人工补充 | `human_input_required` | 警告 | 计划存在等待人工处理的节点，且没有更具体的待审批动作或访问申请 |
| 外部协同异常 | `external_coordination_failed` | 严重 | 外部动作回执未知、提交失败或适配器不支持，需要人工核对 |

兼容读取旧 `action_pending`，并按“人工审核”展示。它不再由新代码写入。

## 不进入异常处置的类型

- `task_created`：任务创建后直接进入工况列表。
- `report_updated`：报告修订只更新任务详情。
- `task_completed`：正常完成不产生异常事项。
- queued、running 等普通状态变化和短暂 SSE 重连不创建用户通知。

新写入不再产生上述三类普通生命周期通知。`020_prune_non_actionable_notifications.sql` 只删除历史 `task_created`、`report_updated` 和 `task_completed` 通知及其级联已读记录，并为受影响项目写入一次批量失效事件。任务、报告、动作、业务告警和事件历史均不删除。

## 数据库应用范围

2026-09-24 本轮只允许在 `tjwater_v2` 执行 `020`。执行前必须确认 `current_database()`、完成备份，并在事务后核对：普通生命周期通知为零，审批、任务异常和外部协同异常仍保留。其他项目数据库待 `tjwater_v2` 验证通过后再单独评估，不批量应用。

本次实际执行结果：删除 16 条普通生命周期通知，保留 2 条旧 `action_pending` 审批通知，活动业务告警仍为 0 条，并写入 `event_seq=39` 的批量失效事件。通知表和用户已读表的迁移前逻辑备份位于 `/home/zhifu/TJWaterBackups/notification-routing-20260924-gZvjsn/tjwater_v2-notifications-before-020.json`，SHA-256 为 `046d6c3a0888b981791f3f39ee1972f304aab18a7e6af035da742c069b97a369`。系统缺少 `pg_dump` 客户端，因此本轮没有生成新的整库 custom dump；上一轮整库备份未被覆盖。