3.7 KiB
3.7 KiB
1. 现有事实与恢复接缝
- 1.1 走读通用审批实例、企业微信上下文、提交 Outbox、集成交互记录及核销申请最新尝试字段,形成明确失败、结果未知、已有企微单号、正常重试与终态的判定矩阵,并确认原申请员工、超级管理员和平台用户可恢复,代理与企业账号拒绝。
- 1.2 在通用审批 Application/Infrastructure 边界新增按原审批实例恢复提交或触发查询确认的接缝;稳定事件键继续使用
approval:{instance_id}:submission,活动事件幂等返回,终态失败事件以条件更新恢复投递资格。 - 1.3 复用企业微信审批上下文既有
last_recovery_at返回最近渠道恢复时间,并以核销恢复审计记录人工触发时间、操作者和动作结果;不新增数据库迁移,不使用通用updated_at冒充恢复时间。
2. 员工核销恢复用例
- 2.1 在员工核销 Application 中实现恢复原审批用例:锁定申请与最新尝试,校验审批中状态、业务类型为
employee_collection_approval、业务标识等于最新尝试、尝试与最新实例引用一致,以及原申请员工或管理员权限;引用不一致、越权与终态申请均拒绝。 - 2.2 按判定矩阵处理已有企微审批单号、结果未知、明确未受理失败和正常重试;恢复不得修改申请材料、审批快照、分摊或账单预占,不得新增审批尝试或审批实例。
- 2.3 为每次人工恢复写入脱敏审计,记录申请、审批实例、实际操作者、触发前状态、恢复动作与结果;管理员代操作保持原申请人为企业微信发起人。
- 2.4 保证员工与管理员重复或并发恢复时至多一次改变提交事实,其余请求返回一致的正在恢复、已确认提交或已在审批中结果。
3. 查询投影与 HTTP 入口
- 3.1 扩展核销申请列表与详情 DTO,返回服务端判定的可恢复标记、提交状态、安全失败摘要、恢复动作结果与最近恢复时间;失败摘要不得包含附件、完整流水、企微原文或内部队列键。
- 3.2 在核销申请 Query 中按页批量读取最新审批实例、企业微信上下文和提交事件,计算恢复投影,避免列表逐条查询。
- 3.3 新增
POST /api/admin/employee-collection-applications/{id}/recover-approvalHandler 与 RouteSpec,只接受路径申请 ID;同步可执行路由、cmd/api/docs.go、cmd/gendocs/main.go及 OpenAPI 生成物要求。 - 3.4 核对原申请员工、超级管理员、平台用户、代理与企业账号的路由门禁;前三类允许恢复,后两类拒绝,越权与不存在保持不可区分,且不扩大列表、详情或其他核销写操作权限。
4. 验证与规格同步
- 4.1 在维护者指定测试环境验证明确失败恢复:同一稳定事件恢复并最终只产生一张企业微信审批单,审批尝试数、审批实例数和账单预占金额不增加。
- 4.2 验证提交结果未知与已有企微单号两条路径只确认或查询原审批,不再次调用创建审批;正常重试中的重复恢复幂等返回。
- 4.3 验证员工与管理员重复及并发操作、终态拒绝、本人和管理员权限边界、配置修复后再次恢复,以及恢复失败时申请材料和预占均不变化。
- 4.4 核对列表与详情恢复投影、审计脱敏和批量查询行为,并运行
gofmt -w、go build ./cmd/api ./cmd/worker、go run cmd/gendocs/main.go。 - 4.5 同步证据矩阵和主 Spec 可达操作索引,运行
openspec validate recover-employee-collection-approval --strict、openspec doctor --json、openspec validate --all与./scripts/context-health.sh。