zkxw/openspec/changes/outbound-release-review/design.md

Context

中试服务管理已有完整的出库生产+质检闭环：中试申请单 → 输注方案 → 输注计划 → 出库生产工单/任务 → 出库质检工单/任务。已存在 biz_outbound_release_review 表和基础 CRUD（4个端点、149行），但功能简陋：创建时未关联生产/质检工单，无聚合查询，无前端页面。

入库放行审核（storage-release-review）已有完整实现（后端757行 CRUD + 3个 Vue 文件 + 独立 API 文件），可参照其模式设计出库放行审核。

后端已有可复用函数 build_outbound_pilot_context_by_schedule(db, schedule_id, tenant_no)，一次性查出申请单/患者/输注方案/计划/产品信息。

Goals / Non-Goals

Goals:

• 实现完整的出库放行审核模块（后端聚合查询 + 前端列表/查看/审核界面）
• 每条输注计划独立审核，查看其关联的生产工单/任务和质检工单/任务结果
• 审核通过/不通过 + 备注 + 附件，仅记录结论不自动改状态
• 参照入库放行审核模式，保持代码风格和架构一致性

Non-Goals:

• 不实现自动联动状态更新（审核通过后不自动改输注计划状态）
• 不实现工作流引擎（审核为单步操作，非多级审批）
• 不修改已有入库放行审核模块
• 不修改生产/质检工单的已有逻辑

Decisions

D1: 复用已有 biz_outbound_release_review 表 vs 新建表

选择: 复用已有表，补充缺失字段。 理由: 表已存在且与 infusion_schedule_id 关联，只需补充 review_attachments、review_by_name、create_by_name 等快照字段。 备选: 新建表——会增加迁移成本且无额外收益。

D2: 审核列表页数据来源

选择: 基于 biz_pilot_infusion_schedule 构建，左连接 biz_outbound_release_review 获取审核状态。 理由: 审核对象是输注计划，而非审核记录本身。输注计划创建后，只有生产和质检都完成才需要审核。列表页展示所有排程（附带审核状态），而非只展示已创建审核记录的排程。 备选: 只展示已创建审核记录的排程——会导致"待审核"状态的排程无法展示。

D3: 前端页面放在 pilot-service 目录 vs quality-inspection 目录

选择: 放在 pilot-service/outbound-release-review/。 理由: 用户决策放在中试服务管理菜单下，与输注计划管理同级。 备选: 放在 quality-inspection/ 下——会与入库放行审核混在一起，不符合业务分组。

D4: 详情聚合查询方式

选择: 后端一次性聚合查询，复用 build_outbound_pilot_context_by_schedule()。 理由: 入库放行审核的详情也是后端聚合（6个信息域）。复用已有函数减少重复代码，且一次请求减少前端多次调用。 备选: 前端多次调用已有 API 组装——增加请求次数，前端逻辑复杂。

D5: API 路径前缀

选择: 保持已有的 /web/admin/pilot-release-review 路径前缀。 理由: 后端 API 已注册在此路径下，保持一致性。

Risks / Trade-offs

• [风险] biz_outbound_release_review 表字段不完整 → 补充字段即可，已有数据不受影响（新字段为 NULL 安全）
• [风险] 聚合查询性能 → 按 infusion_schedule_id 查询（有索引），且单次排程关联数据量有限，性能可控
• [取舍] 审核不联动状态 → 简化实现，但用户需手动操作后续步骤。如需联动可在后续版本补充
• [取舍] 列表基于排程而非审核记录 → 列表数据更全面但查询稍复杂（需 LEFT JOIN）