用途
Unified Notifications Ops 用于解决通知系统碎片化的问题。它的目标不是补一个缺失的 ping，而是把散落各处的通知事件收敛为一个操作界面，使每个事件具备清晰的严重级别、清晰的归属、清晰的路由和清晰的后续操作。
何时使用
- 用户希望在 GitHub、Linear、本地 hooks、桌面提醒、聊天或邮件之间建立统一的通知通道
- CI 失败、评审请求、issue 更新和操作事件出现在互不相通的地方
- 当前配置产生的是噪音而非行动
- 用户希望把重叠的通知分支或积压提案整合为一条 ECC 原生通道
- 工作区已有 hooks、MCP 或连接工具，但没有一致的通知策略
优先使用的表面
从已有资源出发：GitHub issues、PR、review、评论与 CI；Linear issue/项目变动；本地 hook 事件与会话生命周期信号；桌面通知原语；以及已实际存在的邮件/聊天渠道。优先使用 ECC 原生编排，而不是让用户另行采用一个独立通知产品。
不可妥协的规则
- 绝不暴露 token、密钥、webhook secret 或内部标识符
- 区分：事件来源、严重级别、路由渠道、操作者动作
- 当打断成本不明确时，默认采用摘要优先
- 不要把每个事件都扇出到每个渠道
- 如果真正的修复在于更好的 issue 分诊、hook 策略或项目流程，应明确指出
事件管道
将通道视为：捕获事件 → 分类紧急程度与归属 → 路由到正确渠道 → 折叠重复与低信号变动 → 附上下一步操作者动作。目标是更少、更好的通知。
默认严重级别模型
- Critical：默认分支 CI 中断、安全问题、发布阻塞、部署失败——立即打断
- High：收到评审请求、PR 失败、阻塞归属的交接——当日提醒
- Medium：issue 状态变化、值得注意的评论、积压变动——摘要或队列
- Low：重复成功、例行变动、冗余生命周期标记——抑制或折叠
如果工作区没有严重级别模型，应先建立模型再提议自动化。
工作流
- 盘点当前表面：列出事件来源、当前渠道、现有会发出警报的 hooks/脚本、同一事件的重复路径，以及重要事项未被呈现的静默失败情况。指出 ECC 已经拥有什么。
- 决定哪些值得打断：对每个事件族回答谁需要知道、需要多快知道、应该打断、批量还是仅记录。默认：发布、CI、安全和阻塞归属类事件打断；中信号更新做摘要；遥测和低信号生命周期标记仅记录。
- 在新增渠道前先折叠重复：寻找同一 PR 事件同时出现在 GitHub、Linear 和本地日志中；同一失败的重复 hook 通知；应被摘要而非原样转发的评论或状态变动；彼此重复但不提供更好行动路径的渠道。优先采用：一份规范摘要、一个归属、一个主渠道、一条回退路径。
- 设计 ECC 原生工作流：对每个真实通知需求，定义来源、门控、形态（即时警报、摘要、队列或仅仪表盘）、渠道、动作。如果 ECC 已有相应原语，优先使用：用于操作者分诊的 skill、用于自动发出/强制执行的 hook、用于委派分类的 agent、仅在缺少真实桥接时使用 MCP/connector。
- 返回偏向行动的设计：以保留什么、抑制什么、合并什么、ECC 接下来应包装什么作为结尾。
输出格式
- CURRENT SURFACE：sources、channels、duplicates、gaps
- EVENT MODEL：critical、high、medium、low
- ROUTING PLAN：source -> channel、why、operator owner
- CONSOLIDATION：suppress、merge、canonical summaries
- NEXT ECC MOVE：skill / hook / agent / MCP 以及下一步要构建的确切工作流
建议规则
- 偏好一条强通道而非多条弱通道
- 对中低信号更新偏好摘要
- 当信号应自动发出时偏好 hooks
- 当工作是分诊、路由和评审优先决策时偏好操作者技能
- 当根因是积压/PR 协调而非警报时偏好 project-flow-ops
- 当用户首先需要来源清单时偏好 workspace-surface-audit
- 如果桌面通知已足够，不要发明不必要的外部桥接
适用场景示例
- “我们有 GitHub、Linear 和本地 hook 警报，但没有单一操作者流程”
- “我们的 CI 失败太吵，人们直接忽略”
- “我想要一套跨 Claude、OpenCode 和 Codex 表面的通知策略”
- “弄清什么该打断、什么该进入摘要”
- “把重叠的通知 PR 想法收敛为一条规范的 ECC 通道”
相关技能
workspace-surface-audit、project-flow-ops、github-ops、knowledge-ops，以及当通知痛点属于计费/客户运营而非工程时使用的 customer-billing-ops。