Files
yovision/docs/raw/14-Bell原型评审.md
T
QiuSW 8115f584dd
Harness governance / validate (push) Has been cancelled
Harness governance / validate (pull_request) Has been cancelled
docs(design): unify Bell roster and escalation targets
2026-08-04 14:14:06 +08:00

5.0 KiB

Bell 原型评审(复核定稿)

评审对象:docs/design/bell/index.html 输入:Claude 首轮评审草稿;YoVision 需求、架构、US、IX 与路由文档 复核日期:2026-08-04

1. 结论

Claude 指出的投递状态、Event↔Alert 关系、交接班、分页、规则回滚和验收报表缺口成立,应在 T-004 内修复。Area 归属、并发 ack、失败态和重启可观测性的部分结论需要校正;另外原评审遗漏了移动端管理入口与审计深链注入风险。

2. 本轮采纳

优先级 项目 最终要求
P0 投递事实 sent、delivered、seen、ack 分开;不支持回执、状态未知、可重试失败和最终失败不得伪装为成功。ack 属于 Alert 处置事实,不是通道投递状态。
P0 Event↔Alert Alert 详情展示关联 Event 与聚合原因;Event 详情展示触发的 Alert 与最终状态;两边可导航。抑制可能不创建 Alert,不能把“已处置抑制”误写成聚合原因。
P1 并发 ack 首个服务端成功者成为处置人;后到者看到当前处置人与确认时间,不能覆盖,也不能显示双成功。
P1 交接班 展示未 ack、处置中和升级中的 Alert;明确交出人、接手人、备注和确认审计;交接期间升级链不中断。
P1 局部失败 保留弱网证据降级;新增会话过期、ack 竞争结果、规则版本冲突,以及投递的可重试/最终失败。失败应靠近对应操作,不扩展成无意义的全页状态集合。
P1 分页 事件中心和审计日志均提供总数、页码、上一页与下一页,不一次加载全部记录。
P2 规则回滚 查看版本差异与影响范围;回滚通过创建并发布新版本完成,历史版本不可变。
P2 验收报表 按规则版本和冻结样本窗口报告召回率、每路每天误报数及样本量;明确不提供跨场景统一“准确率”。

3. 校正与不采纳

  1. Area 已在 raw/12、US-010、IX-016 和架构文档中冻结为 Bell 管理,Sense 只消费版本化投影;“重写 S-03”属于过期建议,本轮不重复修改。
  2. 《13》A-2 的同库只读视图是独立架构裁决,不因原型评审直接采用。本轮继续保持 Bell 真相源与受控 API/投影边界,不修改 schema、API 或跨库访问方式。
  3. 原型已有并发 ack 文案,但没有可演示的竞争结果,因此补交互而不是从零新增概念。
  4. weak 已覆盖结构化事件成功、视频证据失败的部分成功态;“一个失败态都没有”不准确。本轮补操作级失败和会话过期,不机械增加三个全局错误页。
  5. 进程重启续跑是后端恢复、指标和测试要求。正常值班时间线不展示内部服务重启;只有确实影响用户的异常恢复才进入业务时间线,本轮不添加常态重启节点。

4. 原评审遗漏

  • 移动端底部主导航继续限制为 5 项,但通过顶部“管理”入口访问站点与 Area、审计日志,避免管理能力在窄屏不可发现。
  • 桌面侧栏分成“值班与业务”和“管理”两组,避免权限与运营入口混在同一层级。
  • Sense→Bell 审计深链的 device 参数不得通过 innerHTML/insertAdjacentHTML 拼接;必须按文本节点写入并对返回链接编码,防止原型把不可信查询参数变成 DOM 注入。

5. 实施顺序

  1. 修复审计深链注入。
  2. 补投递状态模型和 Event↔Alert 双向关系。
  3. 补并发 ack、交接班与操作级失败。
  4. 补事件/审计分页和移动端管理入口。
  5. 补规则回滚与按规则版本的验收报表。
  6. 用桌面、竖屏手机和横屏手机验证可访问性、无横向溢出及运行时安全;人工确认前 T-004 继续保持 DOING。

6. 产品裁决补充:联系人、排班与升级策略

采纳“联系人管理和排班一次设计到位”的方向,但将“同源”修正为“共享主数据、分对象建模”:

  • 联系人/成员保存身份、角色、值班组和已验证通知通道,不承载班次与轮换字段。
  • 值班排班引用联系人或值班组,保存站点时区、班次、周轮换、生效日期、临时替班、版本和冲突校验,不复制手机号。
  • 升级策略的每一步使用 person / team / on_call_schedule 类型化目标,不直接写号码;界面提供当前解析人与通道预览。
  • 每次投递创建时固化实际收件人、通道与排班版本快照,后续联系人或排班变更不改写历史事实。
  • 交接班只转移进行中 Alert 的处置责任;未来班次变化必须走临时替班并发布新排班版本。

信息架构继续保留一级“升级链”,内部以“升级策略 / 值班与排班 / 联系人与通道”三个二级模块渐进披露。M3 原型覆盖周轮换、时区、生效日期、替班、空档/重叠冲突、值班人预览、版本发布和审计;自动排班优化、外部日历同步、工时合规与自助换班后置,不在 T-004 扩展。