mercadodevida/work/artifacts/F-153/implementer.md

F-153 — Implementer Evidence

Build

Feature: F-153 — Orders: associate the linked customer's email to the order read model and display it (customer email was missing despite the user having an email).

Changes (production)

• src/modules/orders/domain/order.ts — added email?: string | null to OrderView (read model). Order core aggregate is untouched (email is a denormalized read attr).
• src/modules/orders/infrastructure/pg-order-repository.ts:
  • added email: string | null to OrderRow;
  • added toOrderView(row, items) helper;
  • findById, findByIdAndUserId, findAll, search now SELECT o.*, u.email with LEFT JOIN identity_users u ON u.id = o.user_id (reuses the existing search join pattern);
  • every OrderView is built via toOrderView, so email is always populated (string | null; null when the order has no linked identity_user).
• src/modules/orders/api/orders.routes.ts:
  • serializeOrder now emits email: order.email ?? null (detail + list);
  • admin force-transition (POST /orders/:id/transitions/admin) consumes order.email (the associated email) and no longer issues a separate inline SELECT email FROM identity_users lookup → no N+1, single source of truth.

Changes (tests)

• new src/modules/orders/infrastructure/pg-order-repository.test.ts:
  • findById resolves email via the identity_users join (asserts the query contains identity_users + u.email and returns the row's email);
  • returns null when the order has no linked identity_user;
  • returns undefined when the order does not exist.
• existing OrderView literals (order-service, payments-service, checkout-service) needed no change (email is optional on the view; fixtures omit it → serialized as null).

Boundary / compatibility notes

• identity_users is referenced only as a SQL table name (pre-existing pattern in search); no TypeScript import crosses the identity↔orders boundary → lint:boundaries unchanged.
• No migration (identity_users.email already citext NOT NULL UNIQUE).
• Additive API field; no state-machine / endpoint / contract change.

Evidence (commands + results)

• npx tsc --noEmit → 0 errors (TSC_EXIT:0).
• npx vitest run → 200 passed | 56 skipped (50 files); new F-153 suite orders/infrastructure/pg-order-repository.test.ts → 3 passed.
• npx eslint (touched files) → 0 errors / 0 warnings (ESLINT_EXIT:0).
• npx prettier --check on touched files → only pre-existing baseline warnings (identical to HEAD for both pg-order-repository.ts and orders.routes.ts; my added lines are short / long string literals accepted by Prettier; no new reformatting).
• npm run lint:boundaries → 1 violation, pre-existing (security/routes R1); 0 new violations from F-153.
• git diff --check → clean (no whitespace errors).
• ./scripts/verify.sh → exit 0 (backlog 270 features valid; runtime-status advance to build/running with F-153 in_progress — see below).

Decisions

• Resolved via the read model (Option A in ADR) rather than route-layer lookups (Option B) because orders already joins identity_users in SQL for search; generalizing that join to all order reads gives the email as a first-class read attribute and removes the per-request lookup from the admin transition.