feat(platform): align console with vehicle operations center

vehicle-data-platform/docs/deployment.md

@@ -40,11 +40,11 @@ AMAP_WEB_JS_KEY=***
 AMAP_SECURITY_JS_CODE=***
 AMAP_SECURITY_SERVICE_HOST=/_AMapService
 # Optional reserved server-side key for AMap REST/track services.
-AMAP_API_SERVICE_KEY=***
+AMAP_API_KEY=***
 PLATFORM_RELEASE=platform-YYYYMMDDHHMMSS
 ```
 
-`AMAP_WEB_JS_KEY` is served to the browser through `/app-config.js` so the same static build can be reused across environments. For production, set both `AMAP_SECURITY_JS_CODE` and `AMAP_SECURITY_SERVICE_HOST=/_AMapService`; the API service keeps the security code on the server and proxies AMap requests with `jscode` appended. Only omit `AMAP_SECURITY_SERVICE_HOST` for controlled debugging where exposing `AMAP_SECURITY_JS_CODE` to the browser is acceptable. `AMAP_API_SERVICE_KEY` is reserved for backend-only AMap service APIs such as geocoding, route planning, geofence, or trajectory service integration.
+`AMAP_WEB_JS_KEY` is served to the browser through `/app-config.js` so the same static build can be reused across environments. For production, set both `AMAP_SECURITY_JS_CODE` and `AMAP_SECURITY_SERVICE_HOST=/_AMapService`; the API service keeps the security code on the server and proxies AMap requests with `jscode` appended. Only omit `AMAP_SECURITY_SERVICE_HOST` for controlled debugging where exposing `AMAP_SECURITY_JS_CODE` to the browser is acceptable. `AMAP_API_KEY` is reserved for backend-only AMap service APIs such as geocoding, route planning, geofence, or trajectory service integration.
 
 `PLATFORM_RELEASE` is surfaced by `/api/ops/health.runtime.platformRelease` so operators can confirm which ECS release is currently active after a deployment.
 

vehicle-data-platform/docs/product-spec.md

@@ -2,7 +2,7 @@
 
 ## Visual Direction
 
-The UI is a professional vehicle data operations console. It uses Semi UI as the component base, a restrained gray-white control-room palette, dense but readable tables, right-side drawers for detail, and blue-cyan accents for primary actions. It should feel closer to a cloud data console than a marketing dashboard.
+The UI is a professional vehicle data operations console. It uses Semi UI as the component base, a restrained gray-white control-room palette, dense but readable tables, right-side drawers for detail, and blue-cyan accents for primary actions. It should feel closer to a cloud data console and mature fleet telematics platform than a marketing dashboard.
 
 ## Product North Star
 
@@ -12,19 +12,21 @@ Every primary workflow should answer a vehicle-level question first, then allow
 
 The current product goal is to evolve toward a production vehicle data management center, comparable to mature fleet IoT and telematics platforms: realtime monitoring, trajectory replay, historical evidence query, alert triggering and notification, statistics, and production operation quality all serve the same vehicle object.
 
+The product must not expose GB32960, JT808, and Yutong MQTT as three final products. They are acquisition paths. The final product is a vehicle service that answers online state, current location, historical trajectory, source reliability, alert responsibility, and statistical evidence for one vehicle.
+
 ## Primary Screens
 
 The platform navigation should use vehicle-service language rather than protocol-product language:
 
 1. Operations Cockpit: vehicle service KPI summary, service status distribution, live map preview, alert queue, data quality, and link health.
-2. Live Monitor: map-first current vehicle monitoring with online/offline state, abnormal highlights, source freshness, and a dense vehicle table.
+2. Live Monitor: map-first current vehicle monitoring with online/offline state, abnormal highlights, source freshness, AMap readiness, and a dense vehicle table.
 3. Vehicle Center: table-first vehicle registry, binding state, source coverage, service status, and missing-source governance.
 4. Vehicle Detail: one vehicle service file with identity, latest realtime state, source evidence, history, raw, mileage, alerts, quality evidence, and copyable diagnostics.
-5. Trajectory Replay: historical location playback with AMap polyline, playback marker, auto play/pause, speed controls, and table evidence.
+5. Trajectory Replay: historical location playback with AMap polyline, playback marker, auto play/pause, speed controls, gap detection, mileage evidence, 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. Notification Rules: alert trigger rules, notification targets, channels, escalation windows, acceptance criteria, and copyable runbooks.
-9. Statistics: one vehicle-service statistics workspace covering daily/range mileage, online rate, offline duration, data completeness, and source consistency.
+7. Alert Events: alert trigger records, affected vehicles, rule evidence, manual state, notification state, escalation readiness, and recovery evidence.
+8. Notification Rules: alert trigger rules, notification targets, channels, escalation windows, acceptance criteria, affected-user scope, and copyable runbooks.
+9. Statistics: one vehicle-service statistics workspace covering daily/range mileage, online rate, offline duration, data completeness, source consistency, and exportable evidence.
 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.
@@ -77,6 +79,7 @@ AMap should be treated as infrastructure for vehicle operations, not only as a v
 - History query: location evidence can open the same coordinate in the map context.
 - Alert events: vehicle location at trigger time should be shown when longitude and latitude are available.
 - Ops quality: map key readiness, security proxy readiness, and frontend loader failures should be visible.
+- Statistics: mileage and online-rate anomalies should link back to a map/time-window context so operators can verify whether the issue is vehicle behavior or source data loss.
 
 AMap credentials supplied by operations must be configured through ECS environment variables:
 
@@ -85,6 +88,12 @@ AMap credentials supplied by operations must be configured through ECS environme
 - `AMAP_SECURITY_JS_CODE`: private security code kept by the API service.
 - `AMAP_SECURITY_SERVICE_HOST=/_AMapService`: frontend proxy path used by the AMap loader.
 
+Supplied AMap production credentials must be applied on ECS only:
+
+- API service key: configure as `AMAP_API_KEY`.
+- Web JS key: configure as `AMAP_WEB_JS_KEY`.
+- Web JS security code: configure as `AMAP_SECURITY_JS_CODE`.
+
 ## Alert And Notification Scope
 
 Alert events are first-class product records, but notification delivery can be implemented incrementally.

vehicle-data-platform/docs/vehicle-platform-blueprint.md

@@ -13,6 +13,8 @@ Build one vehicle data management platform around a single vehicle service. GB32
 
 The product direction should reference production telematics and fleet IoT platforms, but keep the Lingniu domain model simple: one vehicle service, multiple source evidences, auditable history, and operational alerts. Realtime data source pages are not product destinations; they are evidence and diagnosis layers under the vehicle.
 
+The current product goal is therefore adjusted to: build a complete vehicle data management center with realtime monitoring, trajectory replay, history query, alert triggering and notification, statistics, and operations quality. GB32960, JT808, and Yutong MQTT remain source evidence and should disappear from the primary user mental model unless the user is diagnosing a specific source.
+
 ## Market Reference
 
 Common telematics, fleet-management, and vehicle IoT platforms converge on a small set of durable workflows:
@@ -31,6 +33,12 @@ Relevant references:
 - Commercial fleet platforms: live GPS tracking, historical route playback, geofence, driver behavior, alerts, reports, and asset management.
 - Domestic vehicle-monitoring platforms: monitoring cockpit, vehicle monitor, trip replay, realtime alerts, running statistics, and alert management.
 
+Reference principles used for the Lingniu platform:
+
+- Samsara-style telematics products emphasize realtime GPS visibility, diagnostics, routing/navigation, energy/fuel, alerts, and operational efficiency.
+- AMap Web JS should power map rendering, marker interaction, and trajectory display while keeping the security code behind a service proxy.
+- TDengine vehicle IoT guidance fits the platform's realtime location monitoring and trajectory replay query pattern, while Redis remains the low-latency realtime projection.
+
 ## Information Architecture
 
 The left navigation should be vehicle-service oriented:
@@ -83,6 +91,7 @@ Primary modules:
 - Right-side vehicle queue: online, offline, degraded, abnormal, no location.
 - Bottom table: latest position, speed, mileage, source freshness, service status.
 - Map overlays: online state, protocol source, alert severity.
+- Production readiness rail: AMap Web JS state, security proxy state, location point cap, latest refresh time, and fallback mode.
 
 AMap behavior:
 
@@ -140,6 +149,7 @@ Primary modules:
 - Playback controls: play, pause, speed, step, seek, and auto-stop at the last point.
 - Evidence table: time, longitude, latitude, speed, mileage, protocol, raw frame link.
 - Quality strip: missing points, time gaps, mileage jumps.
+- Export and share controls: copy query link, open AMap line, export current page evidence.
 
 Query:
 
@@ -193,6 +203,7 @@ Required alert domains:
 - Raw parse failure or unknown field burst.
 - Binding missing or VIN unresolved.
 - Cross-source time/location/mileage inconsistency.
+- AMap unavailable or security proxy misconfigured.
 
 ### Notification Rules
 
@@ -220,6 +231,7 @@ Primary modules:
 - Completeness: location, mileage, SOC, speed, source freshness.
 - Consistency: cross-source time delta and mileage delta for multi-source vehicles.
 - Statistics overview: show the four domains together so operations users understand that GB32960, JT808, and Yutong MQTT are evidence feeding one vehicle service.
+- Notification impact: affected vehicles, affected BI users, last normal data time, and recovery time after alert closure.
 
 Rule:
 
@@ -250,6 +262,7 @@ Use Semi UI as the component base. The style should feel like a cloud operations
 - Cards only for repeated metrics or detail blocks; avoid nested cards.
 - Drawer for detail and evidence, full routes for heavy workflows.
 - No landing page, no marketing hero, no oversized decorative cards.
+- Primary navigation should use user jobs: operations cockpit, realtime monitor, vehicle center, trajectory replay, history query, alerts, statistics, notification rules, and ops quality.
 
 ## Data Model Boundaries