docs(auth): record vehicle grant interval release

vehicle-data-platform/docs/authentication-authorization.md

@@ -30,6 +30,8 @@ Track, location-history and RAW queries are clamped to the exact active `valid_f
 
 Saving an unchanged vehicle assignment preserves its original start time. Removing a vehicle closes the active history interval, and assigning it again creates a new interval. The current projection is deleted on removal so existing sessions fail closed after their short cache window.
 
+Administrators manage `validFrom` and optional `validTo` per vehicle in account management. The API updates the active projection and its latest history interval in one transaction, validates `validTo > validFrom`, and repairs any pre-existing projection/history drift on save. The admin list reads the complete projection, including future or scheduled-to-end grants; customer principals still contain only grants active at the current database time. Each update audit stores the actor and per-VIN before/after interval.
+
 ## Sessions and password policy
 
 - Passwords are stored with bcrypt cost 12.
@@ -68,7 +70,7 @@ POST /api/v2/admin/users
 PUT  /api/v2/admin/users/{id}
 ```
 
-Customer creation/update accepts display name, optional external customer/tenant references, account status, menu keys and VINs. Username is immutable after creation. Password reset and account disable invalidate previous sessions.
+Customer creation/update accepts display name, optional external customer/tenant references, account status, menu keys and `vehicleGrants[]` containing VIN, required enable time and optional disable time. The legacy `vehicleVins[]` field remains accepted for compatibility and preserves existing intervals. Username is immutable after creation. Password reset and account disable invalidate previous sessions.
 
 ## External identity migration
 

vehicle-data-platform/docs/deployment.md

@@ -133,6 +133,8 @@ All three platform systemd units first load `/opt/lingniu-go-native/env/base.env
 
 `EXPORT_DIR` must point outside the release symlink. The API writes mode-`0640` CSV files and an atomic `jobs.json` index there; completed tasks survive API restarts, while interrupted queued/running jobs are marked failed and can be recreated. Every job persists its owner account, role/user type, customer/tenant references, resolved VINs and per-vehicle time scope. Non-admin principals can list and download only their own jobs; customers additionally pass a live account-status and vehicle-grant check before execution, every 5,000-row batch and every download. Old ownerless jobs remain visible only to administrators. The browser downloads through an authenticated Blob request rather than a direct anchor, so the Bearer credential is always present.
 
+Vehicle authorization dates must be changed through account management, which atomically updates the active `platform_user_vehicle` projection and its matching `platform_user_vehicle_grant_history` interval. Do not edit only one table. After saving, verify both timestamps match through `GET /api/v2/admin/users`; the response includes current `vehicles[].validFrom/validTo` and `grantHistory[]`. A start time after local midnight intentionally makes daily mileage visible from the next complete `Asia/Shanghai` day, while track/location/RAW data begins at the exact timestamp.
+
 Exports run one at a time, use 5,000-row forward-only TDengine cursors instead of `OFFSET`, stream into a `.part` file, and atomically publish the final CSV only after flush, `fsync`, and close succeed. A task is limited to five vehicles, 31 days, 32 metrics, 1,000,000 rows, and 30 minutes. Both the initial count and observed rows enforce the row cap so late-arriving data cannot bypass it. Keep the directory mode `0750`, preserve `jobs.json` and completed CSVs across releases, and include the directory in retention/backup policy. Export routes require an authenticated viewer-capable principal; ownership and current Scope are enforced inside the export service instead of relying only on role middleware.
 
 Release verification for this path includes the opt-in synthetic million-row gate:

vehicle-data-platform/docs/vehicle-data-platform-meeting-todo.md

@@ -75,7 +75,17 @@
 
 ### P0-01 客户车辆授权启停履历
 
-状态：`进行中`
+状态：`已完成`
+
+已上线结果（release `vehicle-grant-intervals-20260716180136`）：
+
+- 账号管理按车辆维护启用时间和可选停用时间，车牌主显、VIN 辅显；管理员可展开查看历次开放区间、开通人、停用人和来源系统。
+- 管理接口读取完整授权投影，不会因为授权尚未开始或已设置结束时间而把车辆从编辑页隐藏；客户会话仍只装载当前时间有效的授权。
+- 保存时在同一数据库事务内同步 `platform_user_vehicle` 当前投影与对应的 `platform_user_vehicle_grant_history` 履历。日期修正不新建重复区间，移除车辆才关闭当前区间，再次分配会新建下一次区间。
+- 后端会检测当前投影与最新履历的日期漂移；即使当前投影值未变化，一次保存也会修复履历分叉。生产原有“当前 2026-07-16、履历 2026-06-05”漂移已在不扩大客户 Scope 的前提下对齐，历史条数保持 1。
+- 每次账号保存的认证审计记录操作人及逐车授权区间的变更前/变更后；启停时间格式、重复 VIN、停用早于启用等输入均失败关闭。
+- 轨迹、位置历史和 RAW 继续从精确授权时刻裁剪；日里程继续从首个完整 `Asia/Shanghai` 自然日开始。授权日期变更最多经过 30 秒跨实例会话缓存生效，本实例立即失效。
+- Go 全量测试、现行前端 49 个文件/254 项测试和 TypeScript/Vite 生产构建通过；ECS 三个服务均 active，授权投影/履历一致性生产验证通过。
 
 目标：
 
@@ -92,10 +102,10 @@
 4. 客户 A 无法通过 VIN、车牌、URL、分页或导出访问客户 B 的车辆或历史。
 5. 变更审计包含操作人、目标账号、车辆、变更前后、时间和结果。
 
-依赖/风险：
+运维边界：
 
-- 当前表已预留 `valid_from/valid_to`，但账号管理 UI、完整履历模型及所有历史入口的统一强制校验仍需补齐。
-- 自然日里程在授权首日可能混入授权前数据，首日需采用完整授权日或提供明确的部分日口径。
+- 把授权日期回溯到过去会扩大客户可见历史，必须由管理员在账号管理页面明确保存；不得只修改其中一张表。
+- 若启用时间不是当天 00:00，日里程从下一完整自然日开始；轨迹、位置历史和 RAW 则可从精确启用时刻开始。
 
 ### P0-02 全局监控客户列表重构