Files
2026-07-27 16:46:15 +08:00

9.0 KiB
Raw Permalink Blame History

事件中心生产重构 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: GB32960JT808YUTONG_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