feat: expand vehicle data platform capabilities
This commit is contained in:
lingniu
@@ -0,0 +1,106 @@
|
||||
# 事件中心生产重构 Design QA
|
||||
|
||||
## Automation Editor Fidelity Correction — 2026-07-22
|
||||
|
||||
- reported issue: the production implementation opened desktop automation creation/editing in a full-height right SideSheet, while the selected source uses a centered modal.
|
||||
- source: `automation-editor-desktop.png` (`1487 × 1058`, edit/review state after a successful sample test).
|
||||
- implementation: `qa/automation-editor-modal-final-desktop.png` (`1487 × 1058`, the same edit/review/test-success state).
|
||||
- combined comparison: `qa/compare-automation-editor-modal-final.png`, source left and implementation right, inspected at original detail.
|
||||
- focused geometry: centered `1068 × 936` modal at the source viewport; at `1280 × 720` it remains centered and contracts to `1068 × 672` without document overflow.
|
||||
- interaction: existing desktop automations open directly in review/test mode; create/template flows enter editable configuration first; publishing is disabled until the sample event test succeeds; mobile retains the bottom SideSheet.
|
||||
- accessibility: the dialog, configuration summary, sample event test, execution trace, close control, edit controls and publishing controls all have stable accessible names.
|
||||
- verification: `AlertsPage.test.tsx` passed `15 / 15`; TypeScript, Vite production build and artifact gate passed.
|
||||
- production release: `automation-modal-fidelity-20260722145249`; ECS Web archive SHA-256 matched locally/remotely, the atomic Web installer passed its asset smoke, authenticated health reported this exact release, and the platform plus both alert evaluators remained active.
|
||||
- intentional deviation: the footer uses `返回编辑` instead of the source's `保存草稿`, because the current API has no draft lifecycle and the UI does not pretend to persist one.
|
||||
- pass history: P1 right-SideSheet mismatch fixed; P2 close-button alignment and unresolved modal color-token issue found during comparison, fixed and rechecked.
|
||||
|
||||
final result: passed
|
||||
|
||||
- selected direction: A「事件收件箱」
|
||||
- product model: `Event → Automation → Execution → Delivery`
|
||||
- protocol scope: `GB32960`、`JT808`、`YUTONG_MQTT`
|
||||
- local prototype: `http://127.0.0.1:20301/alerts`
|
||||
- browser method: Codex in-app Browser / IAB
|
||||
- desktop viewport: `1487 × 1058`
|
||||
- mobile viewport: `390 × 844`
|
||||
|
||||
## Visual Evidence
|
||||
|
||||
| Surface | Source | Implementation | Combined comparison |
|
||||
| --- | --- | --- | --- |
|
||||
| Event inbox | `event-inbox-desktop.png` | `qa/event-inbox-desktop.png` | `qa/compare-event-inbox.png` |
|
||||
| Automation workspace | `automation-workspace-desktop.png` | `qa/automation-workspace-desktop.png` | `qa/compare-automation-workspace.png` |
|
||||
| Delivery audit | `notification-audit-desktop.png` | `qa/notification-audit-desktop.png` | `qa/compare-notification-audit.png` |
|
||||
| Automation editor | `automation-editor-desktop.png` | `qa/automation-editor-modal-final-desktop.png` | `qa/compare-automation-editor-modal-final.png` |
|
||||
| Mobile event list | `event-inbox-mobile.png` | `qa/event-inbox-mobile.png` | same-viewport visual review |
|
||||
| Mobile event detail | `event-inbox-mobile.png` | `qa/event-detail-mobile.png` | same-viewport visual review |
|
||||
|
||||
All paths are relative to this directory. Every combined comparison was inspected at original detail with the source on the left and implementation on the right.
|
||||
|
||||
## Fidelity Ledger
|
||||
|
||||
| Surface | Required fidelity | Implementation evidence | Result |
|
||||
| --- | --- | --- | --- |
|
||||
| Information architecture | The default task is to triage events, with automations and notification records as adjacent workspaces. | Text tabs preserve one clear primary task; the event stream is the default view. | Passed |
|
||||
| Event contract | Alerts must be abstracted into canonical events independent of protocol. | Event rows and detail expose canonical event type, category, source protocol, source identifier, occurred/received timestamps, automation and execution state. | Passed |
|
||||
| Event inbox | Operators need scan-first density and a stable inspector. | Compact table, semantic status tabs, selected-row state and a fixed `400px` inspector match the chosen direction. | Passed |
|
||||
| Triage actions | Acknowledgement, completion and ignore must stay reachable. | Sticky footer actions remain visible at desktop `720px` height and in the mobile full-height sheet. | Passed |
|
||||
| Automation model | Configuration should read as “when / if / then”. | Split workspace and four-step editor cover event trigger, conditions, actions, sample test and publish. | Passed |
|
||||
| Execution evidence | Every event needs automation and execution traceability. | Inspector presents event facts, original event fields and execution timeline without mixing them into the list. | Passed |
|
||||
| Delivery audit | Notification is a delivery result, not the event itself. | Independent delivery table and inspector expose channel, recipient, attempts, provider message ID, read state and delivery timeline. | Passed |
|
||||
| Responsive continuity | Mobile must retain the same task model and actions. | `390 × 844` list and detail states use a full-height sheet, no horizontal overflow and visible actions. | Passed |
|
||||
| Visual system | Reuse the existing product shell and Semi UI semantics. | Existing logo, navigation, typography, blue selection, neutral surfaces and red/orange/green status colors are preserved. | Passed |
|
||||
|
||||
## Interaction And Accessibility Checks
|
||||
|
||||
- Search, protocol filters, advanced filters, status tabs, reset and refresh are functional and keyboard-reachable.
|
||||
- Event rows expose an accessible detail action; inspector and editor provide named close controls.
|
||||
- Automation selection, edit, enable state and publish flow are connected to the existing API contract.
|
||||
- Notification records support filter, mark-all-read and per-delivery inspection.
|
||||
- Mobile list and detail have zero horizontal overflow at `390 × 844`.
|
||||
- Canonical event tests, page interaction tests and production-entry tests passed `30 / 30`.
|
||||
- Go API tests passed with `go test ./...`.
|
||||
- Production build and route byte gate passed; vehicle route is `29,999` bytes against the `30,000` byte limit.
|
||||
|
||||
## Source-to-Implementation Comparison
|
||||
|
||||
1. Both use the same shell, cool-gray canvas, white work surfaces and brand-blue selection.
|
||||
2. Both keep text tabs above a table-led event inbox, rather than competing dashboard cards.
|
||||
3. Both use a narrow right inspector and preserve context while moving between events.
|
||||
4. Both use semantic status color only for state and urgency, not decoration.
|
||||
5. Both keep the event action bar anchored at the bottom of the inspector.
|
||||
6. The implementation intentionally moves time range and scope into advanced filters to reduce the first-row query burden.
|
||||
7. The implementation adds an explicit “全部事件” status tab and names the source column “协议”, improving discoverability for the three-protocol product.
|
||||
8. The implementation turns the editor from a visual summary into a complete, editable four-step production form while preserving the selected visual hierarchy.
|
||||
|
||||
## Copy Differences
|
||||
|
||||
- “告警中心” becomes “事件中心” across the product surface.
|
||||
- “告警列表” becomes “事件流”; “告警规则” becomes “自动化”.
|
||||
- “通知” is consistently described as “通知记录 / 送达”, separating delivery from the event itself.
|
||||
- Technical labels use stable contract terms such as “事件类型”, “执行状态”, “来源协议” and “服务商消息 ID”.
|
||||
|
||||
## Intentional Deviations And Follow-up
|
||||
|
||||
- The current local mock backend predates the new API binary, so a local sample can still display `vehicle.geofence.changed`; the new API normalizes this to `vehicle.geofence.exited` after release.
|
||||
- The UI and contract support multiple delivery channels, while the current environment only has in-app delivery configured. Email, SMS or enterprise IM require provider credentials and are not simulated.
|
||||
- The remaining full-Web-suite failures are fourteen stale mileage-page copy assertions in unrelated worktree changes. The event-center test surface, Go suite and production build are green.
|
||||
|
||||
## Result
|
||||
|
||||
No open P0, P1 or P2 issue was found in the event-center desktop, mobile, automation-editor or delivery-audit flows.
|
||||
|
||||
## Production Release Evidence
|
||||
|
||||
- release: `event-center-production-20260722120255`
|
||||
- previous release: `event-center-simplified-20260722102200`
|
||||
- artifact verification: local and ECS SHA-256 matched for the Web archive and Linux API binary
|
||||
- release switch: immutable release directory plus atomic symlink switch; automatic rollback remained armed until all gates passed
|
||||
- Web smoke: `76` current assets and `117` compatibility assets verified byte-for-byte
|
||||
- authenticated health: `/api/ops/health` reported the exact new release
|
||||
- runtime: platform API, alert evaluator and alert stream evaluator all remained `active`
|
||||
- real event evidence: canonical events included `vehicle.connectivity.offline / connectivity / JT808 / pending` and the same event type from `YUTONG_MQTT`
|
||||
- real automation evidence: `9` automations loaded, `2` enabled
|
||||
- real delivery evidence: `in_app / delivered / JT808`, with vehicle VIN/plate, provider message ID and attempt count populated
|
||||
|
||||
final result: passed
|
||||
Reference in New Issue
Block a user