469 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
lzh	3cfd342318	fix(ops): BADGE 绑定/解绑后即时同步工牌缓存 ... 问题： 1. 设备先上线、后绑定为 BADGE 时，"可分配工牌"列表迟迟不出现该设备； 2. 已绑定区域的设备收不到工单（被分派策略过滤掉）。 根因：实时上线路径 BadgeDeviceStatusEventHandler.onMessage 在写 ops:badge:status:{deviceId} Redis 缓存前，先 isBadgeDevice() 校验 ops_area_device_relation 是否存在 BADGE 关系。设备如果在绑定前就上线， 事件被丢弃；建立关系后又没有任何机制回填 Redis，得等 5/30 分钟的 BadgeDeviceStatusSyncJob 对账才会被发现（线上日志可见 deviceId=58 在 绑定后 30 分钟才被对账修正：reason=定时对账修正-上线）。 解绑同样有反向缺口：关系记录删了但 Redis 缓存得等 24h TTL 自然过期， 期间 listAvailableBadges 仍可能返回该设备。 修复：在 ops-biz 引入 AreaDeviceBoundEvent / AreaDeviceUnboundEvent， bindDevice / unbindDevice 成功后通过 ApplicationEventPublisher 发布； environment-biz 新增 BadgeAreaBoundEventListener 仅订阅 BADGE 类型， 使用 @TransactionalEventListener(AFTER_COMMIT) + @Async 确保事务提交后 异步执行不阻塞接口： - 绑定：单次调 IotDeviceQueryApi.getDevice 取齐 state + nickname + deviceName，根据状态写 Redis（IDLE/OFFLINE）； - 解绑：直接调 BadgeDeviceStatusService.deleteBadgeStatus 清理 Redis。 依赖方向遵循 environment-biz → ops-biz；ops-biz 不反向依赖条线模块， 通过事件解耦，与现有 OrderStateChangedEvent 模式一致。 测试： - AreaDeviceRelationServiceTest 补 iotDeviceQueryApi mock 让原本因缺 mock 而 RED 的 testBindDevice_TrafficCounter_Success 转绿； - 新增对 bound / unbound 事件 publishEvent 调用的 verify。 - 全套 10/10 通过。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-22 18:04:47 +08:00
lzh	6c4153fe23	fix(ops): 手动派单提前写执行人字段，修复按键报"没有工单" ... 问题：管理员手动派单后，工牌按键查询持续返回"没有工单"，TTS 循环播报"工单 来啦"但用户无法响应（线上日志可见 deviceId=58 一段时间内连续 8 次按键查询 全部命中 CleanOrderAuditEventHandler.handleQueryEvent 的"没有工单"分支）。 根因：ManualOrderActionFacade.dispatch() 原顺序是 1. transition() —— 事务内同步发布 OrderStateChangedEvent， BadgeDeviceStatusEventListener.onOrderStateChanged 重新 selectById 拿 assigneeId 决定是否写 Redis 工单关联； 2. update assigneeId / assigneeName。 第 1 步事件触发时 assigneeId 仍是 null，listener 走"工单未关联设备，跳过 处理"分支，Redis ops:badge:status:{deviceId} 的 currentOpsOrderId 永远不 会写入；同时主表 assigneeDeviceId 也始终为 null， CleanOrderAuditEventHandler.handleQueryEvent 用 "WHERE assignee_device_id=?" 查工单永远落空 → "没有工单"。 修复：把执行人字段更新前置到 transition() 之前，并补 setAssigneeDeviceId （与 OrderLifecycleManagerImpl.dispatch() 自动派单路径一致）。 事件 listener 此时 selectById 拿得到 deviceId，正常落 Redis；audit 查询也命中，按键路径恢复。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-22 18:04:10 +08:00
lzh	8c664a479d	refactor(ops): 状态转换成功不再镜像写 bus_log ... 问题：每次 transition() 成功 commit 后，OrderTransitionAuditListener 都会 向 bus_log 写一条"状态转换成功: X -> Y"的镜像记录。该信息已由各条线 EventListener（CleanOrderEventListener 的 ORDER_DISPATCHED 等）和 ops_order_event 表完整覆盖，bus_log 里这条镜像形成噪声且与业务日志重复， 线上一次工单流转能产出 4-5 条同义日志，运维抓异常时被淹没。 改动：onAfterCommit 在 event.isSuccess()=true 时直接 return； 失败 / 派发被拒（DISPATCH_REJECTED）/ 回滚三类异常路径继续写， 保留运维真正关心的"为什么失败"审计闭环。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-22 18:03:51 +08:00
lzh	c78759fd52	feat(ops): 新增保洁工单超时自动取消 Job + 集成测试 ... 背景：保洁工单偶尔因设备离线/信标丢失导致卡在非终态（如 PENDING 超 12h 没派， DISPATCHED 超 12h 没确认），靠人工清理成本高。补一个每小时跑的 XXL-Job 扫描关单。 实现： - CleanOrderAutoCancelJob.scanAndCancel： * 查询 update_time 距今超 timeoutHours（默认 12h）的 CLEAN 工单 * 状态白名单 = PENDING/QUEUED/DISPATCHED/CONFIRMED/ARRIVED，**排除 PAUSED** （PAUSED 是 P0 打断的产物，应由 resumeInterruptedOrder 走状态机恢复， 此处若把它 CANCEL，会破坏 P0 完成后的 resume 链路） * 调用 orderLifecycleManager.cancelOrder 走完整责任链，事件监听器负责 TTS 停播/设备关联回收/审计日志 * cancel 前再 selectById 做乐观校验：若 update_time 已刷新或状态已变 （COMPLETED/CANCELLED/PAUSED），跳过；避免候选装内存到实际 cancel 之间用户刚触达的工单被误杀 * 单单独立 try/catch 隔离，单条失败不断批 * batchSize 限流（默认 200），事件风暴防护 - application.yaml 补默认配置：viewsh.ops.clean.auto-cancel.{timeout-hours, batch-size} - CleanOrderAutoCancelJobTest 覆盖 6 条不变量： 无候选零计数、全成功、部分失败不中断、乐观锁跳过 stale、终态跳过、PAUSED 跳过 XXL-Job 配置建议： - JobHandler: cleanOrderAutoCancelJob - Cron: 0 17 * * * ? （每小时 :17，避开整点尖峰） Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 15:21:33 +08:00
lzh	ba6f94a279	fix(ops): review 复盘补齐 FOR UPDATE 覆盖面 + 清理注解/日志死角 ... 今日 review 发现 Bug #2 的 FOR UPDATE 防线只装在 dispatch() 上，但同文件另有两条 路径绕过它： 1. P1 — DispatchEngineImpl.autoDispatchNext 调 transition() 派发队列下一单， 不走 FOR UPDATE。idle 校验和 transition 之间存在竞争窗口，能再次让同 assignee 挂两条 DISPATCHED。改调 dispatch()，天然继承串行化。 补测 autoDispatchNext_whenDispatchingFromQueue_shouldGoThroughDispatchNotTransition 锁定该不变量。 2. P2 — OrderLifecycleManagerImpl.resumeOrder/resumeInterruptedOrder 同样走 transition()，P0 恢复与并发派发竞争时可能产生两条 DISPATCHED。改为先 selectById 取 assigneeId，改调 dispatch() 让同一检查生效。 顺手清理 3 个误导： - DispatchEngineImpl.executePushAndEnqueue 原先忽略内部 dispatch 的返回值， 并发场景下会输出假的“已推送等待任务”日志误导运维，改为按 result.isSuccess() 分支打印。 - OrderTransitionAuditListener.writeRollbackAudit 的 @Transactional(REQUIRES_NEW) 是死注解（由 onAfterRollback 自调用，Spring 代理无法拦截；且 AFTER_ROLLBACK 本就无事务），移除并更新 Javadoc 说明实际行为。 - OrderQueueServiceEnhanced.triggerQueueRebuildAfterCommit 的自调用绕过 @Transactional 是设计意图（最终一致即可），补 Javadoc 解释事务边界， 避免后续误判为 bug。 测试：ops-biz 56 个相关用例全部通过，含新增的 P1 锁定测试。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 14:51:32 +08:00
lzh	9f3ca9c6f2	test(ops): 补齐工单链路 5 个修复点的集成测试 ... 与 4d85659…a5f916c 的 5 次修复对齐，用 Mockito 风格覆盖状态链路关键分支： - DispatchEngineIdleCheckTest：autoDispatchNext 空闲兜底 + executeDispatch MySQL 活跃态降级（Bug #1/#4），ENQUEUE_ONLY 路径不触发兜底查询避免开销浪费 - DispatchEngineConflictFallbackTest：FOR UPDATE 冲突分支（Bug #2）， PENDING → 降级入队、QUEUED → 保持排队、其他错误码 → 硬失败 - OrderTransitionAuditListenerTest：审计闭环（Bug #7），AFTER_COMMIT 成功/WARN/ERROR 分支 + AFTER_ROLLBACK 强制视为失败 + 7 种目标状态映射 - QueueScoreCalculatorEnhancedTest：楼层权重 G+B，锁死"FLOOR×10 > AGING×240" 不变量，验证 base/target 任一 null → score=0，移除旧 +600 罚分后语义对称 22 个新测试全部通过；模块内 115/117 测试通过，2 个 pre-existing 失败 (VspNotifyClient/AreaDeviceRelation) 依赖外部服务，与本次改动无关。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 14:24:07 +08:00
lzh	323ddf27fb	fix(ops): 对账回填工牌 nickname，修复重启后派单人名降级为 deviceCode ... 根因：BadgeDeviceStatusSyncJob 硬编码 nickname=null，依赖 Redis 已有值。 重启后若 ops:badge:device:{deviceId} 的 nickname 丢失（TTL/清理/首次写入）， BadgeDeviceAreaAssignStrategy 会降级用 deviceCode，导致 assigneeName 变成 "43607737587"。 - SyncJob 注入 IotDeviceQueryApi，批量拉 IotDeviceSimpleRespDTO.nickname 做回填 - 状态一致但 Redis 缺 nickname 时也补写一次，覆盖最常见的重启路径 - AreaAssignStrategy 降级兜底改为 "工牌-尾号"，避免再把裸 deviceCode 当人名暴露 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 13:50:00 +08:00
lzh	a5f916c62a	fix(ops): 队列楼层权重修复——强楼层优先 + 闭环基准兜底 + N+1 优化 ... 问题：楼层差在分数公式中本该主导同优先级排序，但有四个缺陷导致效果不稳： 1. 有 base 无 target 时给 +600 罚分，无 base 时则全免罚——同一工单在 保洁员忙/闲时排序不单调（B）。 2. 基准楼层只在 user 有 PROCESSING 时生效，空闲时完全无楼层信号（A）。 3. enqueue 瞬间 score 不含楼层，要等下一轮 rebuild 才补上（H）。 4. aging 上限 720 > floorDiff 上限 600，等满 4 小时可反超同优先级 10 层差 任务，削弱"强楼层优先"语义（G）。 5. rebuild 内 for 循环对每条 WAITING 单独 selectById(order)+selectById(area)， N+1 问题（F）。 修复： 1. QueueScoreCalculator（B + G） - FLOOR_WEIGHT 60 → 100：上限 1000 > aging 上限 720，4 小时老化不再反超 同优先级的近楼层任务。 - 删除"有 base 无 target +600"分支：任一侧缺失即 score=0，语义对称。 2. OpsOrderMapper.selectLatestCompletedAreaIdByAssignee（A 二级兜底） 查最近 24h 内已完成工单的 area，用来推断空闲保洁员的物理位置。 超过 24h 视为跨班次、轨迹失效。 3. OrderQueueServiceEnhanced.resolveBaselineAreaId（A 三级兜底） PROCESSING.area → 最近 24h COMPLETED.area → 调用方传的 fallbackAreaId。 4. OrderQueueServiceEnhanced.enqueue（H） 事务提交后 triggerQueueRebuildAfterCommit(userId, null)，新入队工单 立即按楼层差参与排序，不依赖下一次 autoDispatchNext 触发。 5. OrderQueueServiceEnhanced.rebuildWaitingTasksByUserId（F） 批量 selectBatchIds(orders) + selectBatchIds(areas)，100 条 WAITING 从 200 次 SELECT 降到 2 次。 权重直观对比（P2=priority×1500=3000）： 旧分数 新分数 同层刚入队 3000 3000 差5层刚入队 3000+300=3300 3000+500=3500 差5层等2小时 3000+300-360=2940 3000+500-360=3140 同层等4小时 3000+0-720=2280 3000+0-720=2280 新权重下"差5层等2小时"仍大于"同层刚入队"，楼层稳定主导排序； 极端 aging（>4h）仍能让同层任务被近楼层任务压制优先执行。 测试：QueueScoreCalculatorTest（3）、OrderQueueServiceEnhancedTest（1， 已按 selectBatchIds + selectActiveListByUserId 更新 mock）、QueueSyncServiceTest 全绿。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 13:32:24 +08:00
lzh	3e248fee8c	fix(ops): 补齐状态转换审计闭环，回滚场景也留痕到 bus_log ... 问题：ops_order_event 在主事务内写，事务 rollback 则整段记录消失； 若状态机转换抛异常或并发冲突被拒，线上只有控制台日志而无数据库审计， 运维难以追溯"是谁、在什么时候、尝试做了什么转换、为什么失败"。 设计：中央事件发布 + TransactionalEventListener 双阶段落盘 1. OrderTransitionAttemptedEvent（新） 覆盖 transition 成功、失败、FOR UPDATE 被拒三种情况，携带 orderId、 fromStatus、targetStatus、errorCode、errorMessage、causeSummary 等。 2. OrderLifecycleManagerImpl - transition 成功分支：publishAttempt(success=true) - transition 失败分支（context.hasError）：publishAttempt(success=false, errorCode=INVALID_TRANSITION, cause=摘要) - dispatch FOR UPDATE 命中分支：publishAttempt(success=false, errorCode=ASSIGNEE_HAS_ACTIVE_ORDER) publishAttempt 内部 try/catch，审计失败不影响主流程。 3. OrderTransitionAuditListener（新） - @TransactionalEventListener(AFTER_COMMIT, fallbackExecution=true) 主事务已提交，按事件本身的 success 写 bus_log；INFO 级。 - @TransactionalEventListener(AFTER_ROLLBACK) + @Transactional(REQUIRES_NEW) 主事务已回滚，事件里声称的 success 强制视为失败；独立事务写 bus_log 避免因主事务回滚而日志同样丢失。 - errorCode、fromStatus、targetStatus、reason、cause 全部落 payload。 - 冲突（ASSIGNEE_HAS_ACTIVE_ORDER）→ WARN；其他失败 → ERROR。 4. LogType 新增 TRANSITION_FAILED、DISPATCH_REJECTED。 5. EventLogRecorder 接口补 recordSync（实现类已有同名方法）。 运维查询：按 eventDomain='dispatch' + eventLevel IN ('WARN','ERROR') 即可一眼看出所有"尝试但未成功"的状态转换。errorCode 留在 payload JSON 内， 未升级为一等字段（后续如需聚合统计再迁移）。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 13:11:28 +08:00
lzh	b534d79434	fix(ops): 派发入口加 FOR UPDATE 并发兜底，冲突时降级入队避免悬空 ... 业务不变量：同一执行人在任一时刻最多只有 1 条活跃工单 （DISPATCHED/CONFIRMED/ARRIVED）。PAUSED 不纳入——P0 打断恢复 走 PAUSED→DISPATCHED，此处必须放行。 实现： 1. OpsOrderMapper.selectActiveByAssigneeForUpdate 查询 assignee 活跃工单并对命中行加 FOR UPDATE 排他锁。必须在 事务中调用。 2. OrderLifecycleManagerImpl.dispatch 入口校验 事务开启后立即执行 FOR UPDATE 查询，命中则返回带错误码 ASSIGNEE_HAS_ACTIVE_ORDER 的失败结果，不再执行责任链， 事务 commit 空操作、锁释放；并发竞争的第二个线程会阻塞到 第一个 commit 后看到活跃单，失败退出。 3. 新增 TransitionErrorCode 枚举 + OrderTransitionResult.errorCode 调用方可区分需降级的冲突与硬失败，避免把"可降级"的结果 直接抛给用户。 4. DispatchEngineImpl.executeDirectDispatch 降级逻辑 - 冲突 + 原状态 PENDING → 调 executeEnqueueOnly 降级到 QUEUED， 工单不悬空，等下一轮 autoDispatchNext 重挑。 - 冲突 + 原状态已是 QUEUED（并发另一路抢先派发时回滚保留） → 返回 fail 但不重复入队，天然等下一轮。 - 其他失败 → 照常 fail。 职责划分： - 生命周期层负责"拒绝违反不变量的转换" - 编排层负责"失败后给工单安置归宿" Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 11:52:38 +08:00
lzh	c24b1eb641	fix(ops): 直接派发加空闲兜底 + 队列同步按活跃状态过滤 ... 1. 直接派发空闲兜底（补 autoDispatchNext 之外的另一条派发入口） DispatchEngineImpl.executeDispatch 在 DIRECT_DISPATCH/PUSH_AND_ENQUEUE 前增加 MySQL 兜底校验：若执行人仍挂活跃工单（Redis 判空闲但 MySQL 不一致的场景），强制降级为 ENQUEUE_ONLY 让任务进队列等待下一轮 autoDispatchNext 接力。避免同一设备再次出现并行多单。 2. 队列同步按活跃状态过滤 syncUserQueueToRedis / getTasksByUserId 的 MySQL 回填路径此前调用 selectListByUserId 不过滤状态，会把历史 REMOVED 记录一并同步到 Redis（线上观察到设备 31 的 Redis ZSet 塞了 206 条、其中 205 条是 REMOVED）。新增 OpsOrderQueueMapper.selectActiveListByUserId，只返 回 WAITING/PROCESSING/PAUSED，两条同步链路改走此方法。原 selectList ByUserId 保留给审计/统计场景。 未清理历史 REMOVED 记录，保留审计追溯。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 11:22:18 +08:00
lzh	4d85659277	fix(ops): 修复同一工牌并行多单的状态错乱 ... 线上观察：管理员手动取消一个僵尸 DISPATCHED 单会引发"越清越多"—— 系统顺势派队列首条给仍在工作的保洁员，监听器再用"旧工单残留"机制 尝试取消当前正在执行的工单，该取消走 REQUIRES_NEW 独立事务且吞异常， 最终新单落地、旧单残留，同一设备挂多个非终态工单。 修复两处： 1. DispatchEngineImpl.autoDispatchNext 入口加设备空闲校验： 若执行人名下还有 DISPATCHED/CONFIRMED/ARRIVED/PAUSED 工单（排除 completedOrderId），直接早返回，不再派发。所有调用方（保洁/安保 handleCancelled、asyncCompleteAndDispatchNext、xxl-job 空闲扫描） 自动受保护。新增 OpsOrderMapper.selectActiveByAssignee。 2. BadgeDeviceStatusEventListener.handleDispatched 移除"残留取消"： 旧逻辑用 REQUIRES_NEW 事务 + 吞异常，是对数据已错乱场景的暴力兜底， 失败时导致误杀。改为只打 ERROR 告警暴露问题，仅清理 Redis 关联。 真正的防线在 DispatchEngine 入口。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 10:54:54 +08:00
lzh	6bbd49355d	fix(ops): 修复工单编号生成器 Redis 序号与数据库不同步导致的重复编号问题 ... 问题：Redis 重启或 key 过期后序号从 1 重新计数，与数据库已有编号冲突。 修复方案： - 应用启动后首次生成时，从数据库查询当天最大序号校准 Redis - 使用 Lua 脚本原子操作（校准 + 自增），避免并发竞态 - 后续调用走纯 Redis INCR，无额外数据库开销 - SQL 使用 deleted = b'0' 兼容 bit(1) 列类型 - LIKE 查询转义 % 和 _ 通配符 - 校准异常向上抛出，避免静默产生重复 - calibratedKeys 跨天自动清理旧条目 同步更新单元测试，覆盖校准、纯 Redis 自增、异常处理、SQL 转义等 13 个用例。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-13 23:19:20 +08:00
lzh	7707455a24	feat(ops): 手动派单放宽校验，支持跨区域和向忙碌设备派单 ... 移除 canAcceptNewOrder、区域绑定和区域匹配校验，仅保留在线检查。 手动派单由调度员人工判断合理性，自动派单的校验仍在 BadgeDeviceAreaAssignStrategy 中完成。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-13 23:18:54 +08:00
lzh	ea374d131a	feat(ops): 工牌状态返回昵称字段，手动派单支持传入设备名称 ... - BadgeStatusRespDTO 新增 nickname 字段，透传设备昵称 - CleanManualDispatchReqDTO 新增 assigneeName，派单时携带设备显示名 - CleanWorkOrderServiceImpl 将 assigneeName 传递给派单引擎 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-13 23:18:30 +08:00
lzh	a32a4375bc	build(ci): CI/CD 支持 release/next 预发布分支 ... - Jenkinsfile: Deploy 和 Health Check 阶段支持 release/next 分支 - release/next 部署到 staging 服务器（172.17.16.7），master 部署到 prod - 仅 master 分支推送 latest 镜像标签，避免预发布覆盖生产镜像 - GitHub Actions 添加 release/next 分支触发构建 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-13 14:44:20 +08:00
lzh	1ca472ea93	feat(iot): 客流计数器支持累计值上报模式（CUMULATIVE） ... TrafficThresholdConfig 新增 reportMode 字段，支持 INCREMENTAL（默认）和 CUMULATIVE 两种模式。 累计值设备通过 Redis 存储上次值自动算差值，处理首次上报跳过和设备重启归零场景。 现有增量设备无需改配置，行为完全兼容。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-09 13:59:20 +08:00
lzh	c8ba3e63cb	feat(iot): 新增恒华D5客流摄像机编解码器，对接拌线人数统计（type=1） ... 走通用路由，新增 IotHenghuaD5Codec 解析 form-urlencoded 格式数据， 映射 InNum/OutNum 到 people_in/people_out，业务层完全复用现有客流阈值逻辑。 IotHttpUpstreamHandler 增加恒华D5 专用简洁响应。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-07 14:59:53 +08:00
lzh	04c61a41db	fix(ops): 修复 CleanBadgeServiceImpl 调用不存在的 queryAreaNameById 方法导致编译失败 ... 改用 OpsBusAreaDO.getAreaName() 获取区域名称 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-07 10:45:10 +08:00
lzh	b379fc6741	feat(ops): timeline 接口 deviceId 改为可选，支持全设备查询 ... 不传 deviceId 时查询该日期所有设备的轨迹记录，复用 selectByDateAndDevice 的 LIMIT 5000 安全上限。 Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>	2026-04-05 15:27:05 +08:00
lzh	54f78f8066	feat(ops): 工牌实时状态增加物理位置、电量和工单信息 ... BadgeRealtimeStatusRespDTO 新增物理位置（IoT 轨迹检测 RPC）、 电量（IoT 设备属性 RPC）、当前工单信息三个维度。 RPC 调用改为串行执行避免占用 ForkJoinPool 公共线程。 设备状态写入 Redis 时同步写入区域名称。 Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>	2026-04-05 15:26:43 +08:00
lzh	9ffaac5c91	feat(ops): 新增轨迹统计接口 summary/hourly-trend/area-stay-stats ... - summary: KPI 卡片（作业时长、覆盖区域数、事件数、平均停留） - hourly-trend: 按小时聚合出入趋势 - area-stay-stats: 区域停留分布（含 fullAreaName，按时长降序） - deviceId 可选，不传则汇总全部设备 - selectByDateAndDevice 加 LIMIT 5000 安全上限 - 删除无调用方的 selectTimeline 方法 - enrichWithAreaInfo 改用 buildPaths 批量构建路径 Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>	2026-04-05 15:26:14 +08:00
lzh	368fa90156	refactor(ops): 轨迹区域展示改用 fullAreaName 替代 buildingName/floorNo ... TrajectoryRespDTO 移除 buildingName、floorNo 字段，新增 fullAreaName （完整路径如"A园区/A栋/3层/男卫"）。AreaPathBuilder 新增 buildPaths 批量方法，一次查询所有父级区域避免 N+1；正则预编译为静态常量。 Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>	2026-04-05 15:25:47 +08:00
lzh	9780d6c3f7	fix(ops): 区域设备 RPC 接口添加 @TenantIgnore 解决定时任务调用时租户上下文缺失 ... IoT 模块 BeaconRegistryServiceImpl 每30分钟通过 Feign 调用 /beacons/all 接口， 因定时任务无租户上下文导致 TenantContextHolder NPE。对跨租户查询的方法添加 @TenantIgnore 注解忽略多租户过滤。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 09:23:27 +08:00
lzh	da00f08262	fix(environment): 对账修复后同步清理 TTS 循环播报 ... - BadgeDeviceStatusSyncJob 在修复设备工单一致性后额外停止 TTS 循环\n- 避免工单已清除但语音循环标记残留，导致设备继续播报\n- 对 TTS 清理失败增加 warn 日志，避免影响主对账流程	2026-03-31 22:58:40 +08:00
lzh	5d46502fb9	fix(ops): 启动时恢复工单队列缓存 ... - 新增 OrderQueueInitializer\n- 服务启动时调用 QueueSyncService.forceSyncAll()\n- 在 Redis 队列数据丢失或过期后，自动用 MySQL 数据回填 Sorted Set	2026-03-31 22:58:25 +08:00
lzh	306303ab16	fix(ops): 启动时校准人员调度状态 ... - 为 UserDispatchStatusService 增加基于 DB 的重建能力\n- 扫描 Redis 中的人员调度 key，按实际活跃工单数修正 status、activeOrderCount、waitingTaskCount\n- 新增启动初始化器，服务启动时自动执行一次校准，缓解事件丢失导致的 BUSY 残留	2026-03-31 22:58:09 +08:00
lzh	1696aeb287	fix(clean): 取消工单前先清理客流活跃标记 ... - 调整 CANCELLED 事件处理顺序\n- 先移除 area 级活跃工单 Redis 标记，再执行后续取消逻辑\n- 避免后续取消处理异常时遗留错误的活跃状态	2026-03-31 22:57:44 +08:00
lzh	f0fa5f1c46	fix(clean): 补齐客流活跃工单缓存自愈逻辑 ... - 为客流活跃工单 Redis 标记补充 TTL，避免长期残留\n- 创建工单前命中 Redis 时回查 DB，自动清理终态脏数据并刷新过期状态\n- 新增启动校准器，服务启动时批量清理或刷新 area 级活跃工单缓存	2026-03-31 22:57:28 +08:00
lzh	d3eecc63ef	feat(trajectory): 新增轨迹后台查询与实时位置接口 ... - 新增轨迹分页、时间线、统计摘要等查询 DTO\n- 提供轨迹后台控制器，支持工牌下拉、轨迹查询、实时位置查询\n- 接入 TrajectoryStateApi 的 Feign 配置，打通 Ops 对 IoT 实时位置状态的读取	2026-03-31 22:56:49 +08:00
lzh	bf5aa21648	feat(trajectory): 新增轨迹事件消费与落库模型 ... - 新增 ops_device_trajectory 表及轨迹数据对象、Mapper\n- 消费 trajectory-enter / trajectory-leave 事件并做幂等处理\n- 落地设备进入/离开区域记录，补充停留时长与离开原因字段\n- 在服务层封装轨迹写入、关闭未离场记录等核心逻辑	2026-03-31 22:56:18 +08:00
lzh	11dcb57ff3	feat(trajectory): 新增轨迹检测与 Beacon 注册表	2026-03-31 22:53:06 +08:00
lzh	a9941a29a9	fix(ops): 状态机允许 CONFIRMED → COMPLETED，支持安保确认后直接完单 ... 安保工单不需要信标到岗检测（ARRIVED），确认接单后可直接提交处理结果完成。 原规则 CONFIRMED → {ARRIVED, CANCELLED} 缺少 COMPLETED，导致安保人员完单报错： "非法状态转换: CONFIRMED -> COMPLETED" Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-27 17:11:49 +08:00
lzh	edf0a3e645	fix(clean): 修复 CleanOrderEndToEndTest 编译错误 ... sendPriorityUpgradeNotification 已从 CleanOrderEventListener 移至 CleanOrderNotificationService，测试中 verify 目标未同步更新。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-27 16:38:56 +08:00
lzh	55ef659364	feat(ops): 手动派单遵循执行人忙碌状态，忙碌时入队等待 ... ManualOrderActionFacade.dispatch： - 新增 strategy.isAssigneeIdle() 判断，空闲→DISPATCHED，忙碌→QUEUED - 不再无条件直接派发 OrderBusinessStrategy： - 新增 isAssigneeIdle() 默认方法，默认返回 true CleanOrderBusinessStrategy： - isAssigneeIdle 通过 BadgeDeviceStatusService.isBusy() 判断设备忙碌 SecurityOrderBusinessStrategy： - isAssigneeIdle 通过 UserDispatchStatusService.isIdle() 判断人员忙碌 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-27 16:37:30 +08:00
lzh	78396cf35a	fix(ops): 调度状态补偿 QUEUED→终态跳过 DISPATCHED 场景 ... UserDispatchStatusEventListener： - assigneeId 兜底从工单主表获取（forceComplete 等 payload 缺失场景） - QUEUED→COMPLETED/CANCELLED 补偿 decrementWaitingTaskCount UserDispatchStatusServiceImpl： - 新增 LUA_DECREMENT_WAITING 脚本，安全递减 waitingTaskCount（不低于 0） OpsOrderEventService：新增 8 参数 recordEvent 重载（含 operatorName） DispatchEngineServiceAdapter：reason 文案统一为"手动派单" Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-27 16:09:30 +08:00
lzh	06d701ed5e	refactor(ops): 通用控制器收口，手动动作移至条线控制器 ... OpsOrderController： - 移除 create/assign/complete/cancel 接口，避免绕过条线入口 - 保留查询、元数据维护、设备/人员驱动的状态操作（accept/pause/resume） - 新增 business-logs 查询接口 CleanWorkOrderController：新增手动创建/派单/取消端点 SecurityOrderController：新增手动派单/取消/升级优先级端点 ErrorCodeConstants：新增安保条线错误码 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-27 16:09:07 +08:00
lzh	1d09a50643	feat(security): 安保条线接入 ManualOrderActionFacade ... SecurityOrderBusinessStrategy： - validateDispatch: 去除区域绑定强限制，允许跨区域派单，保留姓名回填 - afterUpgradePriority: 队列分数重算 SecurityOrderServiceImpl： - manualDispatch: resolveUser 一次查询同时拿姓名和手机号 - manualCancel/upgradePriority: 委托 facade，传入 operatorName - 手动创建走 OrderAuditService 审计（告警触发仅写业务日志） SecurityOrderEventListener： - 3 处 resolveOperatorName() 改为从 event.payload.operatorName 读取 - 移除 AdminUserApi 依赖，消除重复远程调用 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-27 16:08:48 +08:00
lzh	5d91097e75	feat(clean): 保洁条线接入 ManualOrderActionFacade ... CleanOrderBusinessStrategy： - validateDispatch: 校验设备在线/可接单/区域匹配 - afterUpgradePriority: adjustPriority + rebuildWaitingTasks + P0 通知 CleanWorkOrderServiceImpl： - manualCreateOrder: 主表+扩展表+创建事件+审计日志 - manualDispatch/manualCancelOrder/manualCompleteOrder/upgradePriority: 委托 facade - 所有入口统一 resolveUserName 传入 operatorName UpgradePriorityReqDTO：新增 newPriority/operatorId 字段 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-27 16:08:20 +08:00
lzh	333329c29c	refactor(clean): 抽取 CleanOrderNotificationService，解除 listener 循环依赖 ... - 通知方法（语音播报/站内信）从 CleanOrderEventListener 迁移到 CleanOrderNotificationService - CleanOrderServiceImpl 改为依赖 NotificationService 而非 Listener - CleanOrderEventListener 补齐 QUEUED 和 PAUSED 状态的 business log - 派单/取消日志从 handleDispatched/handleCancelled 内联改为独立 recordXxxLog 方法 - 硬编码字符串 "CLEAN" 统一替换为 WorkOrderTypeEnum.CLEAN.getType() Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-27 16:07:57 +08:00
lzh	6e5366be57	feat(ops): OrderTransitionRequest 新增 operatorName，EventPublishHandler 透传到事件 payload ... 手动操作场景下 operatorName 沿 facade → request → EventPublishHandler → payload 透传， listener 从 payload 直接读取，不再重复调用 AdminUserApi。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-27 16:07:34 +08:00
lzh	6b01c29cb1	feat(ops): 新增统一手动动作门面与审计服务 ... ManualOrderActionFacade： - 统一骨架：查单校验 → 条线前置 → 状态变更 → 条线后置 - dispatch 支持 PENDING/QUEUED 状态，用独立对象更新 assignee 避免覆盖状态机已写入的 status - cancel/complete 走 transition() 透传 operatorName 到领域事件 - dispatch/cancel/complete 业务日志由 listener 统一记录，不重复写 OrderAuditService： - 仅用于 create/upgradePriority（不经过状态机的手动动作） - 只写 ops_business_event_log，不写 ops_order_event（时间轴只由状态机写） Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-27 16:07:13 +08:00
lzh	e1d967a65e	feat(ops): 新增手动操作枚举与模型定义 ... 引入统一手动动作基础设施： - ManualActionTypeEnum: 手动动作类型（创建/派单/取消/完单/升级） - OrderActionSourceEnum: 动作来源（管理后台/开放接口） - OrderAuditPayloadKeys: 审计 payload 标准化 key - OrderEventTypeEnum: 事件类型枚举值对齐状态机（DISPATCHED/QUEUED/CONFIRMED） - OperatorContext: 统一操作人上下文 - *Command: 手动动作命令模型（Dispatch/Cancel/Complete/UpgradePriority） - OrderBusinessStrategy: 条线策略接口 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-27 15:53:20 +08:00
lzh	4dffd21751	fix(security): 工单取消日志区分操作来源 ... 根据 operatorType 区分日志描述： - SYSTEM → "系统自动取消（原因）" - ADMIN → "管理员手动取消（原因）" - 其他 → "安保工单已取消（原因）" Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-26 16:14:34 +08:00
lzh	4763caf2cc	fix(ops): 移除 OrderLifecycleManager 中重复的业务日志记录 ... LifecycleManager 是通用层，业务日志统一由各业务线 EventListener 负责。 移除 cancelOrder、completeOrder(ADMIN)、pauseOrder、resumeOrder 中的 eventLogRecorder 调用，避免与 SecurityOrderEventListener 等监听器产生 重复日志记录。保留 interruptOrder 的日志（P0 打断是通用机制）。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-26 16:09:58 +08:00
lzh	bde680c188	fix(ops): VspNotifyClient 强制 HTTP/1.1，修复 h2c 升级导致 body 丢失 ... JDK 17 HttpClient 默认尝试 HTTP/2 升级（h2c），uvicorn 不支持 h2c 协商，处理 Upgrade 请求时丢弃 body，导致 Python 端收到空 {}。 强制 HTTP_1_1 禁用 h2c 升级。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-26 16:04:32 +08:00
lzh	93bc1f10c3	fix(security): 规范安保工单事件日志，消除重复记录 ... 修复前同一次派发产生 4 条 ORDER_DISPATCHED 日志的问题： - 新增 ORDER_QUEUED 枚举，handleQueued 改用正确的 event_type - handleArrived 改用 ORDER_ARRIVED（之前错用 ORDER_CONFIRM） - 移除 onOrderCreated 中派单成功的重复日志（由状态监听统一记录） - 移除 DispatchEngineImpl.dispatch 上的 @BusinessLog 注解（避免与 业务层 EventListener 日志重复） - ORDER_DISPATCHED 描述改为"工单派发"，ORDER_ARRIVED 改为"人员到达" Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-26 15:30:42 +08:00
lzh	bd70f3bc8a	fix(ops): 修复队列脏数据导致工单永远排队无法派发 ... 问题：autoCompleteOrder 直接调用 orderStateMachine.forceTransition， 绕过责任链导致队列记录残留 WAITING，autoDispatchNext 反复命中脏数据 失败，人员状态永远 BUSY，新工单全部 ENQUEUE_ONLY 形成死循环。 修复： 1. SecurityOrderServiceImpl 所有状态操作统一走 OrderLifecycleManager， 移除对 OrderStateMachine 的直接依赖 2. autoDispatchNext 增加循环遍历 + 工单状态校验，跳过并清理非 QUEUED 的脏队列记录，增加 maxSkip=50 防护上限 3. forceComplete 返回值校验，失败时抛异常而非静默继续 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-26 15:30:02 +08:00
lzh	8406a80655	feat(ops): OrderLifecycleManager 支持 forceComplete 强制完成工单 ... 新增 forced 字段到 OrderTransitionRequest，StateTransitionHandler 根据 该字段选择 transition 或 forceTransition，确保强制状态转换也走完整 责任链（队列同步 + 事件发布），避免绕过 QueueSyncHandler 产生脏数据。 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-26 15:29:29 +08:00
lzh	c0c9854e73	fix(security): sendCard 改为 DISPATCHED 状态变更时发送 + @EventListener ... - 将 sendCard 从 onOrderCreated 移至 handleDispatched - 使用 @EventListener 替代 @TransactionalEventListener(AFTER_COMMIT) 确保 autoDispatchNext 场景的 DISPATCHED 事件也能触发 - PAUSED → DISPATCHED 恢复场景跳过重发 - 参考保洁模块 CleanOrderEventListener 的实现模式 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-26 14:06:31 +08:00