---
id: TST-COM-ORD-153
title: The in-process participant registry
kind: unit
product_area: commerce
module: orders
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/participants/tests/unit/registry/in-process-registry.spec.js
implements: []
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/registry/in-process-registry.spec.js'
    test_cases:
      - >-
        answers the stub’s two product types with their owner and current schema version, and nothing for
        another type
      - >-
        parses a payload as the schema version named, refusing an unknown version and a payload outside the
        schema by path
      - >-
        refuses a manifest the contract refuses, two owners of one product type, and a schema named but not
        declared
      - >-
        answers ok for a simple item and requires_approval for a reviewed one, each attested over its
        canonical payload
      - 'canonicalises a payload by sorting its keys at every depth, so equal payloads hash alike'
      - 'refuses an item whose payload asks it to, and answers unavailable for one marked so'
      - refuses a request outside the contract
      - reads the caller’s purchasing subject of contracts 0.2.0 and refuses a subject that is not a party
      - 'answers conflict to every lease confirmation: it holds nothing'
      - 'refuses every hold extension: it holds nothing'
scenario_coverage: []
dependency_evidence:
  provenance: test
  source: 'services-commerce:modules/participants/tests/unit/registry/in-process-registry.spec.js'
  declared_by_test: 'the registry, the stub, the contract''s schemas. Doubled: nothing.'
---

# The in-process participant registry

## Verification Boundary

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

## What This Suite Proves

The registered cases check the in-process participant registry 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.