# F-154 — Acceptance Criteria

## AC1 — Customers list shows only storefront customers
`GET /users` (admin) devuelve SOLO usuarios con `role = 'customer'`. Un usuario
interno (admin/editor) NO aparece en el listado. El buscador `q` sigue filtrando sobre email
dentro de los clientes.

## AC2 — Users list shows only internal/backoffice users
`GET /admin/users` (admin, default sin `?role=`) devuelve SOLO usuarios con
`role != 'customer'` (admin/editor/pos). Un cliente (`role = 'customer'`) NO aparece.
`?role=admin` y `?role=editor` siguen afinando dentro de internos; `?role=customer`
NO devuelve clientes (devuelve vacío) — la separación está forzada en backend.

## AC3 — No regression on user profile / addresses
`/users/:id` (GET/PATCH) owner-or-admin sigue devolviendo/editando CUALQUIER usuario
sin filtro por rol (admin ve perfil de cliente; cliente ve el suyo). CRUD de
`/users/:id/addresses` inalterado.

## AC4 — No boundary / injection violation
- `identity_users` referenciado solo como tabla SQL (sin import TS).
- Valores `q`/`role` parametrizados; el literal `'customer'`/`'customer'` es constante de código.
- Sin migración.

## AC5 — Quality gates
- `tsc --noEmit` (API) 0 errores; `npx tsc --noEmit` (apps/admin) sin errores nuevos.
- `npm run lint:boundaries` sin violaciones nuevas.
- `vitest run` (sin DB) → suite nueva F-154 + suite existente en verde.
- `verify.sh` exit 0 (backlog F-154 in_progress, runtime stage válido).