# Receipt queues — Atelier preview

Open `index.html#/payments/receipts`. Source UI remains `02-atelier` / `admin-atelier-v2`: charcoal, apricot, Vazirmatn, fine borders and image-led receipts. This revision follows the user's approved direction directly.

## Reference lock and decisions

- Tinder supplies only the focused card stack and physical right/left decision interaction. Visible approval and rejection buttons remain equivalent alternatives.
- The user's current request supplies pending-only card capsules, live counts, automatic movement to the next card and bounded lazy loading. Capsule movement follows Refero's bundled `motion.md` guidance for layout continuity: short overlapping count, collapse and settling animations, with a reduced-motion fallback.
- The bot's `/GetPayment_<id>` and card-payment handlers supply action eligibility. Approved/credited/canceled receipts are read only. Rejected and expired receipts can be approved when creditable. Custom amount is a persistent guarded mode with its own cancel action.
- Details show payment data and permitted actions. No internal notes, defer, approval undo, status reset/reopen or invented audit timeline. The list provides payment history.
- Capsules belong to the pending queue. History status tabs search all cards, including cards no longer present in the pending queue. Card suffixes distinguish several cards at the same bank.
- The existing search also accepts a payment ID or `/GetPayment_<id>`; there is no separate payment-finder button or dialog. Search responses replace only the results, preserving the actual input node, focus and selection so typing does not dismiss the mobile keyboard.
- The viewer's expand icon opens fullscreen, with a viewport-filling fallback on browsers without the native API. The percentage becomes a reset button after zooming or rotating; fullscreen and reset are separate operations.

## Data and loading

Only the existing shared mock world is used. `shared/admin-receipts.js` supplies a separate aggregate summary, stable cursor pages, detail lookups and guarded review/custom-mode writes. No live wallet credit or bot message is sent.

History loads ten records per page; images are loaded only near the viewport. The deck retrieves/preloads at most five receipts and refills only the number consumed. Its window includes following cards so an exhausted card can hand over to a prepared receipt. Query generations discard stale responses; duplicate page requests are coalesced.

Six provided original images remain untouched. Thirty historical fixture records reuse those photos to make pagination inspectable. Legacy demo notes/deferred states are migrated away. The reset button is a mock fixture control, not a payment operation.

## Future backend integration

**Read [RECEIPTS_BACKEND_CONTRACT.md](../shared/RECEIPTS_BACKEND_CONTRACT.md) before wiring the UI.** It records the user's ten-item history/five-item rolling deck requirement, exact bot action policy, proposed endpoint envelopes, stable cursor rules and media budget.

Verification: `shared/admin-receipts.test.mjs` covers a 100-record paginated history, Unicode search cursors, exact payment-command search, the five-plus-one deck buffer, counts, one-world storage, conditional recovery, custom-mode locks, stale writes and irreversible approval. Browser automation is `output/playwright/receipt-queues-qa.js` and `output/playwright/receipt-viewer-qa.js`; screenshots use `receipt-queues-*.png`. Search checks assert input-node identity and no blur across responses; a desktop browser cannot directly verify an actual phone's software keyboard.