35 lines
1.7 KiB
Markdown
35 lines
1.7 KiB
Markdown
# 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).
|