---
id: TST-COM-ORD-147
title: Participant registry reads
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.queries.integration.spec.js
implements: []
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.queries.integration.spec.js
    test_cases:
      - 'reads a participant by id, and none for an unknown id'
      - 'lists the active participants in id order, the stub and the fake among them'
      - 'lists a participant’s active product types in product type order, with how each is sold'
      - 'finds the active owner of a product type with its declaration, and none for a type nobody sells'
      - 'lists a schema’s versions in version order, the current one marked'
      - >-
        answers the catalog: every sellable type an active participant declares, with the participant and the
        schema versions; not an unsellable or an unowned type
      - 'answers each catalog type’s order_kind: the kind its manifest declares, else the participant’s id'
scenario_coverage: []
dependency_evidence:
  provenance: test
  source: >-
    services-commerce:modules/participants/tests/integration/services/persistence/participants.queries.integration.spec.js
  declared_by_test: >-
    PostgreSQL, the registration, the persistence reads as `rhythm_commerce_app`, Accounting's product types
    stand-in.
---

# Participant registry reads

## 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 registry reads 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.