unified-notifications-ops

name	unified-notifications-ops
description	将通知作为统一的 ecc 原生工作流进行操作，涵盖 GitHub、Linear、桌面提醒、钩子以及连接的通信界面。当真正的问题是告警路由、去重、升级或收件箱崩溃时使用。
origin	ecc

统一通知运维

当真正的问题不是缺少通知，而是通知系统碎片化时，使用此技能。

任务是将分散的事件整合到一个操作员界面上，包含：

• 明确的严重等级
• 明确的责任人
• 明确的路由
• 明确的后续行动

何时使用

• 用户希望在 GitHub、Linear、本地钩子、桌面提醒、聊天或邮件之间建立统一的通知通道
• CI 失败、审查请求、问题更新和操作员事件分散在不同的地方
• 当前设置制造了噪音而非行动
• 用户希望将重叠的通知分支或积压提案整合到一个 ecc 原生通道中
• 工作区已有钩子、MCP 或连接工具，但缺乏连贯的通知策略

首选界面

从已有资源出发：

• GitHub 问题、PR、审查、评论和 CI
• Linear 问题/项目状态变更
• 本地钩子事件和会话生命周期信号
• 桌面通知原语
• 已连接的邮件/聊天界面（如果实际存在）

优先使用 ecc 原生编排，而非建议用户采用独立的通知产品。

不可妥协的规则

• 绝不暴露令牌、密钥、Webhook 密钥或内部标识符
• 区分：
  • 事件来源
  • 严重等级
  • 路由通道
  • 操作员行动
• 当中断成本不明确时，默认采用摘要优先策略
• 不要将每个事件广播到所有通道
• 如果真正的解决方案是更好的问题分类、钩子策略或项目流程，请明确说明

事件管道

将通道视为：

1. 捕获 事件
2. 分类 紧急程度和责任人
3. 路由 到正确的通道
4. 合并 重复和低信号噪音
5. 附加 下一个操作员行动

目标是更少但更好的通知。

默认严重等级模型

等级	示例	默认处理方式