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

报销审批一页式工作台

Goal

让主管和财务在同一审批页面内完成“看报销内容—核明细与票据—识别风险—填写意见—作出审批决定”，不再把“查看报销单”外链作为取得核心报销内容的必经入口；同时建立可复用的“报销明细 + 所属票据”业务内容组件，并承诺在后续填写态迁移后消除历史布局分叉。

Background and Confirmed Facts

• PC WorkflowTaskDetailPage.tsx:302-305 的报销投影只有报销单号、金额、提交人和报销人，随后提供“查看报销单”外链；移动审批详情同样只有摘要和“查看完整报销单”。
• 完整报销详情已有实时明细、发票、附件、材料预览、票面金额证据和处理进度，但其布局以报销人填写/旧只读查看为中心，不按审批决策顺序组织。
• 审批页的 workflowInstance.contextData.standardViolations 是提交时冻结快照；报销详情、票据关联及金额证据来自当前报销实时读取。两者语义不同，不能互相替代。
• 报销提交事务已经计算 budgetCheck，但当前只写入提交响应，没有进入 workflow 快照；新提交若要让审批人看到提交时预算事实，需要补充 workflow context 快照合同。
• 非参与人只读投影任务已明确：审批/财务详情不主动请求参与人专用 precheck，行内费用标准提示由本任务恢复；不得为恢复提示而放宽 precheck 对象权限。
• 移动审批当前允许缓存任务摘要和离线保存通过/驳回草稿，但缓存不含完整报销明细与票据证据。
• 现有前端 spec 的“审批页只提供业务详情出口、不复制报销内容”是旧阶段的临时可达性合同，本任务批准实施后应被新的共享内容组件合同取代，而不是继续并存。
• 现有 docs/产品设计规则.md:73 已规定“证据居中、审批/处理历史靠后、当前动作面板固定在 PC 右侧或移动端底部”；归档统一设计评审还规定审批动作不得竖向铺成多个大卡片。当前报销审批页只有四字段和外链，未满足既有证据结构；本任务是回归既有规则，不另创页面范式。

Delivery Strategy

采用“先审批、后填写迁移”的 B 路线，并拆成两次可独立验收的交付：

1. B-2a 报销审批内容工作台：建立共享的“明细 + 所属票据”只读/核验组件，先接入 PC 和移动审批页；审批人无需跳转即可取得决策所需内容。
2. B-2b 报销填写态共享组件迁移：在 B-2a 真人使用反馈稳定后，把 PC/移动填写态迁移到同一组件，并完成票据抽屉、提交前检查和旧只读布局收口。

B-2a 完成时允许旧填写态暂时存在；B-2b 是本父任务的必交子任务，不得以“以后优化”关闭父任务。父任务只有在填写态迁移完成、旧重复内容布局被删除或明确退役后才能归档为完成。

Scope

• 父任务负责两阶段交付合同、共享组件边界、快照/实时数据口径、跨子任务验收和最终旧布局收口。
• B-2a 负责 PC/移动审批一页式内容工作台与共享组件 review/readonly 能力。
• B-2b 负责 PC/移动填写态迁移、票据抽屉、提交前检查和重复布局删除。
• 两个子任务分别形成候选、部署和回滚点；父任务不直接承载业务代码实施。

Product Requirements

R1 审批决策不再依赖二次跳转

• 报销审批详情直接展示报销事由、报销人/提交人、部门、日期、金额、明细、每条明细所属票据、未归属票据、补充附件、核验提示和审批历史。
• “查看报销单”降级为“打开完整原始表单/打印视图”的次要入口，用于少见的完整字段追溯，不再承担核心内容可达性。
• 非报销审批类型保持当前各自投影，本父任务不借机重构请假、采购、差旅或考勤审批。

R2 共享内容组件必须有明确迁移终点

• B-2a 建立的共享件以业务数据和交互能力为边界，不依赖 WorkflowTaskDetailPage 或审批状态；至少覆盖“明细 + 关联票据 + 行内核验提示”。
• PC 与移动审批使用同一语义组件和字段顺序，只允许响应式布局和操作容器不同。
• B-2b 必须让 PC/移动填写态采用同一组件；编辑、删除、关联等维护动作通过显式能力/回调注入，不复制一套填写专用展示结构。
• B-2b 完成后，不得继续保留“旧填写态、新审批态、旧只读态”三套并行布局。

R3 快照事实与实时事实分层展示

• 提交时快照：费用标准超标、预算提示及提交时形成的规则/风险结论。审批页面必须标注“提交时检查”，不得用当前 precheck 结果覆盖。
• 当前实时事实：报销头、明细、票据归属、票面金额证据、补充附件及当前可见的材料状态。审批页面必须标注“当前报销内容/当前票据检查”。
• 退回补票、重绑或重提后，当前内容可以变化；历史审批任务查看到当前版本时必须给出版本语义，不得把当前内容伪装为旧任务处理当时的原始快照。
• 历史 workflow 没有预算快照时显示“该次提交未记录预算快照”，不得回填或冒充当前预算结果。

R4 恢复审批人需要的行内提示

• standardViolations 按 itemId 回到对应明细旁显示，并明确控制模式和审批影响。
• 办公用品达到既有金额阈值时继续显示“通常应选择办公电子设备”的非阻断提示；不得把该阈值描述成会计固定资产标准。
• 票据未归属、需票明细缺票、票面金额需人工核对或金额不可用等当前事实，必须就近显示到具体明细或票据；系统不校验日期粒度或明细拆分正确性，页面不得暗示会自动判断。

R5 退回定位先解决可用性，不扩大数据模型

• B-2a 允许审批人从具体明细或票据发起“引用到退回意见”，生成员工可读的对象描述并带入现有自由文本意见。
• 本轮不新增退回原因分类表、结构化 reason schema、migration 或新的 workflow 状态；最终仍通过现有 comment 字段存储自由文本。
• 若后续真人使用证明需要统计型退回原因，再另建数据模型任务，不在 B-2a 顺手扩展。

R6 审批动作与证据可见性绑定

• PC 宽屏右侧 sticky 区只展示状态摘要、报销合计、合并后的检查摘要、审批意见与决策动作；完整审批流和处理历史放在主列证据之后。
• 提交时快照与当前票据事实默认合成一个短检查摘要，只有两者不一致时额外标出差异及时间语义，避免在窄栏并列两个难以区分的“检查摘要”。
• PC 只有右侧一个审批动作面板，不在主列底部复制第二套按钮；窄屏降为单列时，同一动作面板才转到底部。
• 通过为唯一主按钮，退回、驳回为紧凑次操作，转审默认进入“更多”；禁止把多个处理动作竖向铺成大卡片。
• 移动端按同一内容顺序单列展示，底部只保留一个主操作，退回、驳回和转审进入次级操作/确认流程；固定操作区不得遮挡内容。
• 报销内容或关键核验数据加载失败时，不得仍允许审批人基于四字段摘要直接通过。

R7 报销审批离线必须保护决策和证据

• 报销审批必须联网并成功加载完整明细、票据和关键检查后，才能通过、退回、驳回或保存审批草稿；离线摘要不得成为报销决策依据。
• cacheWorkflowTaskDetail 必须使用显式脱敏/允许字段投影，排除报销明细、票据证据、附件元数据和材料访问数据；不能依赖“当前 workflow DTO 尚未包含这些字段”作为安全边界。
• 其他审批类型维持现有离线能力，本任务不全局关闭移动审批离线草稿。
• 完整报销内容只保留在在线查询生命周期内，不为 B-2a 扩展 IndexedDB workflow cache；如未来需要离线报销审批，必须另行规划敏感数据缓存、过期、清除和设备边界。

Acceptance Criteria

• B-2a 和 B-2b 作为两个独立子任务存在，前者可单独上线产生完整业务价值，后者是父任务关闭前的强制迁移项。
• PC 与移动报销审批页无需跳转即可看到完整决策内容，并能打开票据原件和补充附件。
• 每条明细与所属票据在同一区域展示；未归属票据和行内提示可直接定位，不依赖页面顶部汇总猜测对象。
• 费用标准与预算使用提交时快照，票据关联与金额证据使用当前实时事实；页面文字明确区分两者。
• 历史缺少预算快照时不做实时替代；退回后内容变化时不把当前版本冒充旧提交快照。
• 非参与人只读权限、材料查看审计、审批状态机和 B2 票据门禁不因页面整合而放宽。
• B-2a 恢复明细行内费用标准提示和既有办公电子设备提示。
• 退回可以引用具体明细/票据到现有自由文本意见；本父任务不新增结构化退回原因数据模型。
• PC 只有右侧单一审批动作面板，完整流程/历史位于主列靠后；窄屏和移动才把同一动作面板转到底部，多个动作不竖向铺卡片。
• 报销审批离线时不能形成任何审批动作或草稿，且离线缓存中不存在明细、票据、附件或材料访问证据；其他审批类型离线合同不变。
• B-2b 完成后，填写态、审批态和只读态共享同一业务内容组件，不再保留三套漂移布局。
• 两次交付分别通过各自的前后端、PC/移动、无障碍、文案、权限和部署验证；生产部署与真人数据写入仍需单独批准。

Out of Scope

• 一次性同时重写审批态和填写态。
• 请假、采购、差旅申请、考勤等其他业务的审批内容重构。
• 结构化退回原因 schema、统计报表、数据库 migration。
• 修改审批角色、审批规则、状态机、B2 flag 或付款流程。
• 自动判断明细日期粒度、业务是否应拆分或费用是否真实合理。
• 操作或读取三张真人 rejected 报销单；其业务处理与本任务并行推进。
• 推送、部署、生产配置或生产数据写入。

Test Plan

• 分别执行 B-2a、B-2b PRD 的前后端、PC/移动、权限与部署验证。
• 父任务收口时验证共享组件确实被审批态、填写态和只读态复用，并检查旧重复布局已删除或退役。
• 运行父子三任务 task.py validate、process contract、Trellis governance、敏感内容检查和 git diff --check。
• 如同步业务事实源，再运行 docs registry；未经部署和公网检查，不通知用户测试。