3.6 KiB
3.6 KiB
02 — 资产详情展示后代并形成双向换货链
What to build: 扩展统一资产详情换货投影，打通当前资产作为换货旧资产时的后代查询，使连续换货 A→B→C 中的中间资产 B 可以同时展示前代 A 和后代 C。后代同样使用换货单不可变快照，并按关联资产当前权限决定是否返回可跳转 ID。主架构通道为 Query，数据库索引为辅助 Infrastructure；完整边界止于单节点前代和后代的固定次数查询，不递归整条换货树、不新增换货链列表接口、不改变资产权限矩阵。
Blocked by: .scratch/ur86-asset-exchange-trace/issues/01-asset-previous-exchange-trace.md — 01 — 资产详情展示可控前代换货信息
Status: ready-for-agent
- 当前资产作为旧资产出现在未软删除且状态为已完成的换货单中时，
next_asset返回新资产类型、换货单快照标识、换货单号、可空资产 ID 和可见性标记；没有后代时为null。 - 卡和设备共用同一套 Query 投影逻辑，不为两种资产复制换货链查询流程。
- 后代资产有权限时返回真实 ID 和
can_view=true；无权限时保留快照标识及换货单号、返回asset_id=null和can_view=false，不泄露其他业务信息。 - A→B→C 场景查询 B 时同时返回 A 和 C，
previous_asset与next_asset互不覆盖；查询 A 和 C 时分别只返回存在的方向。 - 待填写、待发货、已发货待确认、已取消及软删除换货单均不会形成后代关系。
- 增加已完成且未软删除范围内支持“旧资产类型 + 旧资产 ID”最新记录查询的非唯一部分 B-tree 索引，并验证向上迁移、向下迁移和代表性查询计划。
- 前代和后代的关联资产可见性采用固定次数批量加载；查询次数不随设备绑定卡数量或其他列表数据增长，不产生 N+1。
- 同一资产存在多条“当前资产为旧资产”的异常完成记录时，按
completed_at降序、主键降序确定性选择最新一条，并记录包含当前资产、候选数量和最终换货单的中文异常日志。 - Query 测试覆盖仅后代、A→B→C 中间资产、卡链、设备链、关联后代可见与不可见、非完成状态、软删除记录和异常重复完成记录。
- HTTP 集成测试使用真实 PostgreSQL、Redis、JWT 和认证中间件，贯穿当前资产权限、资产解析、双向换货 Query 与统一响应格式，覆盖无换货、仅前代、仅后代、中间资产及关联资产不可见场景。
- 使用代表性 PostgreSQL 数据验证两条部分索引的结构和查询计划，资产详情增加双向换货投影后仍满足项目数据库查询与 API 性能目标，且无 N+1。
- 完成资产详情 OpenAPI 双向契约，明确
previous_asset、next_asset的空值语义，以及仅在can_view=true且asset_id非空时允许跳转。 - 完成 UR#86 中文总结并更新 README 索引，记录完整权限边界、异常选择规则、发布顺序和回滚方式；上线前抽样核验历史新旧资产 ID 与快照完整性，只记录异常、不回填数据。
- 前端人工验收覆盖无换货、换货新资产、已换出旧资产和 A→B→C 中间资产；无权限关联项只显示快照标识和换货单号，不渲染链接或可点击样式。
- 与 UR#45、UR#98 同窗发布时，仅将已实际完成的对应 Ticket 纳入发布前置检查；若形成跨 PRD 实施阻塞，必须先引用其已发布的具体 issue 文件路径和标题更新本票，不能使用模糊依赖描述。