hyb-oa/.trellis/tasks/09-01-reimbursement-approval-content-workbench/prd.md

B-2a 报销审批内容工作台

Goal

先把主管和财务每天真实使用的报销审批页改成可独立完成核验与决策的一页式工作台，并产出后续填写态必须采用的共享“明细 + 票据”组件合同。

Scope

• PC WorkflowTaskDetailPage 和移动 MobileApprovalsPage 的报销任务详情。
• 一个 PC/移动共用、审批/填写可迁移的报销明细证据组件。
• 提交时费用标准/预算快照与当前票据事实的分层投影。
• 票据/附件原件查看、材料合并预览入口、行内风险提示和审批动作布局。
• 从具体明细或票据引用到现有退回意见的轻量交互。
• 为新提交 workflow 补充最小预算快照；无 Prisma schema 或 migration。

Requirements

R1 首屏按决策顺序组织

PC 主列顺序固定为：

1. 报销摘要与事由；
2. 当前报销明细及所属票据；
3. 未归属票据与补充附件；
4. 提交时检查与当前票据检查；
5. 处理历史。

PC 右侧 sticky 区固定为：状态与当前节点、报销合计、合并检查摘要、审批意见、通过/退回/驳回/更多。提交快照与当前票据事实只有不一致时才拆出差异提示。完整审批流和处理历史始终放在主列证据之后。

PC 只保留这一处动作面板：通过为主按钮，退回、驳回为紧凑次操作，转审进入“更多”，不得在主列底部重复按钮或把动作竖向铺成卡片。窄屏降单列时，同一动作面板转到底部；移动端采用单列内容和底部单一主操作。

R2 明细和票据必须同屏对应

• 每条明细显示费用类型、发生日期、金额、说明、assets 事前批准依据（如有）和所属票据。
• 票据显示员工可理解的名称、日期、票面金额、状态和原件入口；不显示内部字段名或禁用术语。
• linkedItemId=null 的票据进入醒目的“尚未对应明细”分组，不隐藏在整单材料列表中。
• 补充附件作为整单证据单独展示，不伪造与某条明细的结构化关系。
• “打开完整原始表单/打印视图”作为次要入口保留，不得替代上述内容。

R3 两类检查不能混用

• workflowInstance.contextData.standardViolations 作为费用标准提交快照，按 itemId 就近映射。
• 新提交把已经计算的 budgetCheck 以最小字段集写入 workflow context；审批端只读该快照。历史无快照时明确显示缺失，不调用实时预算结果冒充。
• 当前票据归属、金额证据、人工核对状态和材料数量来自实时报销详情。
• 当前页面不主动调用受参与人/expense.view_all 保护的 precheck 来重算费用标准；不得放宽 precheck 授权。
• 办公用品达到既有阈值的非阻断提示由纯前端确定性规则直接就近显示。

R4 数据加载失败必须 fail closed

• workflow 任务摘要加载成功但实时报销内容加载失败时，页面显示可恢复错误和重试入口。
• 在完整报销内容、当前票据检查和提交快照解析完成前，报销审批的通过、退回、驳回和审批草稿均不可执行；不得误称已经核验完整内容。
• 单张票据原件加载失败只阻断该证据查看并给出重试/打开完整表单退路，不使整个页面崩溃。

R5 退回定位复用自由文本合同

• 每条明细和每张票据可触发“引用到退回意见”，生成稳定、无 UUID 的员工可读引用。
• 多个引用可以合并到同一退回意见；审批人仍可自由补充说明。
• 实际提交仍调用现有退回接口和 comment 字段；不新增后端 reason 结构。

R6 PC/移动与权限一致

• 当前审批人和具备既有查看资格的用户只读核验报销内容，不获得任何报销人维护动作。
• PC 与移动端使用同一内容组件和数据分层函数；页面容器只负责导航、响应式布局及审批动作。
• 发票/附件预览继续执行现有权限、用途、审计和短时 URL 合同。
• 已处理任务仍可查看当前报销内容，但必须提示“当前版本可能包含退回后修改”；历史审批意见和提交时检查保持各自历史语义。

R7 移动可访问性与操作层级

• 底部只保留一个主操作；退回、驳回、转审进入明确的次级入口和确认流程。
• 所有证据入口和操作触控区域至少 44×44，键盘/读屏顺序与视觉顺序一致。
• 警告不能只靠红/黄颜色区分，必须有文本状态和处理影响；固定操作区不遮挡最后一项内容。

R8 移动离线缓存采用显式最小投影

• 报销审批必须联网加载完整明细与票据后才能通过、退回、驳回或保存审批草稿；离线时只显示摘要/历史和“需联网核对完整报销内容”的解释。
• cacheWorkflowTaskDetail 不得无条件持久化扩展后的整个 task detail。缓存写入前必须构造允许字段子集，并明确排除报销明细、发票、附件、票面金额证据、材料 URL/访问参数和共享组件 projection。
• 测试必须直接读取 IndexedDB 的 workflow_task_cache 记录，断言禁存字段不存在；不能只断言离线按钮禁用。
• 非报销审批继续沿用当前离线草稿能力，避免本任务扩大为全审批离线重构。

Acceptance Criteria

• PC 报销审批详情不再只有四字段摘要；审批人无需跳转即可看到事由、全部明细、所属票据、未归属票据、附件、检查和历史。
• 移动报销审批详情提供同等业务内容，字段顺序与 PC 一致，无桌面表格和横向滚动。
• 明细、票据和提示按对象就近展示；standardViolations 和办公电子设备提示恢复到具体明细。
• 新提交 workflow 保存最小预算快照；历史无快照明确显示缺失，审批页不以实时预算替代。
• 票据关联和金额证据使用实时详情；退回补票/重绑后刷新即可看到最新事实。
• workflow 摘要成功而报销详情失败时，“通过”不可执行并提供重试，不退回四字段审批。
• 票据和附件可按既有授权查看；非参与审批人看不到编辑、删除、关联或解绑动作。
• 审批人可从明细/票据引用到自由文本退回意见，最终后端存储合同不变。
• PC 只有右侧单一 sticky 动作面板，主列底部无重复按钮；完整审批流/历史在主列靠后，动作横向紧凑且“转审”进入更多。移动底部操作在代表性视口不遮挡内容，状态不只靠颜色表达。
• 报销审批离线时所有决策/草稿入口不可用，IndexedDB workflow 缓存不含明细、票据、附件或材料证据；其他审批类型离线基线保持成功。
• 非报销审批详情、审批状态机、权限码、B2 门禁、付款和真实单据状态不变。

Out of Scope

• 把 PC/移动报销填写态迁入共享组件；该项属于 B-2b。
• 票据抽屉中的新增/编辑/拖拽、由票生成明细和填写态提交前检查改造。
• 结构化退回原因、数据库迁移和退回统计。
• 新增财务代员工编辑或纠正票据归属的写入口。
• 生产部署和真人数据验证。

Test Plan

• 后端：workflow 任务详情快照投影、提交时预算快照写入、历史缺失兼容、权限与状态零回归。
• 前端单元/组件：明细—票据分组、未归属票据、快照/实时标签、历史版本提示、引用退回意见、加载失败 fail closed。
• Playwright PC：从审批列表进入报销任务，直接查看明细/票据/附件，打开原件，引用退回意见，检查右侧 sticky 动作区。
• Playwright 移动：同一数据合同、底部主操作、次级动作、44px 触控区、无横向溢出、固定区不遮挡；在线加载前/离线时不能形成报销审批动作或草稿。
• 离线存储：在线打开合成报销审批后直接读取 workflow_task_cache，断言明细、票据、附件、金额证据和材料访问字段未持久化；非报销审批离线草稿回归继续通过。
• 合成冲突用例：提交快照显示超标而当前实时票据已变化，断言两类信息都存在且标签正确。
• 权限用例：审批人可读证据但无报销维护动作；无权用户仍 403。
• 前端门禁：cd client && npm run typecheck && npm run build、聚焦 Playwright、node scripts/qa/check-ui-design-rules.mjs --strict、--self-test。
• 后端门禁：相关 Vitest、cd server && npm run prisma:validate、必要的 node --check。
• 治理：task validate、process contract、Trellis governance、敏感内容检查、git diff --check。