fix: 统一报销付款状态与进度（09-04-reimbursement-state-gap-finance-view）

.trellis/spec/hyb-oa/frontend-react-vite-design.md

@@ -12,6 +12,15 @@ This spec keeps hyb-oa-specific React/Vite, shared-component, business-boundary
 and verification contracts. Do not copy broad aesthetic guidance from
 `frontend-design` into this file; use the skill directly for design judgment.
 
+## Convention: Reimbursement Payment Handoff Consistency
+
+- `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.
+- PC uses `asideContext` for current progress after `actionPanel`, with `lg:static` on the action card. Payment detail and reimbursement approval share this order; comments remain readable without horizontal overflow. Mobile retains its own safe-area action contract.
+- Test absent batch, review, export, receipt, paid, failed/cancelled, missing progress and no batch-read permission. Test create/review/export with real isolated roles, then return from batch to reimbursement. Include visibility return and refresh; a payment-only test does not prove the source detail is correct.
+- Wrong: `approved => create batch`, or `!targetHref => no batch`. Correct: stage-derived next step and one server-authorized destination, including a conservative unknown state.
+
 ## Scenario: Actionable Validation And Selectable Payment Channels
 
 ### 1. Scope / Trigger
@@ -590,8 +599,8 @@ reference, not a copy of Feishu or Ant Design branding.
 - Mobile workflow caching uses an explicit persisted projection. Reimbursement items, invoices, attachments, amount evidence, material access data, workflow snapshot checks and shared component projections do not enter IndexedDB. Offline reimbursement approve/reject/return/draft is forbidden, while other workflow entity offline behavior remains unchanged.
 - The information order is compact header and reason, expense items, invoices, supplementary attachments, real issues/differences when present, then history/progress. Normal state creates no `0 条` check card. Issue copy identifies the object, reason, impact and next step rather than exposing internal counters alone.
 - Expense totals in the header, desktop table footer, mobile summary row and print view all display the server `totalAmount`. A shared workspace-model boundary may sum strictly parsed integer minor units only to classify integrity; that derived sum is never rendered or submitted. A mismatch or unparseable amount is a data-integrity failure, uses distinct non-color-only copy and fails reimbursement approval closed; normal records show no difference explanation.
-- Reimbursement workflow history answers approvers “who acted, when and with what comment”. On desktop approval it appears once in the right aside after the independently sticky decision panel; the main column receives no dormant timeline slot. On mobile approval it remains after evidence and before the safe-area action surface.
-- `ProcessingProgress` intentionally remains separate from workflow history. It answers applicants “where the reimbursement and payment have reached”, may include future stages and owns the single payment-batch link. Workflow history contains occurred actions only. Do not remove either as duplicate or let their shared action/status semantics conflict.
+- Reimbursement workflow history answers approvers “who acted, when and with what comment”. Desktop uses the right aside: non-sticky decision panel, current processing progress, then full history; the main column receives no dormant timeline slot. Mobile keeps evidence, action explanation, current progress and history in one column with necessary safe-area actions.
+- `ProcessingProgress` remains separate from workflow history and may include future stages. An authorized batch link may be promoted into the action panel; pass that exact `suppressedTargetHref` to progress so it appears only once. Do not remove historical facts as duplicates or mistake an absent authorized link for an absent batch.
 - `MobileStickyActionBar` and `MOBILE_STICKY_ACTION_PAGE_CLASS` are one contract. Add the page class only when `mobileActions` exists; omitting it lets `page-scaffold` transform capture the fixed bar, while adding it without a bar leaves false bottom padding.
 - `/reimbursements/:id/print` remains a purpose-built print/PDF view. It is not a fourth interactive workbench and receives no workbench mutation.