# Acceptance Criteria

A feature is not complete because its page exists. It is complete only when its listed behavior works.

## Global criteria

For every feature:
- Uses the approved Nuxt architecture.
- Uses centralized Axios for API access.
- Has TypeScript request/response models where applicable.
- Uses Nuxt UI for standard controls.
- Does not duplicate Nuxt UI with custom components.
- Has loading, empty, error, and validation states where relevant.
- Handles API failures without corrupting local state.
- Respects backend-provided permissions.
- Is responsive.
- Meets basic keyboard/accessibility requirements.
- Has relevant tests.
- Does not invent authoritative backend behavior.

## Storefront
- User can navigate categories/brands.
- Featured/new/promotional products render from API data.
- Search entry is accessible.
- Product links resolve to detail pages.
- Empty/error/loading states are useful.

## Authentication
- Valid credentials create the expected frontend session state.
- Invalid credentials show useful feedback.
- Pending/disabled/unauthorized states are handled.
- Logout clears appropriate local session state.
- Protected routes redirect appropriately.
- No frontend guard is treated as real authorization.

## Registration
- Required fields validate before submission.
- API validation errors map to fields/messages.
- Pending approval is represented correctly.
- Successful registration does not falsely imply approval.

## Catalog
- Category/brand/search pages support their specified filters/sorts/pagination.
- Product cards/listings show API-provided price/availability correctly.
- Product detail exposes all applicable catalog information.
- Unavailable products cannot be falsely represented as orderable.
- Filters can be cleared.
- Mobile filtering remains usable.

## Pricing
- Customer-specific prices are displayed from API data.
- Quantity tiers update the UI using authoritative API pricing.
- Discounts/promotions are explained when data is available.
- Expired/ineligible promotions are not presented as active.
- Client-side price calculations are never treated as final.

## Quick order
- SKU lookup identifies products.
- Multiple lines can be entered.
- Invalid rows are individually understandable.
- MOQ/availability errors are visible.
- Valid rows can be added without silently losing invalid rows.

## Bulk import
- Invalid files are rejected.
- Rows are previewed before destructive/commerce action.
- Row errors identify the affected row.
- Valid rows can be submitted.
- Invalid rows cannot silently become valid products.

## Cart
- Quantity changes are reflected correctly.
- Remove works.
- Backend validation errors are visible.
- Price/promotion changes are explicitly surfaced.
- MOQ/minimum-order constraints are visible.
- Final totals come from authoritative API data.

## Checkout
- Every configured checkout step can be completed.
- Required fields cannot be skipped.
- Changing an upstream choice invalidates dependent selections when required.
- Submit cannot be accidentally duplicated.
- Unknown submission result is handled safely.
- Confirmation uses the authoritative order result.

## Payments
- Available payment methods reflect API state.
- Instructions match API data.
- Upload validates file constraints.
- Payment status comes from the API.
- Gateway return states are handled.
- Frontend never declares payment successful independently.

## Orders
- List supports specified search/filter/sort/pagination.
- Detail contains all applicable order data.
- Status is clearly represented.
- Tracking is accessible.
- Reorder retrieves current price/availability rather than blindly reusing old totals.
- Cancellation only appears when allowed.

## Shipping
- Address selection is correct.
- Shipping methods/rates come from API.
- Delivery estimates are displayed only when supplied.
- Tracking uses API-provided carrier/reference/status.
- Split shipments are distinguishable.

## Notifications
- Unread state is clear.
- Mark-read behavior is synchronized with API.
- Notification preferences persist through API.
- Commerce events are understandable.

## Returns/refunds
- Only eligible items/actions are offered.
- Request validation is explicit.
- Status comes from API.
- Refund amounts/statuses are not fabricated.

## Documents
- Only customer-facing commerce documents are shown.
- Downloads/print actions work when API provides documents.
- Missing/expired documents have clear states.

## E-commerce admin
- Admin routes require appropriate backend permissions.
- Customer/catalog/promotion/order/payment operations use API authority.
- CRUD actions reflect API success/failure.
- No ERP/accounting screens are introduced.
- Analytics are e-commerce-focused.

## Hard exclusion acceptance

The finished application must NOT contain navigation, pages, services, or components implementing:
- general ledger
- AP/AR
- financial reconciliation
- procurement
- supplier management
- warehouse management
- inventory ledger
- manufacturing
- HR/payroll
- fixed assets
- unrelated ERP workflows