feat: expand vehicle data platform capabilities

vehicle-data-platform/docs/design/event-center-20260722/README.md

@@ -0,0 +1,46 @@
+# 事件中心重构规格
+
+## 产品结论
+
+“告警”不是一级数据模型，而是事件的一种处置策略。三类协议统一进入事件域：
+
+`协议事件源 → 标准事件契约 → 自动化匹配 → 动作/通知 → 运行记录`
+
+事件中心只保留三个一级任务：
+
+1. **事件流**：查看所有业务事件，只有需要人工介入的事件标记为“待关注”。
+2. **自动化**：用“当、如果、就”配置触发、范围和动作。
+3. **通知记录**：审计通知送达与已读状态，不与事件处置混为一谈。
+
+## 三类协议
+
+| 协议 | 事件源角色 | 标准事件类型示例 |
+| --- | --- | --- |
+| GB/T 32960 | 整车与新能源遥测 | `vehicle.telemetry.reported` |
+| JT/T 808 | 位置、行驶与终端状态 | `vehicle.location.reported` |
+| 宇通 MQTT | 厂商扩展遥测 | `vehicle.oem.telemetry.reported` |
+
+统一事件最小契约：`event.type`、`source.protocol`、`subject.vin`、`occurred_at`、`received_at`。协议专有字段保留在 payload 中，不渗透到自动化框架。
+
+## 参考模式
+
+- PagerDuty Event Orchestration：事件进入后按内容匹配嵌套规则并执行动作。
+- Amazon EventBridge：事件源进入总线，规则匹配后路由到一个或多个目标。
+- Grafana Alerting：规则判断、通知策略和联系点分离。
+
+本产品采用相同分层，但保留车辆业务语义和协议证据。
+
+## 视觉系统
+
+- 背景：真白与冷灰，不使用暖白或渐变光晕。
+- 主色：羚牛蓝；红/橙仅用于确实需要关注的事件或执行失败。
+- 容器：列表、轨道、分栏和表格优先，避免卡片墙与多层嵌套。
+- 签名组件：接收 → 匹配 → 动作 → 结果的细蓝色执行轨迹。
+- 桌面主工作区：事件流 70%，检查器 30%；移动端检查器变为底部 SideSheet。
+
+## 视觉概念
+
+- `event-stream-concept.png`：事件流与执行检查器。
+- `automation-concept.png`：自动化主从布局、三阶段流程与运行记录。
+
+图片仅是布局与视觉规格；文本、表格、按钮和交互均由 React 组件实现。

vehicle-data-platform/docs/design/event-center-20260722/production-readiness-audit.md

@@ -0,0 +1,89 @@
+# 事件中心生产可用性审计
+
+审计日期：2026-07-22  
+审计范围：事件流、事件详情、自动化列表、自动化编辑器、通知记录、移动端事件流  
+目标用户：重要客户的一线值守、运营管理员与平台管理员
+
+## 用户任务
+
+1. 在大量车辆事件中快速找到需要人工处理的事件。
+2. 判断事件是否可信，理解车辆、协议、观测值、规则和发生时间。
+3. 接手、补充说明、完成或忽略事件，并追溯每一步操作。
+4. 配置可理解、可验证、可审计的事件自动化。
+5. 区分事件状态、自动化执行状态和通知送达状态。
+
+## 当前截图证据
+
+截图保存在：
+
+`/Users/lingniu/.codex/visualizations/2026/07/22/019f8768-39da-7c50-a074-6c21efb5a42e/event-center-audit-2/`
+
+1. `01-event-stream-current.jpg`：事件流默认状态。
+2. `02-event-detail-current.jpg`：事件详情展开状态。
+3. `03-automation-current.jpg`：自动化列表与详情。
+4. `04-automation-editor-current.jpg`：自动化创建侧栏。
+5. `05-notifications-current.jpg`：通知记录。
+6. `06-mobile-event-stream-current.jpg`：390 × 844 移动端事件流。
+
+## 已确认的优点
+
+- 已经把 GB/T 32960、JT/T 808、宇通 MQTT 抽象到统一事件模型。
+- 事件、自动化规则、通知记录已经拥有独立的数据状态和 API。
+- 事件详情具备观测值、匹配条件、动作历史、备注和车辆/轨迹/原始数据入口。
+- 自动化支持数值、电子围栏、长时间静止、长时间离线四类触发，并有版本控制。
+- 移动端已经改为列表而不是压缩桌面表格。
+
+## 生产阻塞
+
+### P0：通知记录布局失效
+
+通知卡片的标题、正文、通道和时间被拆成横向三列，正文所在区域出现大面积空白，通道标签被压缩为“站...”。这不是视觉偏好，而是信息结构错误；客户无法快速确认“什么事件、通过什么通道、何时送达、是否已读”。
+
+### P0：事件详情的处置动作不在稳定可见区
+
+详情侧栏宽度不足，VIN 与表格字段被截断；关键处置输入和动作位于首屏下方，同时底部又固定了车辆、轨迹、原始事件三个导航动作。值守人员打开事件后不能立即完成主任务。
+
+### P1：事件前置控制层过多
+
+用户在看到第一条事件前依次经过：页面分区、筛选栏、状态统计条、协议接入条。状态统计和协议接入信息重复占据垂直空间，却没有直接帮助当前处置任务。
+
+### P1：自动化工作区同时展示过多层级
+
+运行概览、规则列表、推荐模板、流程、运行记录和事件契约同时争夺注意力；推荐模板在窄列中逐字换行。事件契约对管理员有价值，但不应默认占据主要工作区。
+
+### P1：自动化编辑器缺少分步完成感
+
+编辑器把“当、如果、就”的全部字段放进一条长滚动侧栏。保存按钮与当前错误距离过远，用户无法快速知道还差哪一步，也没有样本事件匹配测试。
+
+### P1：排版与可访问性风险
+
+- 多处说明文字接近 10–11px，浅灰文字对比度偏低。
+- 状态同时依赖颜色、圆点和极小文字，长时间值守可读性不足。
+- 详情与编辑器需要继续验证键盘焦点顺序、焦点锁定、Esc 关闭与状态变更播报。
+- 截图不能证明完整 WCAG 合规；仍需语义、键盘和自动化可访问性测试。
+
+## 成熟产品带来的结构原则
+
+- Datadog Events Explorer：搜索、分面、保存视图和事件侧栏是一套连续探索流程，而不是独立的仪表盘区块。  
+  <https://docs.datadoghq.com/events/explorer/navigate/>
+- PagerDuty：事件详情必须把状态变化、人工动作和通知统一放入可过滤时间线。  
+  <https://support.pagerduty.com/main/docs/incidents>
+- Sentry：列表负责筛选和优先级，详情活动流负责完整生命周期。  
+  <https://docs.sentry.io/product/issues/issue-details/>
+- Grafana Alerting：规则与由规则产生的事件实例是两个不同对象，状态生命周期也必须分开表达。  
+  <https://grafana.com/docs/grafana/latest/alerting/fundamentals/>
+- Amazon EventBridge：自动化核心是事件模式匹配和明确目标，并需要用样本事件测试匹配结果。  
+  <https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html>
+
+## 重构验收要求
+
+1. 默认首屏直接呈现事件，不再展示独立 KPI 与协议接入统计带。
+2. 事件搜索、状态视图、协议、类型和时间范围构成一套统一查询模型。
+3. 事件详情默认展示：身份、证据、规则、时间线和主处置动作；主动作无需滚动即可完成。
+4. 状态采用“待处理 / 处理中 / 已恢复 / 已完成 / 已忽略”，事件状态、自动化运行、通知送达互不混用。
+5. 自动化采用“事件触发 → 条件/范围 → 单一动作”的可测试编辑流程，并保留版本审计。
+6. 通知改为正常的审计列表，明确事件、严重度、通道、送达时间、阅读状态。
+7. 桌面、1024px 笔记本和 390px 移动端均无横向溢出、截断主操作或逐字换行。
+8. 加载、空数据、错误、无权限、保存冲突和动作失败均有明确可恢复反馈。
+9. 核心流程具备键盘可达、可见焦点、语义标签和状态更新播报。
+10. 生产构建、前端测试、API 测试、视觉对照和 ECS 发布门禁全部通过后才可交付。