---
id: TST-COM-CAT-135
title: Offers Verification
kind: api-lifecycle
product_area: commerce
module: catalog
revision: 1
status: draft
product_intent: proposed
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/recommendations/tests/e2e/offers.e2e.spec.js
implements:
  - ATS-COM-CAT-020-01
  - ATS-COM-CAT-020-02
  - ATS-COM-CAT-020-03
  - ATS-COM-CAT-020-04
  - ATS-COM-CAT-020-05
  - FAS-COM-CAT-05-01
  - FAS-COM-CAT-05-05
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 2
isolation: 'Suite-owned workspace keys and database fixtures, removed by its cleanup hooks.'
binding_evidence:
  - scenario: ATS-COM-CAT-020-01
    source: >-
      services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#answers one offer: the
      mug, from the listing, priced $12.00 by the quote, live, to add to the checkout, expiring with
      the quote
  - scenario: ATS-COM-CAT-020-01
    source: >-
      services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#adds the mug to the
      checkout with the offer on the item when accepted
  - scenario: ATS-COM-CAT-020-01
    source: >-
      services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#answers the first
      acceptance to a second, repeated, adding nothing
  - scenario: ATS-COM-CAT-020-01
    source: >-
      services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#offers nothing a second
      time: the mug is in the checkout and was accepted
  - scenario: ATS-COM-CAT-020-02
    source: >-
      services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#records the dismissal
      once, the second answering the first
  - scenario: ATS-COM-CAT-020-02
    source: >-
      services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#offers nothing inside
      the dismissal window
  - scenario: ATS-COM-CAT-020-02
    source: >-
      services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#refuses the first
      member accepting what was presented to the other, 403 offer_not_yours
  - scenario: ATS-COM-CAT-020-03
    source: >-
      services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#is refused 409
      offer_expired, naming when it expired
  - scenario: ATS-COM-CAT-020-04
    source: >-
      services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#sees the mug as an
      estimate at the public price, for a session subject
  - scenario: ATS-COM-CAT-020-04
    source: >-
      services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#cannot have the
      estimate accepted, even by a signed-in member: 409 sign_in_required
  - scenario: ATS-COM-CAT-020-04
    source: >-
      services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#is refused a placement
      that admits no anonymous visitor, 403 placement_not_public
  - scenario: ATS-COM-CAT-020-05
    source: >-
      services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#is refused to a portal
      member, 403 preview_not_allowed, and answers the console the suppressed rules without writing
  - scenario: FAS-COM-CAT-05-01
    source: 'services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js'
  - scenario: FAS-COM-CAT-05-05
    source: 'services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js'
evidence:
  - 'services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js'
  - >-
    services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#Real: the composed
    handler, the routes, the evaluation, the quote and the engine, the checkout workflows, the stub
    participant, the placement, the persistence and PostgreSQL.
  - >-
    services-commerce:modules/recommendations/tests/e2e/offers.e2e.spec.js#Doubled: the signing key
    pair, and Accounting's, CRM's and Platform's tables, which are local stand-ins.
execution_constraints:
  - No execution is performed in this documentation back-fill.
verification_boundary: >-
  Bindings identify the existing assertions contributing to each scenario; several suites can
  jointly cover a compound scenario.
---

# Offers Verification

## Verification Boundary

The composed API handler runs locally with signed caller contexts and the integration database. Its route, mapping, permission and persistence assertions establish the local API boundary.

## What This Suite Proves

The offers assertions contribute to the scenarios listed in the register. Each binding retains its exact source test anchor so a reviewer can distinguish an individual contribution from the complete scenario.

## What It Does Not Prove

The register records source inspection only. It establishes no run result, delivery qualification or Product approval.

## Real Dependencies and Test Doubles

PostgreSQL and the services called by the suite are real. External service ports, file storage and queues may use the fixtures declared by the suite and its support helpers.

## Must Not Be Doubled

Keep the asserted database constraints, transactions, service functions and execution contexts real. For API suites, preserve the dispatcher and permission enforcement.