# F-153 — Product Spec

## Problem
The order read model and its serialization (`serializeOrder`) do **not** expose
the linked customer's email. `orders_orders.user_id` references `identity_users`
(whose `email citext NOT NULL UNIQUE` always exists), but the order view carries
only `userId` — never the email. Consequence:
- Order detail (`/orders/:id`, `/orders/:id/admin`) and the admin order list
  (`/orders`) never display the customer email ("customer email missing ... displayed").
- The admin force-transition (`POST /orders/:id/transitions/admin`) works around
  this with a fragile inline `SELECT email FROM identity_users WHERE id =
  order.userId`, which surfaces "El cliente no tiene email asociado" whenever the
  view itself doesn't carry the association.

## Goal
Associate the linked customer's email to the **order read model** and display it in
serialization — detail, admin list, and the admin force-transition notification —
using the order view as the single source of truth.

## Scope IN
- `orders/domain`: add `email` to `OrderView` (read model).
- `orders/infrastructure` (pg-order-repository): JOIN `identity_users` to resolve
  `email` on every order read (`findById`, `findByIdAndUserId`, `findAll`, `search`).
- `orders/api` (orders.routes): surface `email` in `serializeOrder` and consume
  `order.email` in the admin force-transition notification (removing the inline lookup).

## Scope OUT
- No changes to the `identity` domain (no TS cross-import).
- No new tables / migrations: `identity_users.email` already exists and is NOT NULL.
- No new endpoints; no auth/RBAC change; no order state machine change.

## Risk / Priority
- Priority: high. Risk: med (additive read-model field; backward compatible).