---
id: TST-COM-ORD-092
title: The shipping fence inside TX-K
kind: integration
product_area: commerce
module: orders
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/orders/tests/integration/services/cancellations/cancellation-shipping-fence.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 creates its own test workspace records and removes them using the fixture cleanup.
evidence:
  - provenance: test
    source: >-
      services-commerce:modules/orders/tests/integration/services/cancellations/cancellation-shipping-fence.integration.spec.js
    test_cases:
      - >-
        executes the cancellation: the line executed with the shipment line among its fence refs beside the
        participant’s unit refs, a cancel obligation open, the document executing
      - >-
        fences the whole range in TX-K and cancels it right after: the shipment line cancelled, the package
        pulled and its counter label voided, the shipment cancelled, the units unstamped and still picked
      - >-
        refuses the handoff asked after the cancellation (the shipment is cancelled, not manifested) and
        records the refusal
      - >-
        delivers the cancel obligation to the Merchandise participant, which releases unit 2 (allocated down
        by one) and clears the fence on the two kept; the document completes
      - 'leaves the two kept units free for a new shipment, which carries 0..1 again'
      - >-
        lets the handoff commit and refuses the execute that waited: fence_refused with the reason
        shipment_handed_off, naming the unit
      - >-
        rolls the whole transaction back: the document prepared with the refusal, no cancel obligation,
        nothing cancelled on the line, the unit shipped
      - >-
        answers must_return for the line once asked again (B9, the prepared document withdrawn first): the
        plan rejected with shipment_handed_off, nothing executed
scenario_coverage: []
dependency_evidence:
  provenance: test
  source: >-
    services-commerce:modules/orders/tests/integration/services/cancellations/cancellation-shipping-fence.integration.spec.js
  declared_by_test: >-
    PostgreSQL, the cancellation workflow, the shipping stream's fence and cancel step, the claim and fence
    functions through the claimer grant, the register's dispatcher and worker, the Merchandise participant in
    process, the manual carrier. Doubled: the queue publisher (recording), Accounting (the fixture facts and
    adjustment ports).
---

# The shipping fence inside TX-K

## Verification Boundary

The suite exercises persistence or workflow operations against the local integration database.

## What This Suite Proves

The registered cases check the shipping fence inside TX-K 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.