feat(F-153): completed feature

spec/acceptance.md

@@ -1,37 +1,34 @@
-# F-152 — Acceptance Criteria
+# F-153 — Acceptance Criteria
 
-- Feature ID: F-152
+## 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`.
 
-## Account creation → welcome email
-- Escenario: customer registers with a new email.
-  - Given SMTP is configured and `POST /auth/register` is called with valid email+password
-  - When registration succeeds
-  - Then a welcome email (`account_created`) is sent to that email
-  - And the response is still 200 with the user payload
-  - And evidence: SMTP sendmail called once with recipient == input email and template account_created
-- Escenario: SMTP is not configured.
-  - Given SMTP is not configured and `POST /auth/register` is called
-  - When registration succeeds
-  - Then the response is still 200 (registration never fails due to email)
-  - And a warning is logged
+## 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).
 
-## Order confirmation on payment success
-- Escenario: customer pays and Stripe reports PaymentSucceeded.
-  - Given an order in AWAITING_PAYMENT and a valid `PaymentSucceeded` webhook
-  - When the webhook is processed
-  - Then the order moves to PAID
-  - And a confirmation email (`state: PAID`) is sent to the order's customer email via sendOrderStatusEmail
-  - And the webhook returns 2xx
-- Escenario: duplicate webhook.
-  - Given the same PaymentSucceeded webhook delivered twice
-  - When the second is processed
-  - Then only one confirmation email is sent (idempotency from payment dedup / outcome.kind == duplicate skipped)
-- Escenario: SMTP not configured.
-  - Given SMTP not configured and a PaymentSucceeded webhook arrives
-  - When processed
-  - Then the order still moves to PAID, webhook returns 2xx, and an email failure is logged (not thrown)
+## 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.
 
-## Regression
-- verify.sh is green
-- No existing order admin-transition email behavior changed
-- Password-reset email flow unchanged
+## 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).