---
id: TST-COM-ORD-146
title: Participant registration
kind: integration
product_area: commerce
module: orders
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/participants/tests/integration/services/persistence/participants.integration.spec.js
implements:
  - ATS-COM-ORD-012-01
  - ATS-COM-ORD-012-02
  - ATS-COM-ORD-012-03
  - ATS-COM-ORD-012-09
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 2
isolation: >-
  The suite owns its test application declarations and registry namespaces, and removes those rows after the
  run.
evidence:
  - provenance: test
    source: >-
      services-commerce:modules/participants/tests/integration/services/persistence/participants.integration.spec.js
    test_cases:
      - 'answers the contract’s declare response: the active types, nothing deactivated, the instant'
      - >-
        writes the participant row: in-process, no ARN, the contract version it is written in, the manifest
        whole, stamped by the system actor
      - writes each product type with its declaration and the participant’s claim functions
      - 'writes each schema version, the last listed current, with the form descriptor’s URL'
      - flattens the manifest for the function as the rows above show (the pure half)
      - 'registers the same manifest again as one reconcile: the version moves, nothing else does'
      - >-
        retires a product type and a schema version no longer declared, naming the type, and updates a changed
        declaration
      - brings a retired product type back active when declared again
      - >-
        writes the order_kind a 0.3.0 manifest declares on its product type, and none on the type that
        declares none
      - 'keeps the manifest whole with the declared kind, which the registries read the type back from'
      - 'clears the kind when a later manifest declares none, as a 0.2.0 participant’s does'
      - 'a manifest that does not parse, every problem named (400 manifest_invalid)'
      - a manifest in a contract version Commerce does not support
      - >-
        a claim function that does not exist, and one the claimer role cannot execute, each named (400
        sql_function_not_executable)
      - a product type another active participant sells (the floor is the partial unique index)
      - 'the application role writing the registry itself: SELECT alone, the function the one way in'
scenario_coverage:
  - scenario: ATS-COM-ORD-012-01
    test_cases:
      - 'answers the contract’s declare response: the active types, nothing deactivated, the instant'
      - 'registers the same manifest again as one reconcile: the version moves, nothing else does'
      - >-
        retires a product type and a schema version no longer declared, naming the type, and updates a changed
        declaration
      - brings a retired product type back active when declared again
    scope: >-
      The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified
      conformance claim.
  - scenario: ATS-COM-ORD-012-02
    test_cases:
      - 'a manifest that does not parse, every problem named (400 manifest_invalid)'
      - a manifest in a contract version Commerce does not support
      - >-
        a claim function that does not exist, and one the claimer role cannot execute, each named (400
        sql_function_not_executable)
    scope: >-
      The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified
      conformance claim.
  - scenario: ATS-COM-ORD-012-03
    test_cases:
      - a product type another active participant sells (the floor is the partial unique index)
    scope: >-
      The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified
      conformance claim.
  - scenario: ATS-COM-ORD-012-09
    test_cases:
      - 'the application role writing the registry itself: SELECT alone, the function the one way in'
    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/integration/services/persistence/participants.integration.spec.js
  declared_by_test: >-
    PostgreSQL built from the migrations, the definer function, the claimer role and the fake participant's
    functions, the persistence and registration services as `rhythm_commerce_app`. Doubled: nothing.
---

# Participant registration

## Verification Boundary

The suite exercises selling-application registration or registry reads against the local integration database.

## What This Suite Proves

The registered cases check participant registration 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

PostgreSQL and the exercised Commerce persistence or workflow code are real. Remote service records, clocks and transports follow the suite’s fixtures.

## Must Not Be Doubled

The database constraints, role restrictions, locks and transactions exercised by this suite must use PostgreSQL.