fix: 统一报销付款详情布局与票据展示（09-04-reimbursement-state-gap-finance-view）
这个提交包含在：
@@ -14,6 +14,11 @@ and verification contracts. Do not copy broad aesthetic guidance from
|
||||
|
||||
## Convention: Reimbursement Payment Handoff Consistency
|
||||
|
||||
- Reimbursement desktop shells and payment detail opt into `detail-workspace-grid--payment`: a 320px aside at lg and above, single column below lg. A shared proportional grid does not guarantee equal asides when parent max-width differs. Verify actual widths on both pages at 1280/1440, not only matching class names; leave unrelated detail grids unchanged.
|
||||
- `BusinessDetailActionPanel({ inlineActions: true })` puts the primary action followed by the More trigger in a wrapping, content-width row. The default layout stays unchanged. Both detail pages use the existing DropdownMenu; menu items are portalled outside the card, so test via page-level menu roles. Keep disabled states, permission conditions, confirmations and mobile payment actions intact. Do not pass known-empty action components as children: a React element that renders null is still a nonempty slot and otherwise creates a phantom divider.
|
||||
- Linked reimbursement invoices use a desktop table with number preview, seller, date and right-aligned amount; narrow rows stack without duplicating IDs or preview controls. Keep OCR warnings, unlinked correction cards, attachment delete confirmation and evidence anchors. Test five synthetic invoices, long names/numbers, empty attachments, preview calls, narrow layout and the existing approval/detail consumers.
|
||||
- A compact payee-account reveal control stays beside the masked value as a 44px Eye button with title and aria-label `查看完整账号`. Preserve role/permission/status/account gates and the reason/audit dialog; icon clicks must not immediately request plaintext. Layout measurements wait for fonts and compare aligned centers; round subpixel box heights to hundredths before checking the 44px minimum (Chromium can return 43.99994 for a CSS 44px target).
|
||||
|
||||
- `resolveReimbursementPaymentHandoff({ status, deletedAt, progress })` consumes the server's `payment_batch_created`, `payment_batch_review` and `payment_and_receipt` stages. It is a display projection, not a second payment eligibility or write state machine.
|
||||
- Only an explicit current creation stage followed by pending review/payment can advertise creation, and the caller still requires `payment.batch.manage`. Missing stages, unknown status or contradictory facts never produce a guessed creation action. Cancelled and failed batches use the existing stage explanation, not automatic recreation.
|
||||
- Read-only detail states (including reviewing, approved and paid) override global focus caching locally (`staleTime: 0`, refetch on mount and visibility return). Do not enable whole-app focus refetch or overwrite draft/rejected editors for this fix. A query error must not keep a stale actionable payment panel.
|
||||
|
||||
@@ -1,5 +1,11 @@
|
||||
# 报销状态空隙与财务处理视角：设计
|
||||
|
||||
## 2026-09-11 等宽侧栏与票据表格
|
||||
|
||||
动作卡通过可选inlineActions布局主动作和更多，默认合同不变。两页更多复用现有Radix DropdownMenu，Portal渲染后测试按page.getByRole("menuitem")定位，而不是动作卡内找按钮。业务回调和确认对话框不变；报销调用方仅在有撤回或动作错误时传ReimbursementActions，避免React组件返回null但外层误判为有内容而生成空分隔线。
|
||||
|
||||
根因：共享detail-workspace-grid使用比例列，而报销壳另有max-w-7xl，付款壳无同一上限。新增局部共享detail-workspace-grid--payment类供两处使用，lg起固定320px侧栏，主列minmax(0,1fr)，保持各自正文宽度和手机规则。frontend-design不可用，仅复用现有表格、边框和按钮样式，不创建新视觉体系。已关联票据采用响应式表格，窄屏按行紧凑排列；未关联票据保留原纠错控件与唯一锚点。姓名和号码允许换行，预览、移除及OCR告警按原capabilities保留。
|
||||
|
||||
## 2026-09-11 下一步与侧栏一致性方案（已批准本地实施）
|
||||
|
||||
本轮只读核对已发布候选，未查询生产。ReimbursementDetailPage 的 approved 分支无条件显示“等待财务组建付款批次”，其主动作只再检查 payment.batch.manage；同一页面 ProcessingProgress 已消费服务端按真实批次状态构造的阶段。修复必须连接这两处投影，不能只把错误文字换成另一句固定文案。
|
||||
|
||||
@@ -1,5 +1,29 @@
|
||||
# 报销状态空隙与财务处理视角：实施计划
|
||||
|
||||
## 本轮复核输入与提交准备（未提交）
|
||||
|
||||
用户批准整理两笔独立改动的复核/提交方案。基线均为5d8cdf12；01为制单备注5文件，02为UI布局11文件，路径无重叠。仅生成补丁、摘要清单并用临时索引验证顺序合并，不改变实际HEAD/index，不创建commit，不推送或部署。复核入口位于layout副本的artifacts/qa-layout/review-preparation/README.md；临时合并树不是发布候选commit。既有验证按输入不变复用，本轮不新增测试通过计数；UI补跑外层143、网银导入未验证、未独立复核等边界保留。提交前须核对冻结摘要，发布前还需验证合并后的实际候选，不能把单包测试冒充集成验收。
|
||||
|
||||
## 2026-09-11 侧栏与票据展示增量
|
||||
|
||||
独立layout副本基于5d8cdf12，官方current核对本task；不混制单备注及其他未提交工作。本轮已授权本地实施，未授权提交/推送/部署。
|
||||
|
||||
- [x] 统一两处侧栏，复用表格展示已关联发票，保留异常/手机/附件能力；同轮更多下拉同行、账号旁查看图标已实施。
|
||||
- [x] 添加同屏宽度和票据展示回归，运行typecheck/build与相关浏览器测试。
|
||||
- [x] 主会话复核、更新规约和验证记录，明确未发布边界。
|
||||
|
||||
本轮本地实施已完成：图标仅替换展示，原employee.bank.read/finance角色、reviewed/failed及paymentAccount条件未改，点击仍需填写原因后才能请求完整账号。布局/菜单不改API、权限规则和状态机；主会话核源码及合成截图，不冒充独立复核或生产验收。
|
||||
|
||||
验证回执：
|
||||
- client下npm run build（含typecheck）重跑退出0，Vite/PWA完成，116项预缓存；最终源文件再次npm run typecheck退出0。首轮build外层143保留，不计为通过。
|
||||
- E2E_BASE_URL指向本地4317，npx playwright test tests/e2e/system-action-confirmation.spec.ts tests/e2e/reimbursement-content-consistency.spec.ts --workers=1 --reporter=list：50项中47通过、3失败。手机失败是boundingBox将44px回传为43.99993896484375；改为百分之一像素精度判断，仍要求44px。另两项为未指定BIFF8运行环境，生成器不可用，不是制单内容失败。
|
||||
- 使用既有BIFF8虚拟环境的PAYMENT_ORDER_PYTHON_BIN，仅重跑手机交接和双端制单3项，Playwright报告3 passed。外层会话返回143，不能把整条补跑命令称为退出0；进程检查已无该补跑进程。保留日志和结果，不为刷绿再次重复已通过输入。50项用例已有通过结果，但不是一次50/50退出0的运行。
|
||||
- 首轮侧栏4项中3通过，同排几何测量出现8px差值，失败截图未见持续错排；等待字体并按中心线比较后，1280/1440均通过且两页侧栏都实测320px。不将字体竞态猜测冒充已独立证明的原因。
|
||||
- 图标键盘打开/取消零完整账号请求；5张长名称/长编号在390/1280/1440均完整且不造成页面横向溢出，预览请求命中正确票据；桌面更多、删除/撤回/打印、手机底栏、上传回单、双端真实BIFF8下载与重复下载边界均有回归通过结果。
|
||||
- Trellis治理、process-contract baseline、git diff --check通过。本地证据存artifacts/qa-layout（ignored），含首次失败和补跑记录；不提交合成截图或原始运行输出到业务文档。
|
||||
|
||||
未提交、未推送、未部署、未做生产写入；制单备注仍在另一独立副本。本轮不归档整个task。下一步按路径汇总本UI增量与独立备注增量的候选复核输入，经明确授权后再分别提交/推送及准备发布，不覆盖原integration任务历史。
|
||||
|
||||
## 2026-09-11 迟到 401 复核接续（最新，门户取消修正本地通过）
|
||||
|
||||
主会话只读核对 dcde0d44 的 33 源文件、3 补丁重放及历史证据后，双端合成浏览器补查甲→乙→甲：甲旧请求迟到 401 后按乙会话重试，结果进入甲缓存，甲再次登录等待新响应时显示乙待办。该包 NO_GO；独立复核仍 PENDING_INLINE，原 6/62/真实隔离通过记录不改写。回执在 postpush-identity/readonly-review.md。
|
||||
|
||||
@@ -2,6 +2,14 @@
|
||||
|
||||
## Goal
|
||||
|
||||
### 2026-09-11 追加：侧栏等宽与票据紧凑展示（已批准）
|
||||
|
||||
用户同轮要求“查看完整账号”改为账号旁Eye图标，保留44px触控、title/aria-label及键盘入口；账号仍默认脱敏，权限/角色/状态条件和填写原因、审计流程不变，不改为悬浮或点击即解密。
|
||||
|
||||
用户同轮追加“更多”紧随主按钮：报销和付款桌面动作行左对齐，主按钮按内容宽度，更多为相同下拉菜单；不足则换行，不改变手机付款底栏。保留菜单内删除/打印/下载/上传/取消的资格、禁用与确认语义。去掉空动作组件导致的重复分隔线，不隐藏实际撤回或错误信息。
|
||||
|
||||
报销详情/审批共用壳与付款详情桌面侧栏统一320px，lg以下仍单列，操作在上、进度在下；不改其他业务布局。发票桌面按号码、开票方、日期、金额、操作展示，号码沿用预览入口，金额右对齐；窄屏紧凑列表。补充附件保留独立文件列表及已有类型/大小、预览和有权删除入口，空态一行。不新增关联步骤，不隐藏未关联/OCR失败等异常处理。使用合成数据验收等宽、多票据、长名称、预览、附件删除及390px无页面溢出。无权限/API/生产变更，不混入制单备注补丁。
|
||||
|
||||
### 2026-09-11 追加需求：付款下一步与详情侧栏一致性（已批准本地实施）
|
||||
|
||||
用户反馈财务在报销详情同时看到“去组建付款批次”和已创建、已复核的付款进度。只记录脱敏状态矛盾，不复制真实截图、票据或金额。已发布 fe025e65 源码中右侧下一步及主动作只按报销 status=approved 判断，忽略已由服务端提供的付款阶段；报销进度插在主列材料之后，付款详情则在右栏操作下方。报销审批通过并不等于尚未组批，也不等于银行已经付款。
|
||||
|
||||
在新工单中引用
屏蔽一个用户