feat(platform): add notification rules workspace

This commit is contained in:
lingniu
2026-07-04 16:27:37 +08:00
parent 33da8ba5a4
commit c060317fb0
8 changed files with 287 additions and 9 deletions

View File

@@ -21,8 +21,9 @@ The platform navigation should use vehicle-service language rather than protocol
5. Trajectory Replay: historical location playback with AMap polyline, playback marker, controls, and table evidence.
6. History Query: historical locations, raw frames, and flattened parsed fields with pagination and field trimming.
7. Alert Events: alert trigger records, affected vehicles, rule evidence, manual state, notification state, and escalation readiness.
8. Statistics: daily/range mileage, online rate, offline duration, data completeness, and source consistency.
9. Ops Quality: GB32960, JT808, Yutong MQTT, Kafka, NATS, Redis, TDengine, MySQL, AMap, gateway, and runtime health.
8. Notification Rules: alert trigger rules, notification targets, channels, escalation windows, acceptance criteria, and copyable runbooks.
9. Statistics: daily/range mileage, online rate, offline duration, data completeness, and source consistency.
10. Ops Quality: GB32960, JT808, Yutong MQTT, Kafka, NATS, Redis, TDengine, MySQL, AMap, gateway, and runtime health.
See `docs/vehicle-platform-blueprint.md` for the detailed page-level blueprint and phased implementation plan.
@@ -83,6 +84,8 @@ Alert events are first-class product records, but notification delivery can be i
Alerts should cover source offline, no realtime update, location missing, mileage abnormality, raw parse failure, binding missing, and cross-source inconsistency.
Notification rules are managed separately from alert records. Alert Events answers "what is happening now"; Notification Rules answers "who should be notified, when to escalate, and how to verify recovery." A rule should always expose trigger condition, owner, channel, escalation window, and acceptance criteria.
## Statistics Scope
Statistics must stay vehicle-first and evidence-backed: