---
id: TST-COM-FUL-020
title: Fulfillment policies
kind: api-lifecycle
product_area: commerce
module: fulfillment
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
repository: services-commerce
files:
  - modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js
implements:
  - ATS-COM-FUL-001-01
  - ATS-COM-FUL-001-03
  - ATS-COM-FUL-001-04
  - ATS-COM-FUL-001-06
  - ATS-COM-FUL-001-09
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
isolation: >-
  Run-created workspace identifiers and fixture records in the prepared test database; concurrency
  cases own their extra connections.
evidence:
  - repository: services-commerce
    path: modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js
    test_titles:
      - 'answers each as written, with the contract’s defaults filled in and a UUIDv7 id'
      - >-
        refuses a policy the contract refuses (400 naming the field), a second policy of one scope
        (400), a reader’s create (403) and the other tenant’s read (404)
      - 'lists them by scope kind and name with the filters, and reads one'
      - >-
        answers the effective policy: the product’s over the ordering profile’s over the tenant
        default’s
      - >-
        freezes the product policy on the obligation with the row’s version and source, and the
        replacement changes nothing on it
      - 'refuses a stale replacement 409, and the reader the apply 403'
      - >-
        re-freezes the pending obligation to the replaced policy with a receipt, records the
        intervention, and re-freezes nothing on a repeat
      - 'deletes the policies, after which the effective policy is the built-in default'
    scenario_anchors:
      - >-
        services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#refuses a
        policy the contract refuses (400 naming the field), a second policy of one scope (400), a
        reader’s create (403) and the other tenant’s read (404)
      - >-
        services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#deletes the
        policies, after which the effective policy is the built-in default
      - >-
        services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#freezes the
        product policy on the obligation with the row’s version and source, and the replacement
        changes nothing on it
      - >-
        services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#re-freezes
        the pending obligation to the replaced policy with a receipt, records the intervention, and
        re-freezes nothing on a repeat
      - >-
        services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#refuses a
        stale replacement 409, and the reader the apply 403
---

# Fulfillment policies

## Verification Boundary

This suite calls the composed local HTTP handler over the prepared database. It checks fulfillment policies through request contracts and the enforcing security boundary.

## What This Suite Proves

The bound scenarios identify the assertions this suite contributes. Source anchors retain the exact test cases; where a capability scenario has several contributing suites, a single binding does not imply that every branch runs here.

## What It Does Not Prove

Local handler execution does not establish deployed routing, queue delivery or browser behavior. It also supplies no latest result until a qualification run records one.

## Real Dependencies and Test Doubles

The database and imported Commerce persistence services are real. Fixtures create the records owned by this run. Signed local security contexts and the composed handler exercise the request boundary.

## Must Not Be Doubled

Keep the composed handler, permission enforcement, request validation and database writes real when claiming this local API coverage. Scripted financial, queue or carrier outcomes must remain visibly separate from deployed integration evidence.