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