# 异常处置通知路由

“异常处置”只展示需要当前用户判断、授权或处置的活动事项。通知表仍是用户收件箱，不替代 `domain_event_log`；Header 列表按通知生命周期和当前用户权限过滤，不因用户已读而隐藏尚未解决的事项。

通知存在两个互不替代的状态维度：

- `lifecycle_status=active|resolved` 保存在通知文档中，表示对应业务事项是否仍需处理，是项目共享状态。
- `status=unread|read` 由 `operational_task_notification_reads` 按用户计算，只表示某个用户是否看过。

新通知保存 `subject_type + subject_id`，明确关联任务、Run、访问申请或动作。访问申请审核、动作审批、外部协同恢复、任务重试和人工材料补充，会在更新权威业务状态的同一事务中把对应通知改为 `resolved`，并追加 `operational.notification.changed`。Header 只接收 `active` 通知；活动事项被标记为已读后仍保留并计数，直到权威业务状态将其解决。已解决通知不会因为某个用户尚未阅读而继续计数。

共享生命周期事件使用 `operational_notification` 聚合；用户点击已读使用 `operational_notification_read` 聚合，聚合 ID 为 `notification_id:user_id`。这样项目共享的解决状态与每个用户的已读修订不会占用同一聚合版本。外围来源撤销时，尚未提交的动作审批、访问审批和任务级待办一并解决；已经提交或结果未知的外部动作仍保留只读回执核对入口。

## 进入异常处置的类型

| 分类 | 通知类型 | 严重度 | 说明 |
| --- | --- | --- | --- |
| 任务异常 | `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` 和 `022`。执行前必须确认 `current_database()`、完成备份，并在事务后核对：普通生命周期通知为零，仍待处理的审批保持 `active`，已经审批或恢复的事项为 `resolved`。`022` 只回填通知 JSON 文档及表注释，不新增表或物理列。其他项目数据库待 `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；上一轮整库备份未被覆盖。

`022_operational_notification_lifecycle.sql` 带有 `current_database()='tjwater_v2'` 硬门禁。实际执行后，2 条旧审批通知均已关联到动作：仍为 `pending/not_submitted` 的 1 条保持 `active`，已经 `approved/succeeded` 的 1 条变为 `resolved`；活动事项查询只返回前者，其个人已读状态不改变活动生命周期。迁移写入批量失效事件 `event_seq=79`，并更新通知文档列注释。迁移前逻辑备份位于 `/home/zhifu/TJWaterBackups/notification-lifecycle-20260924-tLsVeI/tjwater_v2-notifications-before-022.json`，SHA-256 为 `09df5efd2c748536752eaf0df94ad455d88458bb99866ed2163d8a0db56979ea`。其他 BizDB 未执行；扩展仍需维护者明确确认。

历史通知本身没有业务对象 ID。回填只在任务内恰有一个候选动作或访问申请时建立关联；存在多个候选时保持 `active` 并关联任务，不按时间邻近关系猜测，也不会自动隐藏。后续由人工核对或专门迁移处理这类歧义数据。新写入始终携带精确 `subject_id`，不受此限制。