# F-153 — Acceptance Criteria

## AC1 — Order detail exposes customer email
`GET /orders/:id` and `GET /orders/:id/admin` responses include a top-level `email` field equal
to the linked `identity_users.email`. When the order has no linked identity_user, `email` is
`null`.

## AC2 — Admin order list exposes customer email
Every item in `GET /orders` (admin list) includes the `email` field, resolved via the same
read-model association (no N+1 per item beyond the repository's single read).

## AC3 — Admin force-transition uses the associated email
`POST /orders/:id/transitions/admin` resolves the customer email from the order view
(`order.email`) — it no longer issues a separate inline `SELECT email FROM identity_users`.
When `email` is present, the status notification is sent; when absent, it logs
"El cliente no tiene email asociado" via `request.log.warn` and still completes the transition.

## AC4 — No regression
All existing order flows keep their behavior (create, customer/admin detail, list, edit items,
shipping update, transitions). Only `email` is added to serialization; no new state transitions,
endpoints, or side effects.

## AC5 — No migration
`email` is derived from the pre-existing `identity_users.email` column; no schema migration is
required.

## AC6 — Quality gates
- `tsc --noEmit`: 0 errors.
- `prettier --check` + `eslint`: clean on touched files.
- `lint:boundaries`: no new R1/R2 violations (orders→identity_users is a SQL table-name
  reference, same as the existing `search` join; no TS cross-import).
- `vitest run`: full suite green (existing order/payments/checkout/notification tests + new
  pg-order-repository test).
- `verify.sh`: exit 0 (backlog F-153 in_progress, runtime stage valid).