优化报销审批证据布局（reimbursement-form-shared-component-migration）
这个提交包含在：
@@ -71,8 +71,8 @@ type ReimbursementWorkspaceShellProps = {
|
||||
### Approval Adapter
|
||||
|
||||
- 消费路由边界移交的 workflow task detail/query result，不为同一 task 再发一份分派查询；另行获取实时报销详情。
|
||||
- 拥有 task detail 的业务解释和刷新策略、allowedActions、提交快照、处理历史、审批 mutation、退回引用、材料查看、联网状态和 fail-closed。
|
||||
- 只注入证据查看、引用和审批决策能力；编辑/关联/解绑 capability 必须不存在。
|
||||
- 拥有 task detail 的业务解释和刷新策略、allowedActions、提交快照、处理历史、审批 mutation、退回动作内引用、材料查看、联网状态和 fail-closed。
|
||||
- 常驻内容只注入证据查看和审批决策能力；引用只注入已展开的退回编辑区，编辑/关联/解绑 capability 必须不存在。
|
||||
- 任务、快照、实时报销内容任一关键部分未就绪时，输出不可决策模型和原因。
|
||||
|
||||
### Readonly Adapter
|
||||
@@ -92,9 +92,9 @@ type ReimbursementWorkspaceShellProps = {
|
||||
报销人 · 日期 · 合计
|
||||
事由
|
||||
┌────────────────────────────────────┬────────────────────┐
|
||||
│ 明细及所属票据 │ 当前节点/状态 │
|
||||
│ 未归属票据（仅有时） │ 可决策状态 │
|
||||
│ 补充附件 │ 异常锚点（仅有时） │
|
||||
│ 费用明细表 │ 当前节点/状态 │
|
||||
│ 票据与附件（发票/补充附件分组） │ 可决策状态 │
|
||||
│ 未归属恢复（仅有时） │ 异常锚点（仅有时） │
|
||||
│ 异常/快照差异（仅有时） │ 审批/提交动作 │
|
||||
│ 处理历史/进度 │ sticky │
|
||||
└────────────────────────────────────┴────────────────────┘
|
||||
@@ -102,7 +102,7 @@ type ReimbursementWorkspaceShellProps = {
|
||||
|
||||
### Mobile
|
||||
|
||||
标题/状态 → 报销人/日期/合计 → 事由 → 明细/票据 → 未归属（仅有时）→ 附件 → 异常/差异（仅有时）→ 历史/进度 → 底部动作。
|
||||
标题/状态 → 报销人/日期/合计 → 事由 → 费用明细卡 → 票据与附件（分组）→ 未归属恢复（仅有时）→ 异常/差异（仅有时）→ 历史/进度 → 底部动作。
|
||||
|
||||
正常检查不生成卡片。异常模型必须带对象引用和锚点：
|
||||
|
||||
@@ -162,3 +162,27 @@ type ReimbursementWorkspaceIssue = {
|
||||
## 10. UI/UX Basis
|
||||
|
||||
本任务不引入新视觉系统。采用 `ui-ux-pro-max` 对本场景适用的通用原则：一致标题层级、组合优于模式继承、异常不只靠颜色、反馈明确、触控目标至少 44×44、渐进披露避免把所有解释预先铺开。其数据库没有命中特定“审批工作台”React 模板，因此不采用不存在的模板结论，继续以项目现有组件和 `docs/产品设计规则.md` 的信息架构为基线。
|
||||
|
||||
## 11. Post-deployment KISS Evidence Layout
|
||||
|
||||
上线真人目视反馈证明，统一工作台架构正确，但 `ReimbursementItemEvidenceList` 仍把“费用明细、所属票据、文件动作、退回引用”压进同一嵌套卡片。收尾迭代保持适配器和 capability 边界不变，把展示层拆成三个语义组件：
|
||||
|
||||
```text
|
||||
ReimbursementEvidenceSection
|
||||
├─ ReimbursementExpenseItems
|
||||
│ ├─ desktop: ExpenseItemsTable
|
||||
│ └─ mobile: ExpenseItemCards
|
||||
├─ ReimbursementMaterials
|
||||
│ ├─ invoices
|
||||
│ └─ supplementary attachments
|
||||
└─ ReimbursementReturnReferencePicker（仅退回动作展开时挂载）
|
||||
```
|
||||
|
||||
- `ExpenseItemsTable` 与 `ExpenseItemCards` 消费同一行模型：类型、日期、说明、金额、票据数量/状态、异常摘要、稳定锚点。PC/移动可以不同 DOM，不得各自重新计算业务状态。
|
||||
- 发票不再嵌套在明细 DOM 内；projection 继续保留 `linkedItemId`，由纯函数派生每行票据摘要和独立材料列表。点击问题锚点仍能定位到对应明细行或材料行。
|
||||
- 文件行的文件名/整行采用语义按钮或链接作为唯一查看入口；视觉上不重复“查看原件/查看附件”。移动命中区域不小于 44px，键盘焦点和 `aria-label` 必须包含材料类型与文件名/票号。
|
||||
- edit capability 映射为明细单一编辑入口和材料区维护入口；readonly/approval 不注入维护能力。未归属或阻断票据是例外，可在材料行就地显示关联恢复动作。
|
||||
- `onReferenceItem` / `onReferenceInvoice` 不再传给常驻明细/材料组件；审批适配器仅在 `activeSecondaryAction === "return"` 时把异常优先的候选模型传给引用选择器。选择器只写入本地退回意见文本，不调用 API。
|
||||
- “查看完整材料”是区块级批量预览能力，与单文件入口并存时必须保持次要层级；单文件打开仍沿用既有短时 URL、用途审计和失败隔离。
|
||||
|
||||
参考 `/home/shunli/shenzhou-business-suite` 的费用明细表、移动卡片和附件分区只用于确定信息架构。实现不依赖该项目代码，也不复制其权限、状态或样式实现。
|
||||
|
||||
@@ -61,6 +61,15 @@
|
||||
- [ ] 公网用合成三模式任务验证，不碰 `0016/0017/0018` 或其他真人单据。
|
||||
- [ ] 部署与真人反馈完成前，B-2b 和父任务都不得归档。
|
||||
|
||||
## Post-deployment KISS Closeout
|
||||
|
||||
1. [x] 把当前嵌套 `ReimbursementItemEvidenceList` 拆为共享行 projection、PC 明细表、移动明细卡和独立票据/附件区；不改壳、适配器查询或后端合同。
|
||||
2. [x] PC 审批/只读明细行清零常驻动作；编辑态收敛为单一编辑入口，删除进入编辑流程或二次确认。
|
||||
3. [x] 文件名/文件行成为唯一查看入口，删除重复“查看原件/查看附件”；保留区块级“查看完整材料”及异常票据就地恢复。
|
||||
4. [x] 将明细/票据引用能力移入退回编辑区，异常对象优先，全部对象按需展开；关闭或切换动作时保持现有意见状态合同。
|
||||
5. [x] 更新 PC/移动三模式与 B2 测试：正常行零动作、材料分组、单一查看入口、退回渐进披露、问题锚点、未归属恢复、键盘/触控/横屏。
|
||||
6. [ ] 复跑 typecheck/build、UI strict/self-test、相关 Playwright、B2/workflow 后端回归、治理与部署门；重新提交、push、部署均须分别批准。
|
||||
|
||||
## Rollback Points
|
||||
|
||||
- 适配器接线或非报销回归失败：停止在本地，不删除旧分支，修正后重新验证。
|
||||
|
||||
@@ -29,7 +29,7 @@
|
||||
- 建立 `edit`、`readonly`、`approval` 三类模式适配器；查询、业务状态、权限判断、mutation、错误恢复和 fail-closed 均归适配器。
|
||||
- `/reimbursements/:reimbursementId` 的参与人填写态和非参与人只读态迁入工作台。
|
||||
- `/workflow/tasks/:taskId` 与 `/mobile/approvals/:taskId` 的报销任务进入同一工作台的审批适配器；其他实体继续走通用审批详情。
|
||||
- 复用并扩展 B-2a 的明细—票据证据组件、票据抽屉、提交前检查和未归属恢复。
|
||||
- 复用 B-2a 的证据 projection、capability 契约、票据抽屉、提交前检查和未归属恢复；把嵌套的明细—票据卡片替换为费用明细与材料分区。
|
||||
- 删除 PC/移动通用审批页中的报销业务分支，以及被工作台替代的旧报销明细/材料布局。
|
||||
- 收敛顶部摘要、检查提示、右侧动作摘要和退回/驳回解释。
|
||||
|
||||
@@ -37,7 +37,7 @@
|
||||
|
||||
### R1 一个业务对象只保留一个交互式工作台
|
||||
|
||||
- 报销详情的主内容顺序在 `edit`、`readonly`、`approval` 三种模式中一致：紧凑报销头 → 明细及所属票据 → 未归属票据 → 补充附件 → 必要检查/差异 → 处理历史或处理进度。
|
||||
- 报销详情的主内容顺序在 `edit`、`readonly`、`approval` 三种模式中一致：紧凑报销头 → 费用明细 → 票据与附件 → 必要检查/差异 → 处理历史或处理进度。发票归属仍是业务合同，但不再以嵌套卡片占据每条明细的主视觉。
|
||||
- PC 宽屏使用主列证据 + 右侧单一 sticky 动作区；窄屏和移动采用同一内容顺序的卡片/分区详情布局，动作区转到底部且不遮挡内容。PC 与移动不强求同一份 DOM，不得用密集的 `isMobile` 业务分支把两种布局重新耦合成巨型壳。
|
||||
- `/workflow/tasks/:taskId` 保留为审批入口和浏览器地址。任务解析为 `reimbursement` 后由报销审批适配器渲染工作台；不得先渲染通用报销摘要再嵌入工作台，也不得要求用户点击“查看报销单”才能取得核心内容。
|
||||
- `/reimbursements/:reimbursementId` 使用同一工作台。参与人处于 `draft/rejected` 时获得编辑能力；其他获准查看者只得到只读能力。
|
||||
@@ -65,7 +65,7 @@
|
||||
### R4 信息必须按审批人决策需要收敛
|
||||
|
||||
1. 顶部只显示报销单号、状态、报销人、日期、合计；事由作为紧接标题的正文展示。不得再用六张字段卡重复下面已经出现的信息，也不显示“业务类型=报销”等自明字段。
|
||||
2. 主列直接进入明细和所属票据；附件随后展示。相同报销头、事由、票据或检查事实不得在不同区块重复完整表达。
|
||||
2. 主列直接进入费用明细，随后进入独立的“票据与附件”区。PC 明细使用紧凑表格，移动明细使用卡片；表内只呈现票据数量/状态，不嵌套票据卡片或文件操作。发票与补充附件在证据区内分组，避免把两类业务语义合并成同一种数据。
|
||||
3. 正常项不解释、不计数。只有存在异常或人工决策需要时才显示提示，并就近说明“对象、原因、影响、下一步”；不得默认平铺“0 条”状态或仅显示无法定位对象的总数。
|
||||
4. 提交时快照与当前票据事实一致时，不并排展示两个“检查摘要”；只有出现异常、快照缺失或时间语义差异时才显示必要内容。
|
||||
5. 历史提交缺少预算快照时，以低强调度说明“该次提交未留存预算快照”；它不得使用告警视觉冒充当前业务异常，也不得用实时预算结果补写历史。
|
||||
@@ -75,8 +75,8 @@
|
||||
|
||||
### R5 编辑态围绕明细完成票据维护与提交恢复
|
||||
|
||||
- `edit` 适配器向同一明细—票据组件注入新增、编辑、删除、上传/选择 PDF 发票、关联、解绑和未归属恢复能力。
|
||||
- 员工可在当前明细上下文内查看和维护所属票据；未归属票据直接提供选择明细的恢复入口，不依赖口头操作顺序或跳到独立材料区。
|
||||
- `edit` 适配器向同一费用明细与材料组件组注入新增、编辑、删除、上传/选择 PDF 发票、关联、解绑和未归属恢复能力。
|
||||
- 员工从费用明细进入单一“编辑”入口维护该条明细；删除收进编辑弹窗或明确的二次确认，不与编辑并排常驻。票据上传、关联、解绑和未归属恢复统一位于“票据与附件”区；未归属票据直接提供选择明细的恢复入口。
|
||||
- 整单补充附件继续作为独立证据，不伪造与某条明细的结构化关系。
|
||||
- 填写过程中持续计算可解释的提交前检查；汇总区只提示仍有多少可操作问题并提供锚点，具体错误就近落到明细或票据。
|
||||
- 服务端 B2 门禁继续为权威。前端不得因工作台迁移放宽 `ocr_failed`、manual review、金额超票面、缺票或未归属合同。
|
||||
@@ -86,7 +86,7 @@
|
||||
|
||||
- 费用标准/预算使用 workflow 提交快照；票据归属、金额证据和附件使用当前实时报销详情。两者不得互相替代。
|
||||
- 完整报销内容、关键当前检查或提交快照解析未就绪时，通过、退回、驳回、转审和报销离线草稿均不可执行；动作入口除禁用外仍有中文原因。
|
||||
- 审批适配器只注入查看原件、查看附件、引用到退回意见及 workflow 决策能力，不注入报销维护能力。
|
||||
- 审批适配器只注入材料查看及 workflow 决策能力，不注入报销维护能力。明细和票据不常驻“引用到退回意见”；只有展开“退回”动作后，才在意见编辑区提供可选的明细/票据引用清单。
|
||||
- 报销证据继续排除在移动 IndexedDB workflow cache 之外；其他审批类型的离线草稿能力保持不变。
|
||||
- 已处理任务查看当前报销版本时保留时间语义提示；历史意见和提交快照不被当前内容覆盖。
|
||||
|
||||
@@ -97,9 +97,19 @@
|
||||
- PC/移动从待办列表进入、刷新、浏览器返回、深链打开和已处理任务查看均保持可预测；工作台返回目标由入口上下文决定，不形成“返回审批详情 → 又回到同一工作台”的循环。
|
||||
- 页面级加载失败显示重试和安全返回；单个材料加载失败只影响该材料，不清空已加载证据。
|
||||
|
||||
### R8 上线后按国内报销阅读习惯完成 KISS 收敛
|
||||
|
||||
- PC “费用明细”使用一张表，固定核心列为序号、费用类型、发生日期、费用说明、金额、票据；票据列只显示“免票 / N 张 / 未关联 / 需核对”等短状态。正常行不显示解释文案或业务按钮，异常在对应行内用文字与图标共同标识。
|
||||
- PC 表格的审批态和只读态行内操作为 0；编辑态只允许一个“编辑”入口，删除进入编辑弹窗或二次确认。不得恢复“编辑 + 删除 + 引用 + 查看原件”并排动作。
|
||||
- 移动端保持卡片而不复制 PC 表格；每张卡只显示费用类型、日期、金额、说明和票据状态。正常卡无操作说明，编辑态能力从单一入口进入。
|
||||
- “票据与附件”是明细之后的独立区块，内部按“发票”和“补充附件”分组。文件名/文件行本身是唯一查看入口并具有完整可访问名称；不得为每个文件重复渲染“查看原件”“查看附件”按钮。只有异常票据显示就地恢复动作。
|
||||
- 退回引用采用渐进披露：默认页面不显示引用按钮；用户展开“退回”后，意见框附近显示可勾选的异常明细/票据，必要时可展开全部，选择后生成可编辑的引用文本。关闭退回区不改变业务数据。
|
||||
- “查看完整材料”只在确有批量核对价值时保留为区块级次要入口，不与每个文件的查看入口重复；无材料时不显示空动作。
|
||||
- 本轮只重排前端展示与能力入口，不改变发票—明细关系、B2 门禁、快照/实时语义、材料授权审计、workflow 状态机或后端数据合同。
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1：PC 与移动的 `edit`、`readonly`、`approval` 使用同一展示模型、区块顺序、明细—票据语义组件和 capability 契约；PC 可使用右栏 sticky 布局壳，移动可使用卡片 + 底部动作布局壳，不要求同一份 DOM，模式差异只来自适配器注入的数据与能力。
|
||||
- [ ] AC1：PC 与移动的 `edit`、`readonly`、`approval` 使用同一展示模型、区块顺序、费用明细/材料语义组件和 capability 契约；PC 可使用右栏 sticky 布局壳，移动可使用卡片 + 底部动作布局壳，不要求同一份 DOM，模式差异只来自适配器注入的数据与能力。
|
||||
- [ ] AC2：PC/移动布局壳中 `useQuery`、`useMutation`、API 调用、角色/权限判断、workflow/报销状态机判断和 `if (mode === ...)` 业务分支均为 0；`scripts/qa/check-ui-design-rules.mjs --strict` 静态扫描并报 error，且该命令作为部署 preflight 执行。
|
||||
- [ ] AC3：`WorkflowTaskDetailPage` 与 `MobileApprovalsPage` 的报销业务渲染分支、六字段摘要、重复检查区和休眠兜底全部删除；通用审批页仍通过非报销回归。
|
||||
- [ ] AC4：报销审批首屏只有一套紧凑报销头；事由、明细、所属票据、附件、异常和历史各有唯一主展示位置，不再出现两套摘要或四处检查计数。
|
||||
@@ -110,6 +120,10 @@
|
||||
- [ ] AC9：报销证据不进入 IndexedDB；非报销审批离线草稿基线、PC/移动非报销详情和 workflow 状态机均无回归。
|
||||
- [ ] AC10：参与人/非参与人、`draft/rejected/reviewing`、pending/已处理任务和材料权限矩阵通过；没有新增 schema、migration、flag、seed 或生产数据改写。
|
||||
- [ ] AC11：生产部署后使用公网真实 bundle + 合成 API 完成三模式、失败关闭和离线验收；真实员工重提反馈记录后，父任务才允许归档。
|
||||
- [ ] AC12：PC 审批/只读费用明细为单表且行内业务按钮为 0；编辑态每行至多一个“编辑”入口。表格在 1280px 无横向溢出，键盘与读屏按列顺序读取。
|
||||
- [ ] AC13：移动费用明细保持卡片；PC/移动共享同一明细字段、顺序、异常语义与 capability 合同，不共享同一 DOM。375px 与横屏无内容遮挡或横向溢出。
|
||||
- [ ] AC14：票据和补充附件从明细中拆出并在独立证据区分组；正常文件仅有一个可访问的查看入口，正常明细/票据不出现“引用到退回意见”“查看原件”“查看附件”按钮文案。
|
||||
- [ ] AC15：只有展开退回动作后才出现引用选择；异常对象优先、全部对象按需展开，选择结果进入可编辑意见。B2 未归属恢复、金额异常锚点、材料查看审计和审批 fail-closed 回归通过。
|
||||
|
||||
## Out of Scope
|
||||
|
||||
@@ -123,8 +137,8 @@
|
||||
## Test Plan
|
||||
|
||||
- 结构边界：`check-ui-design-rules.mjs --strict` 扫描 PC/移动布局壳，禁止 query/mutation/API/角色/状态机/mode 请求分支，并扫描通用审批页报销分支和旧文案为 0；三适配器能力集合另做组件/类型验证。
|
||||
- 纯函数/组件：统一报销头、明细—票据投影、异常过滤、快照/实时差异、异常锚点和 capability 注入覆盖正常/异常/缺失边界。
|
||||
- PC/移动 Playwright：三模式内容顺序；无异常降噪；异常就近文案；右栏/底部动作；票据抽屉；未归属恢复；B2 阻断后修复并再次提交；退回引用；深链/返回。
|
||||
- 纯函数/组件：统一报销头、明细行/材料投影、异常过滤、快照/实时差异、异常锚点和 capability 注入覆盖正常/异常/缺失边界。
|
||||
- PC/移动 Playwright：三模式内容顺序；PC 明细表/移动明细卡；正常行零动作与零解释；独立票据/附件区；文件单一查看入口；异常就近文案；右栏/底部动作；票据抽屉；未归属恢复；B2 阻断后修复并再次提交；退回动作展开后引用；深链/返回。
|
||||
- 权限/状态：participant/nonparticipant × draft/rejected/reviewing；pending/已处理审批；无权 task、跨单材料、无维护能力和并发关联回归。
|
||||
- 离线：直接读取 IndexedDB 禁存字段/哨兵值；报销动作和草稿 fail-closed；非报销审批离线草稿仍可形成和同步。
|
||||
- 后端：原则上不改合同；复跑 B2 门禁、报销详情只读投影、workflow task detail、材料查看审计、票据 bind/unbind/link 和审批动作聚焦测试。
|
||||
@@ -136,4 +150,5 @@
|
||||
- 大型旧页面拆分容易在中间阶段形成双实现；允许在开发分支短暂并存，但最终候选必须通过旧分支为 0 的结构门禁。
|
||||
- task 路由先取元数据再分派可能产生加载闪烁；设计必须用稳定骨架而不是先渲染通用页再切换。
|
||||
- 打印页继续独立，未来如字段语义漂移可另建“打印投影复用”任务；本轮不扩大交付面。
|
||||
- 神州 ERP 仅作为国内报销信息层级参考；不复制其旧页面状态管理、过小图标按钮、打印专用边框或数据模型。当前系统继续以自身 B2、权限、审计和可访问性合同为准。
|
||||
- 全局错误色 token、部署脚本 `--no-deps`、`.claude` gitignore 和其他治理债不并入本任务。
|
||||
|
||||
@@ -21,6 +21,6 @@
|
||||
"children": [],
|
||||
"parent": "09-01-reimbursement-one-page-approval-workbench",
|
||||
"relatedFiles": [],
|
||||
"notes": "父任务第二阶段；B-2a 已部署并取得真人目视反馈。规划采用方案 A：仅报销进入业务对象工作台审批模式，其他 workflow 实体保持通用详情。实现与本地全量门禁已完成，用户最终 diff 复核通过，实现提交为 abdd250；尚未 push、部署或触碰真人单据。",
|
||||
"notes": "父任务第二阶段；方案 A 的统一报销工作台已以候选 9fc3b76 部署，生产 build marker 为 9fc3b764382d。上线真人目视反馈触发 KISS 收尾：PC 明细表格、移动明细卡片、票据/附件独立分组、单一文件查看入口和退回动作内渐进引用已完成本地实施；typecheck/build、UI strict/self-test、R102/R111/workflow/视觉聚焦回归及治理通过，等待用户 diff 复核，尚未提交、push、部署或触碰真人单据。",
|
||||
"meta": {}
|
||||
}
|
||||
|
||||
在新工单中引用
屏蔽一个用户