hyb-oa/.trellis/tasks/09-02-reimbursement-readonly-content-consistency/prd.md

报销只读内容一致性与审批上下文收敛

Goal

让同一张报销单在 PC/移动、编辑/只读/审批和不同授权用户眼中保持同一份报销正文语义，同时把审批动作、审批历史和员工处理进度明确留在各自上下文中。补齐费用明细后的权威合计，避免审批人依赖页头回看或自行心算；在不复制内容、不引入第二业务金额来源的前提下保持 KISS。

Background and Confirmed Facts

• B-2b 已部署统一工作台并通过公网真实 bundle + 合成 API 验收；旧报销审批分支已经删除，当前父任务仍等待 AC11 真人重提反馈。
• PC/移动工作台头部均显示服务端 detail.totalAmount，但共享费用明细组件没有明细区合计；打印页已有“合计”行，也直接显示同一个 detail.totalAmount。
• 服务端 recomputeTotalAmount 在明细变化和提交链路按明细聚合重写 reimbursement_forms.total_amount；docs/报销发票附件规则.md 明确 PC、手机和打印页只展示服务端权威总额，不提供手工填写。
• 当前审批适配器把完整 timeline 注入主列末尾；PC 右栏只放审批决定，移动端历史也位于内容末尾。
• 普通报销详情使用 ProcessingProgress 回答“我的报销/付款走到哪一步”；审批任务使用 workflow timeline 回答“谁执行了什么动作、留下什么意见”。二者服务不同问题，不视为同一组件的视觉分叉。
• 当前打印页包含三类来源不同的信息：报销人申报的报销头/事由/明细/合计/票据，审批人或系统形成的审批记录，以及打印动作形成的二维码/打印人/打印时间。页面位置不能替代信息来源成为分类依据。

Scope

• 定义并验证报销正文、处理上下文和归档元数据的来源分类合同。
• 在统一工作台的 PC/移动明细区补充服务端权威合计，并建立仅用于完整性判断的共享状态。
• 将 PC 报销审批完整历史移入右栏动作之后且只保留一份；移动历史位置不变。
• 固化 ProcessingProgress 与 workflow timeline 的职责分工和一致性回归。
• 更新与上述行为直接冲突的产品体验事实和自动化验收；不改业务数据合同。

Product Requirements

R1 按信息来源划分正文、处理上下文和归档元数据

• 业务正文是报销人申报的内容：报销头、事由、费用明细、权威明细合计、票据与附件，以及由报销人申报的关联项目/差旅信息。PC/移动的 edit、readonly、approval 必须消费同一正文模型并逐字段一致。
• 处理上下文是审批人或系统对本次申报形成的判断与记录：提交时快照、费用标准/预算判断、票据金额证据状态、B2 检查、处理进度、审批历史和审批动作。上下文可以按模式和权限出现或省略；省略不构成正文不一致，但同一事实在不同模式出现时语义不得冲突。
• 归档元数据是打印动作形成的信息：二维码、打印时间和打印人。它只属于打印页，不进入交互工作台正文。
• 打印页是三类信息的组合交付视图，不再作为“页面内所有字段都是正文”的判据；字段归属只由来源决定。
• 布局可以响应设备变化：PC 合计使用语义表格 tfoot，移动端在明细卡片组末尾使用等价的“明细合计”汇总行；字段含义、金额来源和可访问名称必须一致。
• 模式只增加能力和上下文：edit 增加维护/提交能力，approval 增加快照、决策和 workflow 历史，readonly 不增加业务动作。不得为不同角色复制或重新计算正文。

R2 明细合计只展示服务端权威总额

• 明细区合计显示统一工作台模型中的服务端 totalAmount，不得在 PC 表格、移动卡片或各页面用 items.reduce() 生成可展示的第二总额。
• 若实现完整性核对，明细派生和权威总额只能在共享模型构建边界比较一次；派生值仅用于判断完整性，不得作为报销金额展示或提交。
• 不一致不是正常业务“差额”，必须显示为数据完整性故障，文案明确为“报销总额与明细汇总不一致，请联系管理员”，并阻止审批动作；不得暗示用户可手工修正总额。
• 明细金额无法安全解析时不得伪造差额；应明确提示无法完整核对并按既有关键内容未就绪合同阻止审批动作。
• 金额比较必须使用十进制定点/分值口径，不能使用二进制浮点直接累加。

R3 审批历史在 PC 右栏只保留一份

• PC approval 将完整 workflow 处理历史移到右侧审批上下文，位于审批动作之后；主列不再重复 timeline。
• 历史条目保留动作、处理人、时间和完整意见；正常短流程不新增“历史摘要 + 完整历史”双层表达。
• 历史增长不得把主要审批动作挤出可达区域；右栏的 sticky、滚动和长意见折行策略在设计阶段明确，并覆盖 1280px 与长退回意见。
• 移动端不复制 PC 右栏，完整历史继续位于正文之后、底部动作之前或安全区动作之前的既有阅读顺序。

R4 处理进度与处理历史明确分工

• ProcessingProgress 保留在普通报销详情，回答员工“当前走到哪一步、付款到哪一步”，并继续提供唯一付款批次入口。
• workflow timeline 保留在审批任务，回答审批人“谁处理过、执行了什么动作、留下什么意见”。
• 两者可以使用不同视觉结构，但动作名称、人员、时间和状态含义不得互相矛盾；本任务不强行合并为一个组件。

R5 先改进，再由 AC11 完成业务验收

• 用户决定不再以 AC11 真人反馈作为本子任务的实施前置；本规划经最新评审明确批准后即可 task.py start。
• 本子任务只改变已冻结的合计、历史位置和上下文表达，不借“先改进”继续扩充范围；commit、push、部署仍分别等待明确批准。
• 父任务 AC11 仍是最终业务验收：部署后至少记录一次员工真实重提与一次财务真实复审，核对员工提示、正文一致性、明细合计、PC 历史位置和进度/历史理解。
• 真人反馈若推翻已上线行为，必须作为新事实回到规划，不以现场猜测直接改代码；在 AC11 完成前不得归档父任务。

R6 不扩展业务与数据范围

• 不修改 schema、migration、B1/B2、费用类型、workflow 状态机、材料权限或生产数据。
• 不操作 0016/0017/0018；它们仍用于父任务 AC11 的真人反馈。
• 不借本任务处理部署脚本、.gitignore、错误色 token、AGENTS skill 名称或其他治理债。

Acceptance Criteria

• AC1：同一合成报销数据在 PC/移动 edit、readonly、approval 中的报销头、事由、明细、合计、票据/附件和申报关联信息逐字段一致；差异仅来自已批准的能力与处理上下文。
• AC2：PC 费用明细表使用 tfoot 显示“明细合计 + 服务端权威总额”；移动卡片组末尾显示语义等价汇总。三模式、不同用户均从同一工作台模型取值。
• AC3：代码与静态检查证明 PC/移动明细组件不存在用于展示总额的 items.reduce() 或页面级金额汇总；展示金额与页头、打印页使用同一 totalAmount。
• AC4：mismatch 与金额不可解析 fixture 分别触发准确故障提示并使报销审批 fail-closed；正常 fixture 不显示差额或“0 条”说明。
• AC5：PC approval 的完整历史只在右栏出现一次且位于动作之后；主列 timeline 为 0。1280px、长意见和 6 条历史下动作可达、页面无横向溢出。
• AC6：移动 approval 的历史仍在正文末尾，底部动作不遮挡；375px 与横屏无横向溢出，触控目标不小于 44×44。
• AC7：普通详情继续使用 ProcessingProgress，审批继续使用 workflow timeline；付款批次入口仍只有一处，二者没有状态/动作语义冲突。测试明确证明票据本体属于正文，而票据金额证据状态属于可按模式展示的上下文。
• AC8：edit 维护能力、readonly 零维护能力、approval 零报销维护能力和 B2 未归属恢复均无回归。
• AC9：打印视图继续显示服务端权威合计且不获得工作台 mutation；二维码、打印人和打印时间不进入交互工作台，审批记录不被误纳入三模式正文一致性断言。
• AC10：无 schema、migration、flag、seed 或生产数据写入；通过 typecheck/build、相关 Playwright、UI strict/self-test、Trellis governance 和 git diff --check。
• AC11：本子任务部署后，父任务记录员工真实重提和财务真实复审反馈；反馈未完成不阻止本子任务实施，但继续阻止父任务归档。

Test Plan

• 共享模型：严格十进制金额解析、权威总额透传、正常一致、mismatch、金额不可解析和空明细边界。
• PC/移动组件：tfoot/移动汇总行、三模式逐字段一致、编辑操作列 colspan、正常无解释、完整性故障可访问文案。
• 审批行为：完整性故障四动作 fail-closed；PC 历史单一右栏位置、长意见与 6 条记录；移动历史和安全区动作不遮挡。
• 上下文一致性：同一 fixture 对照 ProcessingProgress 与 workflow timeline 的已发生事件；未来付款阶段只出现在进度模型，付款批次入口唯一。
• 回归：edit/readonly/approval capability、B2 未归属恢复、打印视图、移动离线缓存、非报销 workflow。
• 视觉与可访问性：1280px、375px、移动横屏，无页面级横向溢出；语义表格、键盘顺序、非颜色单一表达和 44×44 触控目标。
• 工程门禁：typecheck/build、相关 Playwright、UI strict/self-test、Trellis task validate/governance、process contract、docs registry、敏感内容检查和 git diff --check。

Out of Scope

• 合并 ProcessingProgress 与 workflow timeline，或重做付款流程。
• 重新设计整张打印页、改变打印字段或归档政策；仅把它作为内容口径证据并保持回归。
• 在取得 AC11 反馈前据此宣称真人体验问题已经解决或归档父任务。
• 其他非报销 workflow 页面和历史债务。