---
id: TST-COM-ORD-152
title: The participant manifest across contract versions
kind: unit
product_area: commerce
module: orders
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/participants/tests/unit/registration/manifest-contract-versions.spec.js
implements:
  - ATS-COM-ORD-012-11
environment: mock
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 1
isolation: 'The suite owns its in-memory inputs, scripted responses and rendered component state.'
evidence:
  - provenance: test
    source: 'services-commerce:modules/participants/tests/unit/registration/manifest-contract-versions.spec.js'
    test_cases:
      - >-
        is accepted by the pinned contract’s own schema with an order_kind on a product type (premise:
        contracts 0.3.0)
      - 'parses a 0.3.0 manifest declaring an order_kind on every product type, keeping each kind'
      - 'parses a 0.2.0 manifest whose product types declare no order_kind, the kind left absent'
      - 'refuses an order_kind that is not a snake_case code manifest_invalid, naming the product type’s field'
      - 'hands the registry each product type’s declared order_kind, and null for a type that declares none'
      - 'classifies a sale by the declared order_kind, else by the participant’s id'
      - 'declares Merchandise’s order_kind in Commerce’s own manifest, which parses'
      - >-
        declares the reference participant’s membership type’s order_kind and leaves its other types to the
        participant’s id
      - 'keeps the stub a 0.2.0 manifest: it parses and none of its types declares an order_kind'
scenario_coverage:
  - scenario: ATS-COM-ORD-012-11
    test_cases:
      - 'classifies a sale by the declared order_kind, else by the participant’s id'
    scope: >-
      The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified
      conformance claim.
dependency_evidence:
  provenance: test
  source: 'services-commerce:modules/participants/tests/unit/registration/manifest-contract-versions.spec.js'
  declared_by_test: >-
    the contract's schema, Commerce's widening, the registration's parse, the flattening, the manifests.
    Doubled: nothing.
---

# The participant manifest across contract versions

## Verification Boundary

The unit suite checks the named contract or helper with controlled inputs.

## What This Suite Proves

The registered cases check the participant manifest across contract versions with their fixture records and assertions. Scenario bindings name only the examples those cases exercise.

## What It Does Not Prove

A registered file supplies no run result or verified conformance by itself. Local fixtures do not establish deployed cross-service behavior or complete browser journeys.

## Real Dependencies and Test Doubles

Inputs and external responses are controlled in process; this suite establishes no deployed service behavior.

## Must Not Be Doubled

The named contract validation or component behavior under assertion must use its actual implementation.