# STANDALONE-001 — Order history

## Status

Done

## Purpose

Give authenticated operators a way to find delivered orders and inspect the details that were
finalized and recorded during fulfillment. This is a standalone addition to the existing MVP: Epic
003 preserves delivered orders durably but explicitly excludes a history/search UI.

## Scope

Add a protected page titled **Order history**, reachable under the **New order** navigation area. It
presents delivered orders in a table, newest first. Each order can be expanded to show its complete
human-readable details. This requirement covers commercial and non-commercial delivered orders
because both are durable orders in the shared fulfillment model.

## Acceptance scenarios

### STANDALONE-001-S01 — Protected page is reachable under New order

- **Given** an authenticated operator
- **When** they open the **New order** navigation area
- **Then** they can navigate to a protected page titled **Order history**
- **And** an unauthenticated visitor cannot read the page or its order data
- **Evidence:** frontend navigation/page test and backend/API authorization test for any history
  read endpoint; include the scenario ID in test title or native metadata.

### STANDALONE-001-S02 — Delivered orders appear newest first

- **Given** delivered orders with different delivery timestamps
- **When** the operator opens Order history
- **Then** every delivered order is represented once in a table, with the latest delivery date and
  time first
- **And** orders that have not been delivered are absent
- **And** equal timestamps have a deterministic secondary order
- **Evidence:** application/API test for delivered-only filtering and deterministic ordering, plus a
  page test for rendered rows; scenario ID required in executable evidence.

### STANDALONE-001-S03 — Summary row shows useful compact order information

- **Given** a delivered order
- **When** its table row is displayed
- **Then** the row shows its eventual queue number when one was recorded, a compact one-line item
  description using kitchen labels, its kitchen note when present, delivery date and time to minute
  precision, and total gross amount
- **And** missing queue numbers and notes are represented without misleading placeholder data
- **And** the item description and note each stay on one line and shorten overflow with `...`
- **Evidence:** component tests cover kitchen-label fallback, multiple items/quantities, absent
  optional values, truncation, minute precision, and gross total; scenario ID required.

### STANDALONE-001-S04 — Row expansion shows the complete order

- **Given** a delivered order in the table
- **When** the operator expands its row
- **Then** all order details available from the finalized order and its recorded history are shown
  in a human-friendly layout, including item names and kitchen labels, quantities, captured prices
  and VAT, gross total, queue number, note, eat-here/take-away metadata, classification, checkout
  outcome/reference when applicable, and relevant finalization and fulfillment timestamps
- **And** expanding or collapsing a row does not change or delete the order
- **Evidence:** component test covers displayed detail fields and expand/collapse behavior; API or
  integration evidence verifies the read model supplies durable snapshot values; scenario ID
  required.

## Presentation rules

- Order by delivery timestamp descending. When timestamps tie, order by immutable internal order ID
  ascending for stable pagination/rendering.
- Render date and time in the configured local timezone with minute precision.
- Use the captured kitchen label for each item when present; otherwise use the captured product
  name.
- Keep summary item content compact and single-line. Use an ellipsis (`...`) where the available
  width truncates the text; the expanded details retain the complete text.
- Show money as gross customer-facing SEK using the project's existing money-formatting convention.
- The queue number is the order's recorded queue number, if any; do not synthesize one.
- Notes are optional. A missing note leaves no note text in the summary.

## Exclusions

No search, filtering, editing, deletion, export, receipt generation, refund workflow,
customer-facing history, or new analytics. No retention policy or authorization role model is
introduced here.

## Required validation

Implement tests at the lowest suitable levels for all scenarios, run affected application tests,
coverage and the repository's `pnpm quality` gate, and update the scenario evidence references
below. If the implementation changes an HTTP contract, update OpenAPI and regenerate/check the
documentation site as required by the repository rules. Add end-to-end tests for the scenarios.

## Implementation record

- **Status:** Done
- **Implementation tasks:** Implemented as one vertical slice; no separate task record was needed.
- **Scenario evidence:** `OrderHistoryPage.test.tsx`, `order-api.test.ts`, `pages.test.tsx`,
  `order-http.test.ts`, `order-history.integration.test.ts`, and `tests/e2e/order-history.spec.ts`;
  the scenario-to-evidence index is in [standalone README](README.md#scenario-to-evidence-index).
- **Validation:** Focused frontend/backend tests, PostgreSQL integration, and desktop/mobile
  Playwright history tests passed. `pnpm test:coverage` passed with 100% statements, branches,
  functions, and lines in frontend and backend. `pnpm quality`, `pnpm docs:build`,
  `pnpm docs:site:check`, and `git diff --check` passed. `docs:check` reports only the existing
  health-route missing-4xx and Redux Toolkit inherited-summary warnings.
- **Notes:** The requirement adds a history presentation surface that Epic 003 excluded; it is
  intentionally tracked independently under the standalone namespace. Detail text follows the
  table's theme body2 scale, and history entries display their timestamp before the event.