[C06] Order Detail

I'm designing the **Order Detail** screen for the EMS admin portal — a
Spring Boot + Angular SPA admin tool used by event operators (race
directors), tenant admins, and finance staff to manage participants,
events, members, and order/payment data. Visual language matches the
existing portal screens you've designed in this project (C01 structure,
C03 public landing, C04 reassignment dialog, E01 event overview, E05
events control centre, E02 event participants — all handoff-ready or
in-design with v2 prompts). Match fonts, spacing, palette, density.

C06 is the **canonical order-detail surface** for the entire portal.
Every order — event-participant orders, membership orders, future cross-
event purchases — surfaces here. The route is deliberately *not* event-
scoped; orders cross event boundaries. Three invocation surfaces feed
into it: a hover popup panel on calling screens, a modal cluster
overview (also on calling screens), and direct route navigation.

============================================================
Route
============================================================

  /orders/{orderId}                       — view-only landing
  /orders/{orderId}?action=cancel
  /orders/{orderId}?action=mark-paid
  /orders/{orderId}?action=refund
  /orders/{orderId}?action=resend-receipt — auto-opens that action dialog
  /orders/new?epId={id}
  /orders/new?membershipId={id}           — Future (FU-2); v1 stubs only

The action is a **focused mode of the same screen**, not a separate
URL hierarchy. Refresh on `?action=cancel` should reopen the cancel
dialog — that's the desired behaviour. Sub-routes (`/orders/{id}/cancel`)
would imply different pages and are explicitly rejected.

============================================================
Invocation surfaces (rendered on caller screens — NOT on C06 itself)
============================================================

These three surfaces summon C06 from a caller. They're spec'd here for
cross-screen coherence — the actual rendering belongs to the caller's
template (E02 owns the chip + hover; this prompt describes what the
chip's modal contains).

[A] **Hover tooltip — rich popup panel** (desktop only; suppressed on
    touch). Triggered on chip mouseover. Shows a popup panel (NOT a
    text-only tooltip) listing each non-cancelled order as a row:
    order number, transaction date, status pill, total amount.
    Bottom of the panel: a small info-icon hint "click for actions".
    Click on the chip dismisses any open tooltip immediately and
    opens the modal.

[B] **Modal — cluster overview** (chip click). Always opens, even for
    a single-order EP (consistency over single-row optimisation).
    Lists each non-cancelled order as a row with:
      - Order number (left).
      - Transaction date.
      - Status pill (Paid / Unpaid / Pending / Cancelled — Cancelled
        rows hidden by default).
      - Total amount (right-aligned).
      - **Per-row action buttons**, contextual on row status:
          UNPAID / PENDING → "Mark as Paid", "Cancel"
          PAID            → "Refund" (visible only when ≥1 paid order
                                       in the cluster — gates entire
                                       action class)
      - **View order** link → /orders/{orderId} (no action focus).
    Bottom of modal: "Show cancelled (N)" toggle (default off — when
    on, cancelled orders render inline with greyed treatment).
    Action button click does NOT execute the mutation — it navigates
    to /orders/{orderId}?action=<action>. The full page opens with
    the action dialog auto-focused.

[C] **Direct route** — operators arriving via deep-link, share-link,
    or external integration (Slack / email / support tickets). Lands
    straight on the full page; no modal needed.

============================================================
Page anatomy (top to bottom — full page at /orders/{orderId})
============================================================

[1] Sticky header band (sticks on scroll)
   - Order number (left, prominent).
   - Status pill (Paid / Unpaid / Pending / Cancelled / Refunded).
   - Transaction date.
   - Billed person — name + linked `mailto:` (if email known) +
     linked `tel:` (if phone known). Note: this is `Order.buyer.person`
     — who PAID for the order. Line-item linked entities (EP /
     Membership) carry their own persons via FK and can differ
     (e.g., parent buys for child; org buys bulk membership).
     Surface both axes; don't try to collapse them.
   - Total amount.
   - Payment processor name.
   - WooCommerce external link (when `external_id` present) — small
     icon + "View on WooCommerce" link.
   - Tenant name.
   - **Status-conditional action buttons** (top-right of header band):
       UNPAID / PENDING → "Mark as Paid", "Cancel"
       PAID            → "Refund", "Resend receipt" (FU-1 — disabled
                          v1 with "Coming soon" tooltip)
       CANCELLED       → none
       REFUNDED        → none
     All buttons open their respective dialogs. The dialog also opens
     automatically if the URL carries ?action=<action>.

[2] CANCELLED-order banner (when status = CANCELLED, replaces action buttons)
   - "Cancelled on YYYY-MM-DD by *X* — *<reason>*"
   - Read-only across the whole page. No mutation affordances rendered.

[3] Line items section (collapsible — default expanded)
   - One row per `OrderLineItem`:
       - Product name.
       - Linked entity (EP name with race / Membership name with
         period; "—" when no linked entity, e.g. raffle items).
         Linked-entity links route to E09 (EP) / future Membership
         detail (membership).
       - Quantity. **Always 1 when EP / Membership is linked**;
         qty > 1 only for non-entity products. Always render the
         column for consistency.
       - Unit price.
       - Discount (when > 0; blank when 0).
       - Line total.
   - Footer row: subtotal / total breakdown.

[4] Refunds & cancellations section (collapsible — default collapsed
    if empty)
   - One row per refund event: amount, date, mode (back to original
     PaymentProcessor vs office / manual), reason, deactivate-linked-
     entities flag (for audit visibility), operator note.
   - For CANCELLED orders: cancellation record (date, reason, note).
   - Section absent (not rendered) when both lists are empty AND
     order is not CANCELLED.

[5] Cross-references panel (collapsible — default expanded)
   - **Sibling orders** — other orders for the same EP / Membership
     in the line items, resolved via OrderCriteria extension
     (`lineItemEventParticipantId.equals` / `lineItemMembershipId.
     equals`). Cancelled siblings hidden by default with a "Show
     cancelled (N)" toggle.
   - Linked EP / Membership entities — cards with name + a "View"
     link to their respective detail screens (E09 for EP; future
     Membership detail).

[6] Payment history section (FU-6 — Future)
   - Section ABSENT in v1 (DTO doesn't carry payment events yet).
   - When backend sync brings these forward (WooCommerce-side
     transaction history), this section renders between Line Items
     and Refunds — timeline of initiation / gateway redirect /
     callback / status transitions.
   - Don't draw a placeholder in v1.

============================================================
Action dialogs (modal-on-page; mirror the C04 pattern)
============================================================

All action flows are modal-on-page dialogs reached via the header
button (per current status) OR via ?action=<action> query. Same
dialog, two entry paths.

(a) **Mark as Paid** (UNPAID, PENDING)
    Dialog captures:
      - Payment method (Cash / EFT / Other) — radios.
      - Payment processor (selector — typically the Office / Manual
        processor for cash).
      - Payment reference (string; useful for EFT reference numbers).
      - Payment amount (defaults to order total; editable for partial).
      - Optional operator note (free-text).
    Submit → POST /api/orders/{id}/mark-paid → status transitions
    to PAID, payment fields persisted, downstream membership / EP
    activation cascade fires.

(b) **Cancel** (UNPAID, PENDING)
    Dialog opens with a **conditional info box at the top** when
    either condition holds (both can be visible simultaneously):

      Multi-line cascade (when order has > 1 line items):
        "This order covers more than one membership/participant.
         Cancelling will cancel all of them."

      Sole-paid-order cascade (when affected person has no other
      paid orders):
        "This is the person's only paid order. Cancelling could
         deactivate their participation/membership."

    Dialog captures:
      - Cancel reason (reference-data picker — values come from
        GET /api/cancel-reasons; initial seed: Customer cancelled,
        Duplicate order, Operator override, Unfit event, Other).
      - Optional free-text note.
    Submit → POST /api/orders/{id}/cancel → status transitions to
    CANCELLED, cancelDateTime + cancel_reason_id persisted.

(c) **Refund** (PAID)
    Dialog captures:
      - Refund amount (full or partial; defaults to order total or
        paid total).
      - Refund mode (back to original PaymentProcessor vs office /
        manual) — radios.
      - Reason (reference-data picker; same source as Cancel).
      - Deactivate-linked-entities flag (default TRUE — surfaces
        the cascade explicitly to the operator).
    Submit → POST /api/orders/{id}/refund → refundAmount +
    refundDateTime persisted, downstream cascade per the flag.
    Dependency: US #354 (refund schema + WC plugin sync — in flight).

(d) **Resend receipt** (PAID — FU-1, Future)
    v1 stub: button visually present but disabled with a "Coming
    soon" tooltip. Do NOT route to a placeholder URL. Dialog design
    can be sketched but not built.

(e) **Add order** (FU-2, Future)
    Routed entry only — no header button on C06. Reached via
    /orders/new?epId=… or ?membershipId=…. Full create flow with
    line-item authoring. v1 stubs the entry point on calling screens
    only (E02's "Add order" cell affordance for zero-order EPs).

============================================================
Action flow — submit / success / failure UX
============================================================

  Success: dialog closes, page reloads order data, success banner
           surfaces the operation summary (status delta + cascade
           summary, e.g. "Order #123 cancelled. 3 EPs deactivated.").
           Banner auto-dismisses after ~5 seconds.

  Failure: dialog stays open with inline error message; operator
           may retry or cancel.

  Partial-failure (AF-5): operation succeeds order-side but downstream
                          cascade fails (membership activation, WC
                          sync, receipt send). Surface a warning
                          banner explaining the partial state and
                          offering retry where possible. Order-side
                          mutation NOT rolled back.

============================================================
Empty + edge states
============================================================

- 404 (order not found / no access): full-page error with a back
  link to caller (use document.referrer when present; fall back to
  /events).
- AF-2: Refund button DISABLED when the order has no paid line items
  or has already been fully refunded. Tooltip explains.
- AF-3: Action affordance disabled with permission-explaining tooltip
  when the operator lacks the required role.
- Long lists (line items > 10, refunds > 5): no pagination in v1.
  The collapsible section header carries the count; if real
  production data ever pushes a section past a comfortable scroll,
  we lazy-load that section in a follow-up.

============================================================
"About this screen" info panel (C05/E06/C04 cross-cutting pattern)
============================================================

Persistent collapsible right-rail panel near the top of the page
with a short purpose paragraph + bulleted operational details:

  - What this screen shows (order detail; canonical order surface).
  - What the action buttons do at a high level (one line each).
  - Where mutations route (URL convention; ?action=).
  - Reference-data sources (cancel reasons; processors).

Default expanded on first open per browser, collapsed thereafter
(state persisted in localStorage). Same pattern applied symmetrically
on C04 / C05 / E06 — promote later to UI Design Principles.

============================================================
Style consistency
============================================================

- Sticky header band feel: similar weight to E01's title band.
- Status pills: same shape / saturation as the chips on E02.
- Action dialogs: same modal width / header / footer as C04.
- Section collapse affordance: chevron icon left of the heading,
  matches existing design system conventions.
- Tables (line items, refunds, sibling orders): plain-vanilla
  Bootstrap table density; no zebra striping on these counts.

============================================================
Output
============================================================

- HTML/JSX + matching styles for C06 covering:
  - The full page at /orders/{orderId} for each status state
    (Paid, Unpaid, Pending, Cancelled, Refunded).
  - The five action dialogs (Mark as Paid, Cancel, Refund —
    Resend Receipt and Add Order are FU stubs and only need a
    button-disabled + tooltip rendering).
  - The chip-summon modal (cluster overview) referenced from E02.
  - The hover popup panel referenced from E02.
- Screen README explaining:
  - The route + ?action= convention (canonical full page;
    sub-routes rejected).
  - The three invocation surfaces and how they relate.
  - Action flow ergonomics (modal-on-page; cascade banners;
    partial-failure handling).
  - The Cancel dialog's conditional info-box logic.
  - The "About this screen" info-panel pattern (cross-cutting
    candidate).
- Note any moments where a calling screen (E02) needs to update
  to render the chip / hover / modal correctly — that update lives
  in E02's delta prompt, but flag here if you spot ambiguity worth
  resolving before E02 lands its delta.