记录四块式报销详情验证（07-27-yang-jun-reimbursement-readiness）

2026-08-01 12:38:04 +08:00
@@ -161,8 +161,8 @@

 - 后端继续用 ISO 8601 UTC 字符串传输时间，前端不得用 `slice(0, 19)` 假装本地时间。PC 报销详情、移动报销详情和 PC 审批任务详情复用 `formatDisplayDateTime`；共享函数显式使用 `Asia/Shanghai`，使公司内部 OA 不依赖浏览器所在时区。
 - 不新增页面级时间工具。合成 UTC 样例通过页面文本断言验证上海时间，覆盖附件上传时间和审批任务时间。
- PC 将“当前状态与下一步”和“业务摘要”收敛为单一首屏概况，保留总额、状态、编号、日期、报销人、说明与真正可执行入口；删除解释同一事实的二级标题和辅助句。
- PC 的明细、发票、附件各保留一个可扫描标题；附件上传限制只在可编辑时出现。关联事项仅在已有项目/差旅关联或可编辑时展示，预算/风险区域仅在存在真实提示时展示。
+- PC 将“当前状态与下一步”和“业务摘要”收敛为单一首屏概况，保留总额、状态、编号、日期、报销人、说明与真正可执行入口；差旅概要并入该单头，删除解释同一事实的二级标题和辅助句。
+- PC 与移动只保留单头概况、费用明细、报销材料、处理进度四个可扫描标题。附件上传限制只在可编辑时出现；关联事项作为单头行、预算/风险作为就近提示、付款作为进度节点次级事实，均不形成永久空区域。
 - 移动端头部已经包含状态，因此概况卡不重复状态；只保留金额、日期、报销人和说明。只读状态不显示编辑教学或空“操作”卡，编辑态仍保留新增、上传、删除和底部提交能力。
 - 采用当前设计系统和现有组件，不引入新颜色、字体、动效、布局系统或后端字段；新版 `ui-ux-pro-max` 仅用于内容优先、密度和渐进披露判断。

@@ -206,7 +206,7 @@
 ## 12. 报销明细与材料的 KISS 对齐

 - 交互采用“一个入口、一次通览、语义保留”：费用明细只展示费用事实，不再渲染关联发票；`linkedItemId`、票据/附件类型、对象权限、审计和生命周期均不改变。付款回单仍属于付款阶段材料，不提前混入本次提交材料。
- 报销材料只读态首屏显示“发票 N · 补充附件 M”和一个明确的“查看材料合并预览”按钮，不为每份文件重复暴露技术操作。草稿/驳回编辑态仍保留发票添加/移除和附件上传/删除所需列表，数据变更动作与只读通览分离。
+- 报销材料首屏显示“发票 N · 补充附件 M”和一个明确的“查看材料合并预览”按钮，下方始终显示有序原件列表。每份材料只使用一个语义化整行按钮打开原件，不再叠加“查看”按钮；草稿/驳回编辑态在同一行外保留发票移除和附件删除动作，只读审批人不显示数据变更动作。
 - 服务端新增报销级合并 PDF grant：授权后读取当前绑定的发票 PDF 与补充附件，PDF 原页全部复制，JPG/PNG/WebP 经 Sharp 规范化后各嵌入一页。企微调用一次 `previewFile({ url, name, size })`，PC/普通浏览器打开同一短时 PDF URL；不引入 PDF.js，不在客户端渲染 PDF。
 - 预览顺序固定为发票 `created_at, id`、补充附件 `created_at, id`、PDF 内页顺序；不根据 `linkedItemId`、金额或文件名猜测排序。有序材料集合哈希覆盖材料类型、ID、文件哈希/大小/MIME，缓存键由报销单 ID、集合哈希和合并器版本组成。
 - 合并在 Node `worker_threads` 中执行，不启用 Compose worker profile。worker 限制材料数、源文件总字节、PDF 总页数、图片像素、输出字节和执行时间；`pdf-lib` 不使用 `ignoreEncryption`，加密、损坏或不可复制 PDF 导致整包失败。任一材料失败都不能跳过，客户端展开现有逐份原件路径。
@@ -246,10 +246,45 @@
 - 差旅单判定使用“任一明细的 `expenseType.category === travel`”或存在关联差旅申请，不新建另一套报销类型字典。
 - 关联差旅申请时，概要可从已批准申请的 purpose、segments 城市、start/end date 读取；普通差旅报销使用自身四字段。历史数据只读降级为“description 作事由、明细最小/最大日期作起止日”，地点缺失如实显示，禁止从文件名、OCR 金额或自由文本猜地点。
 - 四字段只允许申请人/受权代办在 `draft/rejected` 更改。审批中单不原地改业务事实；当前真实单如需完整地点，必须由主管退回后申请人补齐并重新提交。
- 详情页把“差旅概要”置于金额/报销人概况之后、费用明细之前；只有差旅单显示，不让普通费用报销承担空字段。
+- 详情页把差旅概要并入金额/报销人所在的单头概况；只有差旅单显示差旅行，不让普通费用报销承担空字段或独立空卡。
+- 共享 `ReimbursementTravelSummary` 以“可编辑且概要不完整”作为初始填写态条件，直接呈现四个可见标签输入框；保存成功后切回摘要态，保存失败停留在表单并显示现有错误反馈。完整概要仍由用户点击“编辑”进入表单，不引入新的步骤、弹窗或报销类型。

-### 13.4 验证与回退
+### 13.4 四块式 KISS 交互边界
+
+- 材料列表与合并预览复用现有单份签名 URL、企微 `previewFile`、PC 打开方式、下载理由、权限和审计；本轮只移除只读态的列表可见性条件，不增加后端接口。
+- 列表顺序沿用详情 API 的发票、补充附件顺序；不按金额、文件名或关联明细重新排序。稳定 ID 作为 React key，整行按钮保留可见焦点和至少 44px 触控高度。
+- PC/移动沿用现有详情路由和返回路径，只重排当前内容为四块纯滚动；不做 Tab、折叠、抽屉、普通/差旅二选一、费用日期交叉校验、补助自动计算或审批页重构。
+- 真实风险以内联提示贴近单头/明细，关联项目或差旅申请以单头一行链接呈现；草稿/驳回动作留在页面底部命令区，均不计入稳定内容块。
+
+### 13.5 五阶段处理进度 DTO
+
+`GET /api/reimbursements/:id` 新增只读 `processingProgress`：
+
+```text
+processingProgress.stages[] = {
+  key,
+  label,
+  state,          // completed | current | pending | exception
+  actorName?,
+  occurredAt?,
+  result?,
+  comment?,
+  detail?,
+  targetHref?
+}
+```
+
+- 服务端始终生成“申请提交、主管审批、财务复核、付款批次复核、付款与回单”五个业务阶段。workflow 阶段按提交快照的职责节点映射；不暴露内部 step ID、角色码或权限码。
+- workflow task 提供实际 assignee/completer/outcome，history 提供动作、意见和时间。已完成取实际 completer/actor，当前取真实 pending assignee；未来 task 尚未创建时 `actorName=null`，严禁按当前角色持有人猜姓名。
+- 付款汇总读取与当前报销关联的最新 `PaymentBatchItem` 及其 batch，只选择状态、制单/复核/执行人员与时间和未归档回单计数，不返回批次其他报销、金额或材料。只有具备现有付款批次读取权限时才返回可跳转的 batch href。
+- 没有批次时付款复核 detail 为“待财务创建付款批次”；draft 为“所在付款批次待非制单人复核”；reviewed 为“所在付款批次已复核，待执行付款”；failed/cancelled 如实表达失败或待重新创建。不得写成“您的报销待复核”。
+- `paid` 后最后阶段完成；回单计数为 0 显示“付款已完成，回单待留存”，大于 0 显示“付款与回单已留存”。回单是最后阶段次级状态，不增加第六块。
+- workflow、batch、receipt 三个来源分别 try/normalize；合法缺失不是错误，缺失来源只让对应及下游阶段保持 pending。数据库或映射异常仍按现有 5xx 处理并记录服务端错误，不用伪造“已完成”。
+- PC 与移动复用一个时间轴组件。已完成无意见节点压成单行；当前、exception、returned/rejected 或有 comment 的节点展开。语义状态同时使用图标/文字/线条，不只依赖颜色。
+
+### 13.6 验证与回退

 - 后端覆盖迁移、PATCH/GET/submit 字段合同、日期倒置、非差旅报销不误拦截、关联差旅申请摘要与旧单降级。
- 前端覆盖 PC/移动概要顺序、草稿编辑、审批中只读、按钮归位、加载反馈、JPEG 类型、企微有序 URL 和 375px/横屏。
+- 后端补充五阶段 DTO 的 pending/approved/paid、退回/驳回、batch 五种状态、回单有无、三个来源独立缺失、未来节点无姓名和付款链接权限测试。
+- 前端覆盖 PC/移动四块顺序、单头差旅填写/只读、材料列表与合并入口、五阶段紧凑时间轴、加载反馈、企微原件预览和 375px/横屏。
 - 若 JPEG/并发修复未通过目标镜像与合成火车票验收，回滚应用代码到现有 PNG 串行路径，保留原件降级；不删生产数据或回滚整库。
@@ -213,8 +213,22 @@
 - [x] 以单一 Serializable 数据库事务补录用户确认的事由、地点和起止日期，并只把上述唯一错误火车票明细日期改为确认后的实际乘车日期；未改金额、费用类型、说明、票据、附件、审批状态、工作流实例或待办。
 - [x] 同事务新增 1 条管理员代录审计，只记录“字段于提交后上线、原提交未采集、业务方确认后代录”的原因、被修正字段名和受控 task 标识；未把真实事由、地点、日期、票据或原始请求写入 task 证据或审计 extra。
 - [x] 写后只读断言通过：差旅概要四项完整、5 条 travel 明细日期全部位于确认区间、金额与 3 张发票和 3 个附件保持不变、工作流与当前待办仍为原 pending 状态、目标审计恰好新增 1 条；事务结果为 `applied`，未触发回滚。
+- [x] 用户刷新当前真实报销后确认页面日期显示正确；该结果只证明日期展示，不代替差旅概要其他字段、材料列表或真实审批结果。
 - [ ] 补录不代表审批通过；马建勇仍须按业务事实完成主管审批，后续财务、付款批次、银行回单和最终复核继续遵守既有流程。

+## 6.16 四块式详情与五阶段处理进度
+
+- [x] PC 与移动端移除只读态材料列表的权限/失败条件，所有有权查看当前报销的人始终看到发票与补充附件列表；合并预览保留在列表上方。
+- [x] 单份材料继续使用现有整行按钮和单份预览路径；只读审批人没有移除、删除或管理动作，编辑态既有动作保持不变。
+- [x] PC/移动详情重排为“单头概况 → 费用明细 → 报销材料 → 处理进度”四块；差旅概要并入单头，关联/风险/付款/操作按数据与权限就近显示，不增加 Tab 或折叠。
+- [x] 共享差旅概要组件在“草稿/驳回可编辑且字段不完整”时直接进入四字段填写态；完整概要保持单头内摘要 + 编辑，不新增报销类型或字段合同。
+- [x] 后端详情新增五阶段 `processingProgress`，从 latest workflow snapshot/tasks/history、关联 PaymentBatchItem/batch、报销付款字段和回单计数生成；不改 schema、workflow 或 PaymentBatch 状态机。
+- [x] 固化未来节点无姓名、共享批次措辞、maker-checker 各状态、回单次级状态、付款链接权限和三源独立缺失降级；返回中不包含批次其他单据、金额或材料。
+- [x] PC/移动复用紧凑纵向时间轴：已完成无意见节点单行，当前/异常/有意见节点展开；不显示“第 N 步”、内部 step ID、角色码或权限码。
+- [x] 更新后端聚焦测试与 PC/移动 Playwright，覆盖五阶段、退回/驳回、batch 状态、回单、来源缺失、未来无姓名、材料单份/合并、编辑权限、四块顺序、44px 触控和横屏无溢出。
+- [x] 运行 Prisma validate、touched-file `node --check`、server 聚焦/必要全量、client typecheck/build、聚焦 Playwright、task/Trellis/process/docs/sensitive/diff 门禁；只读 review 跨 workflow/付款状态映射与权限，不让 reviewer 改代码。
+- [ ] 实现完成后分别申请提交、推送和生产部署批准；部署与公网检查通过前不通知真人测试，不执行真实审批、付款或回单写入。
+
 ## 7. 完成条件

 - [ ] PRD 全部验收项有脱敏证据或明确由用户完成的真实业务验收结果。
@@ -296,3 +310,9 @@
 - 数据合同验证：Prisma schema 通过；63 个 migration 在临时空 PostgreSQL 16 数据库完整 apply；新迁移只增加四个 nullable 差旅概要列，未回填或改写真实审批中数据。
 - 最终质量：server 全量 171 个文件、1114 项通过；client typecheck/生产 build 通过；task、Trellis governance、process contract、敏感扫描和 `git diff --check` 通过。文档审计 0 error、1 条既有汇总 warning（22 个历史未登记文件）。
 - 发布后运维对齐：automatic backup 三项与 WARCH3 共 4 个 service 均匹配 `8a9279e`，4 个 timer 均 enabled/active；新 automatic backup daily 与源端 watchdog 均为 `success/0`。
+- 四块式详情实现：PC/移动均收敛为“单头概况 → 报销明细 → 报销材料 → 处理进度”；差旅概要、关联事项和真实风险并入单头，材料列表对只读审批人常显，单份与合并预览沿用既有权限和审计路径。
+- 五阶段只读投影：详情 API 固定返回申请提交、主管审批、财务复核、付款批次复核、付款与回单；付款批次未创建时可明确显示“待财务创建付款批次”，未来处理人不预填，普通申请人不获得批次跳转或批次其他业务信息。
+- 五阶段验证：后端最新聚焦 12 项覆盖草稿、审批中、退回/驳回、批次 draft/reviewed/executed/failed/cancelled、回单有无、无批次历史付款和批次链接权限；服务端全量基线 171 个文件、1123 项通过。Prisma validate 与 touched route `node --check` 通过。
+- 双端验证：client typecheck/生产 build 通过；R111 PC/企微 2/2、Wave3 只读详情 1/1 及移动视觉聚焦 2/2 通过，覆盖材料常显、只读无删除、四块顺序、五阶段无“第 N 步”、44px 触控和无横向溢出。视觉复核确认 PC 主内容不再因空侧栏过窄。
+- 只读 review：按 workflow task、PaymentBatchItem/batch、回单计数三源逐项复核映射与权限；修正“workflow 已通过但尚未建批次”原本无当前节点的问题，使其明确落在“待财务创建付款批次”。确认未来 checker 不预填、普通申请人无批次链接、共享批次不暴露其他单据/金额/材料；review 未修改状态机、权限矩阵或生产数据。
+- 最终治理：task validate、Trellis governance、process contract、敏感扫描和 `git diff --check` 通过；文档审计 0 error、1 条既有汇总 warning（22 个历史未登记文件）。本步骤未部署、未推送、未修改生产配置、真实报销状态、付款批次、回单或业务数据。
@@ -38,7 +38,7 @@
 - 当前小团队取消报销金额分层，所有金额统一按“直属主管 → finance”审批；不得保留无人持有的 `finance_mgr` 节点，也不得因马建勇同时是主管和 CEO 而让同一人重复审批。
 - 真实首笔报销暴露审批可读性阻断：待办列表卡片能够进入审批任务详情，但任务详情只显示单号、申请人和金额摘要，没有通往费用明细、发票和附件的业务详情入口。移动端必须在审批任务详情区提供明确的“查看完整报销单”入口，复用既有 `/mobile/reimbursements/:id` 路由和 `state.from` 回跳约定；PC 审批任务详情同步提供报销单入口。
 - 报销详情当前把后端 ISO UTC 时间直接截取为字符串，附件和审批记录会在中国时区显示早 8 小时；报销链路的日期时间必须复用共享格式化能力并固定按 `Asia/Shanghai` 展示，不修改数据库时间或 API ISO 合同。
- PC 与移动报销详情应按 KISS 原则收敛为“概况 → 明细 → 发票 → 附件 → 审批记录”的业务主线：删除重复状态、重复标题和面向只读用户的操作教学；没有实际内容或动作的辅助区块不渲染，同时保留编辑态必要控件、风险提示和审计信息。
+- PC 与移动报销详情应按 KISS 原则收敛为四个稳定内容块：“单头概况 → 费用明细 → 报销材料 → 处理进度”。差旅事由、地点和起止日期并入单头，不保留独立差旅卡；项目/差旅申请关联、真实风险和付款事实仅在存在时作为相邻行或节点次级信息显示。页面纯纵向滚动，不增加 Tab、折叠或抽屉，同时保留编辑态必要控件、风险提示和审计信息。
 - 生产真机验收确认企微 WebView 可继续运行部署前的旧前端包：公网资源已包含“查看完整报销单”，但存活页面仍只显示报销日期。页面从后台恢复到前台时必须用现有前后端构建标识做一次轻量比对；不一致时只显示用户可控的“发现新版本，点击刷新”，点击后清理旧 PWA 缓存并重载，不自动打断当前页面操作，不扩展为完整更新管理系统。
 - 真实审批继续暴露材料查看阻断：PC 能打开普通附件，但 PC 与移动报销详情均没有发票原件入口，企微 WebView 中异步 `window.open(blob:)` 只下载附件而不能预览。企业微信自建应用内必须优先使用官方 `ww.previewFile` / `wx.previewFile` 原生能力查看 PDF；普通 PC 浏览器保留浏览器预览，两端保持“查看原件”的业务能力一致。
 - 生产验收发现移动报销列表固定请求 `scope=own`，导致已有 `expense.view_all` 的管理员无法在企微工作台找到杨俊的报销单并代为验证原生预览。移动端必须与 PC 的范围能力对齐：仅对 `expense.view_all` 用户显示“我的 / 全部”切换，默认仍为“我的”，选择“全部”时复用现有 `scope=all` API；普通员工不显示范围切换，不修改后端权限模型。
@@ -50,6 +50,10 @@
 - 生产只读计时确认当前图片包串行处理约 1.8 秒，且火车票栅格图在企微中视觉上近似空白。新主路径不得继续现场栅格化 PDF；合并由 Node `worker_threads` 执行并设置材料数、源文件字节、总页数、输出大小和超时上限，避免阻塞单一 server 的事件循环。不启用 Compose worker profile，不引入 PDF.js。
 - 合并产物必须可重复生成：材料查询使用显式排序键，缓存键包含报销单 ID、有序材料集合哈希与合并器版本；PDF 元数据和保存选项固定。同样输入独立生成两次必须字节完全相同。签发返回的 `fileSize` 与实际 GET 返回的缓存字节严格一致；缓存缺失或进程重启不能临时拼出另一份字节冒充原签发产物，只能拒绝并让客户端重新签发或降级原件。
 - 当前真实报销为“空白报销”创建且未关联差旅申请，现有数据模型没有独立的出差事由、地点和起止日期，因此详情页无法显示完整差旅概要。轻量差旅报销必须直接持久化这四项可选业务字段；存在任一差旅费用明细时，草稿/驳回态提交前必须补齐。既有审批中单据不自动伪造或回填地点；可以只读显示报销说明和明细日期的明确降级值，需完整补齐时由主管退回后申请人修改。
+- KISS 复核确认只读审批人仍需要知道本单有哪些原始材料。PC 与移动端“报销材料”区必须始终显示有序材料列表，整行点击只预览该份原件；“查看材料合并预览”保留为列表上方的一次通览动作。只读审批人不得看到移除、删除或票据池管理动作，费用明细仍不重复展示发票。
+- 草稿/驳回报销出现差旅类明细且四项差旅概要不完整时，PC 与移动端应直接显示带标签的填写表单，不先展示四个“未填写”再要求用户点击编辑；概要完整后恢复紧凑只读摘要并保留编辑入口。不新增“普通/差旅”选择，不改变现有字段、差旅判定、提交校验或差旅申请关联规则。
+- “处理进度”必须使用移动端友好的纵向时间轴，固定表达五个业务阶段：申请提交、主管审批、财务复核、付款批次复核、付款与回单。节点名使用职责而非序号；已完成节点显示实际处理人/时间/结果，当前节点显示实际待办人（可取得时），未来节点不得预填姓名。退回、驳回和有内容的意见必须展开，普通已完成节点压成一行。
+- 五阶段是跨状态机只读投影，不把付款批次塞入 workflow。服务端从 workflow 快照/任务/历史、报销付款字段、当前关联付款批次和回单计数生成安全 DTO；任一来源缺失时仅把对应下游节点降级为“待处理”，前面已完成节点继续返回。付款批次为共享对象，节点文案必须写“所在付款批次…”，不能暗示单张报销自身再次被审批。

 ## Scope

@@ -93,6 +97,11 @@
 - [x] 合并在 `worker_threads` 中受限执行；同样输入生成两次字节完全相同，签发 `fileSize` 等于 GET 实际字节，缓存丢失不返回漂移产物。
 - [x] 用无业务数据的多页 PDF 与 JPG/PNG/WebP 合成样本验证页数、顺序、25 页边界和企微一次 `previewFile`；加密、损坏或不可复制 PDF 必须整包失败并回退逐份原件。
 - [x] 存在差旅费用明细时，PC/移动详情首部均显示“出差事由、出差地点、起止日期”的轻量概要；草稿/驳回态可编辑且提交校验完整，审批中历史单不伪造缺失字段。
+- [x] PC 与移动端只读报销详情始终显示有序材料列表；列表上方保留合并预览，点击单行仅预览对应原件，审批人没有编辑/解绑/删除动作。
+- [x] 草稿/驳回差旅报销的概要不完整时直接进入四字段填写态；完整后显示紧凑摘要与编辑入口，普通报销不显示差旅字段。
+- [x] PC 与移动报销详情只保留四个稳定内容块；差旅概要并入单头，关联、风险、付款和操作均按数据/权限条件呈现，不形成永久空版块，不增加 Tab 或折叠。
+- [x] “处理进度”按五阶段纵向显示，不出现“第 N 步”；当前责任、实际处理人、时间、结果及必要意见清楚，未来节点无姓名，付款批次共享语义准确。
+- [x] workflow、付款批次或回单任一来源缺失时进度 DTO 和页面均安全降级，已知节点不丢失；批次 draft/reviewed/executed/failed/cancelled 与回单有/无均有合成回归。

 ## Out of Scope

@@ -117,3 +126,7 @@
 - 用合成企微 ticket、签名 URL 和 PDF/图片元数据验证：JS-SDK URL 签名、origin allowlist、原生 `previewFile` 参数、PC fallback、审批人对象级只读授权、附件理由门禁、短时 token 过期/篡改拒绝和实际查看审计；不得使用真实发票或附件。
 - 用合成管理员与普通员工权限验证移动报销范围：管理员默认请求 `scope=own`，切换后请求 `scope=all` 并显示他人报销；普通员工不显示“全部”且始终请求 `scope=own`。
 - 用合成普通增值税发票、数电发票、电子火车票、多页 PDF 与 JPG/PNG/WebP 补充附件验证 PC/移动一致性：费用明细无发票预览；票种标题不虚构缺失字段；统一材料区计数正确；合并 PDF 包含全部材料并保持顺序；异常/加密 PDF、超限和合并失败可安全降级；编辑态管理动作不回归。
+- 用合成申请人、审批人和管理员权限覆盖 PC/移动材料区：列表始终可见且顺序稳定，语义化整行按钮可单份预览，合并预览仍只调用一次，只有可编辑参与人看到移除/删除动作。
+- 用合成普通与差旅草稿覆盖 PC/移动概要：无差旅明细时不显示；差旅概要不完整时直接显示四个有标签输入框；保存中、成功和失败有反馈；完整后回到摘要态。
+- 后端用合成 workflow task/history、付款批次 item 和回单计数覆盖五阶段只读 DTO：当前/完成/未来节点、退回/驳回意见、maker-checker、共享批次措辞、每个来源单独缺失和权限安全摘要；不写生产业务数据。
+- 前端用同一 DTO 覆盖 PC/企微纵向时间轴：已完成节点单行、当前/异常节点展开、无“第 N 步”、未来无姓名、付款批次共享措辞和四块式纯滚动布局。
@@ -0,0 +1,94 @@
+# 国内报销详情页 KISS 调研
+
+## 1. 调研问题
+
+面向 10 人以下国内科技公司，报销详情页是否需要把概况、差旅概要、费用明细、材料、关联事项、风险、审批、付款和操作拆成多个常驻区域；如果不需要，最小但完整的信息结构是什么。
+
+## 2. 公开资料结论
+
+- 合思公开产品资料覆盖申请、消费、报销、对账、记账、归档、报表，并强调票据识别、费用可追踪和审核；这些是全链路能力域，不等于单据详情页需要常驻同等数量的版块。
+- 汇联易公开产品资料强调费用管理、合规规则、发票管理、智能审核、会计与流程能力；其复杂预算、风险和核算能力面向中大型企业，不应直接成为本项目小团队详情页的默认结构。
+- 每刻报销公开产品资料强调出差申请、费用、发票、审核、支付和归档，并明确其相对传统 OA 的优势来自预算、智能审核、ERP 和银企集成；本项目当前没有这些真实配置或集成，不能为了“像费控系统”而展示空区域。
+- 人人都是产品经理的费控设计案例把差旅移动流程概括为事项申请、发票采集、场景报销、领导审批和财务审核，并指出不同费用类型应使用动态单据模板和附件清单。可复用原则是“按业务事实动态展示”，不是固定堆叠所有能力域。
+
+## 3. 项目现状
+
+- 移动报销详情当前至少有：报销概况、独立差旅概要、报销明细、报销材料、审批、操作。
+- PC 详情除上述主线外，还可能出现关联事项、预算与审核提示、付款状态和更多操作；多数已按数据条件隐藏，但差旅概要仍形成独立卡片。
+- 当前公司费用标准和预算没有形成真实常用数据；风险区没有内容时本来就不显示。审批动作在审批任务页，普通业务详情不应复制审批动作。
+- 当前真实单据规模小，适合单页纵向滚动；Tab、折叠和二级抽屉只会增加企微 WebView 的状态与返回验证成本。
+
+## 4. 推荐结构
+
+只保留四个稳定内容块，PC 与移动端信息顺序一致：
+
+1. **单头概况**：单号、状态、申请人、部门、总额、说明；差旅单把事由、地点和起止日期并入同一块，普通报销自然不显示差旅行。
+2. **费用明细**：费用类型、发生日期、金额和说明；编辑态在这里保留新增、编辑和删除。
+3. **报销材料**：计数与合并预览在上，下面始终显示可单份打开的发票/补充附件列表；只读审批人没有移除或删除动作。
+4. **审批与处理记录**：提交、当前节点和历史。付款事实仅在实际存在时作为本块内的处理结果显示，不新建永久空版块。
+
+状态性内容不形成新的常驻区域：
+
+- 真实风险或校验异常以内联提示放到单头或对应明细附近；无风险不显示。
+- 项目或差旅申请关联作为单头的一行链接；无关联不显示。
+- 草稿/驳回操作继续使用页面底部命令区或移动固定操作条，不算内容块。
+- 打印、返回列表等低频动作收进“更多”，不占主阅读流。
+
+## 5. 明确不做
+
+- 不做 Tab、折叠、底部抽屉或左右分页。
+- 不保留独立“差旅概要”卡片。
+- 不新增常驻预算、合规、风险、财务或付款版块。
+- 不把审批按钮搬进报销业务详情，不改变审批任务返回链路。
+- 不新增普通/差旅类型，不改变现有数据字段、权限、状态机或 API。
+
+## 6. 来源
+
+- 合思官网，合思费控与全链路产品说明：<https://www.ekuaibao.com/>（访问：2026-08-01）。
+- 汇联易官网，全面费用管理产品功能：<https://www.huilianyi.com/products/helios>（访问：2026-08-01）。
+- 每刻报销官网，企业差旅及费用管理平台：<https://www.maycur.com/mkbx>（访问：2026-08-01）。
+- 人人都是产品经理，《费控报销系统，如何设计？》：<https://www.woshipm.com/pd/5292016.html>（访问：2026-08-01）。
+
+以上公开资料只用于提炼信息与流程共性，不把供应商宣传中的预算、AI、ERP、银企直连或大型集团能力视为本项目需求。
+
+## 7. 审批与付款进度补充调研
+
+### 7.1 国内产品共性
+
+- 企业微信官方“获取审批申请详情”数据合同把审批流程表达为多个审批节点；节点含审批人、节点/审批人状态、操作时间和审批意见，备注另行记录。可复用原则是按节点展示职责、处理人、状态、时间和必要意见，而不是显示“节点 1 / 节点 2”。
+- 飞书、钉钉等国内审批产品同样把实例详情、任务/节点和操作记录分开建模。公开资料没有要求统一视觉，但移动端纵向时间轴符合用户既有审批心智，也适合本项目企业微信 WebView。
+- 国内费控产品通常把费用审批与支付、回单、归档串成端到端业务链；实现上审批 workflow 与付款对象仍是不同状态机。详情页可以给用户一条连续进度，但不能把付款批次伪造成 workflow 节点。
+
+企业微信官方资料：<https://developer.work.weixin.qq.com/document/path/91983>（访问：2026-08-01）。
+
+### 7.2 本项目真实状态机
+
+- 报销 workflow 快照当前固定为“主管审批 → 财务复核”，最终把报销状态置为 `approved`。
+- 付款另由 `PaymentBatch` 承担：财务创建批次（maker）→ 非制单人复核批次（checker）→ 执行付款；执行后报销进入 `paid`，银行回单可随后留存。
+- 当前 PC `workflowProgress` 显示“第 N 步”，且只在 workflow pending 时返回；移动端只显示当前节点和历史。报销详情没有付款批次安全摘要，因此还不能诚实展示付款复核、执行和回单状态。
+
+### 7.3 推荐的端到端纵向进度
+
+第四个稳定内容块命名为“处理进度”，使用一条纵向时间轴，按职责显示五个业务阶段：
+
+1. 申请提交
+2. 主管审批
+3. 财务复核
+4. 付款批次复核
+5. 付款与回单
+
+显示规则：
+
+- 节点名称使用业务职责，不显示“第 1 步 / 第 2 步”。
+- 已处理节点显示实际处理人、时间和结果；当前节点显示实际待办处理人（可取得时）和“处理中”；未来节点只显示职责与“待处理”，不根据当前角色持有人猜姓名。
+- 审批意见、退回/驳回原因仅在有内容时显示；退回/驳回原因不得隐藏。
+- 付款批次未创建时，付款复核节点显示“待财务创建付款批次”；批次 draft 显示“待非制单人复核”；reviewed 显示“复核通过，待执行付款”；failed/cancelled 如实显示异常或重新处理。
+- 报销进入 `paid` 后，最后节点显示付款时间/处理人；回单状态作为该节点的次级状态，不额外增加第六块内容。
+- 前端时间轴消费统一的只读进度 DTO；服务端分别读取 workflow 快照/历史、当前 task、报销付款字段和当前关联付款批次摘要，再做安全映射。不得修改 workflow 或 PaymentBatch 状态机。
+
+### 7.4 KISS 边界
+
+- 不画 BPMN、分支图或横向步骤条。
+- 不展示内部 step ID、角色码、权限码或状态机枚举。
+- 不在报销详情复制审批、付款或回单操作；需要处理时仍跳到当前审批任务或付款批次详情。
+- 不硬编码自然人姓名；历史用实际 actor，当前用实际 assignee，未来只写职责。