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).

1.7 KiB Raw Blame History