unified-notifications-ops

原文涵盖的主题

• 统一通知运维
• 何时使用
• 首选界面
• 不可妥协的规则
• 事件管道
• 默认严重等级模型
• 工作流程
• 1. 盘点当前界面

当真正的问题不是缺少通知，而是通知系统碎片化时，使用此技能。 任务是将分散的事件整合到一个操作员界面上，包含： 明确的严重等级 明确的责任人 明确的路由 明确的后续行动 用户希望在 GitHub、Linear、本地钩子、桌面提醒、聊天或邮件之间建立统一的通知通道 CI 失败、审查请求、问题更新和操作员事件分散在不同的地方 当前设置制造了噪音而非行动 用户希望将重叠的通知分支或积压提案整合到一个 ECC 原生通道中 工作区已有钩子、MCP 或连接工具，但缺乏连贯的通知策略 从已有资源出发： GitHub 问题、PR、审查、评论和 CI Linear 问题/项目状态变更 本地钩子事件和会话生命周期信号 桌面通知原语 已连接的邮件/聊天界面（如果实际存在） 优先使用 ECC 原生编排，而非建议用户采用独立的通知产品。 绝不暴露令牌、密钥、Webhook 密钥或内部标识符 区分： 事件来源 严重等级 路由通道 操作员行动 当中断成本不明确时，默认采用摘要优先策略 不要将每个事件广播到所有通道 如果真正的解决方案是更好的问题分类、钩子策略或项目流程，请明确说明 将通道视为： 1. 捕获 事件 2. 分类 紧急程度和责任人 3. 路由 到正确的通道 4. 合并 重复和低信号噪音 5. 附加 下一个操作员行动 目标是更少但更好的通知。 | 等级 | 示例 | 默认处理方式 | | --- | --- | --- | | 严重 | 默认分支 CI 损坏、安全问题、发布受阻、部署失败 | 立即中断 | | 高 | 请求审查、PR 失败、阻塞责任人的交接 | 当日提醒 | | 中 | 问题状态变更、重要评论、积压变动 | 摘要或队列 | | 低 | 重复成功、常规噪音、冗余生命周期标记 | 抑制或折叠 | 如果工作区没有严重等级模型，请先构建一个，再提出自动化方案。 列出： 事件来源 当前通道 现有的发出提醒的钩子/脚本 同一事件的重复路径 重要事项未被呈现的静默失败案例 指出 ECC 已拥有的部分。 针对每个事件族，回答： 谁需要知道？ 他们需要多快知道？ 应该中断、批量处理还是仅记录？ 使用以下默认值： 发布、CI、安全和阻塞责任人的事件需要中断 中等信号更新使用摘要 遥测和低信号生命周期标记仅记录 检查： 同一 PR 事件出现在 GitHub、Linear 和本地日志中 同一失败的重复钩子通知 应总结而非直接转发的评论或状态变更 相互重复且未提供更好行动路径的通道 优先选择： 一个规范摘要 一个责任人 一个主要通道 一个备用路径 针对每个真实通知需求，定义： 来源 门控 形态：即时提醒、摘要、队列或仅仪表盘 通道 行动 如果 ECC 已有原语，优先使用： 操作员分类技能 自动触发/执行的钩子 委托分类的代理 仅在真正缺少桥接时才使用 MCP/连接器 最终输出： 保留什么

这里只展示节选，请以完整原文和当前要求为准。