--- id: TST-COM-ORD-035 title: 'Placement, TX-P' kind: api-lifecycle product_area: commerce module: orders revision: 1 status: draft source_sha: services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b repository: services-commerce files: - modules/checkout/tests/e2e/placement.e2e.spec.js implements: - ATS-COM-ORD-005-01 - ATS-COM-ORD-005-02 - ATS-COM-ORD-005-03 - ATS-COM-ORD-005-05 - ATS-COM-ORD-005-09 - ATS-COM-ORD-005-10 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/checkout/tests/e2e/placement.e2e.spec.js' test_cases: - >- answers 200 with the order: numbered 10000, placed, pending billing, pay now with a thirty-minute tender window, created - 'stamps every item line’s price_as_of with the order’s placed_at, one instant (COMM-M2 R2-2)' - freezes no billing address when CRM holds none for the bill-to party (COMM-M2 R2-2) - >- writes one line per item with its frozen purchase: the canonical payload, the stub’s attestation, the plan, no claim - >- reads the order whole: lines, purchases, tenders (none), invoices (none), the two pending obligations, the placed event - >- leaves the checkout placed, naming the order, its items frozen with what prepare attested, and its trail telling the story - >- answers the same order to a retry under the same key, replayed from the idempotency ledger, writing nothing (08 row 9; D11) - 'refuses a placement of the placed checkout under another key, 409 idempotency_key_mismatch' - 'lists the member’s orders, newest first, bounded' - places the pin under the shirt with its parent_line_id naming the shirt’s line - >- one places the order; the other is told the request is in progress (409) or answered the one order; exactly one order row exists - answers 409 placement_refused with the participant’s problem naming the item - 'placed nothing: no order, the checkout still open with its items unfrozen, the refusal on its trail' - refuses an item the stub answers unavailable the same way (sold out) - 'refuses an empty checkout, and a placement without an Idempotency-Key' - >- refuses PRICE_CHANGED with both prices when the price rose since a preview of a moment ago, the checkout left open - 'refuses a price that fell the same way: the amount shown never changes silently' - 'binds the new price once the customer previews again, with no price_tolerance adjustment' - 'records no tolerance on the order: its pricing snapshot names neither the window nor the switch' - 'proceeds at the recomputed price when the preview equals it, and when there was no preview' - >- binds a never-previewed checkout at the price of the moment, even one that moved since the checkout opened scenario_coverage: - scenario: ATS-COM-ORD-005-01 test_cases: - >- answers the same order to a retry under the same key, replayed from the idempotency ledger, writing nothing (08 row 9; D11) - 'refuses a placement of the placed checkout under another key, 409 idempotency_key_mismatch' scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-005-02 test_cases: - >- one places the order; the other is told the request is in progress (409) or answered the one order; exactly one order row exists scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-005-03 test_cases: - >- refuses PRICE_CHANGED with both prices when the price rose since a preview of a moment ago, the checkout left open - 'refuses a price that fell the same way: the amount shown never changes silently' - 'binds the new price once the customer previews again, with no price_tolerance adjustment' - >- binds a never-previewed checkout at the price of the moment, even one that moved since the checkout opened scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-005-05 test_cases: - answers 409 placement_refused with the participant’s problem naming the item - 'placed nothing: no order, the checkout still open with its items unfrozen, the refusal on its trail' - refuses an item the stub answers unavailable the same way (sold out) scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-005-09 test_cases: - >- answers 200 with the order: numbered 10000, placed, pending billing, pay now with a thirty-minute tender window, created - 'stamps every item line’s price_as_of with the order’s placed_at, one instant (COMM-M2 R2-2)' - freezes no billing address when CRM holds none for the bill-to party (COMM-M2 R2-2) scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-005-10 test_cases: - >- writes one line per item with its frozen purchase: the canonical payload, the stub’s attestation, the plan, no claim - places the pin under the shirt with its parent_line_id naming the shirt’s line - >- reads the order whole: lines, purchases, tenders (none), invoices (none), the two pending obligations, the placed event - >- leaves the checkout placed, naming the order, its items frozen with what prepare attested, and its trail telling the story 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/checkout/tests/e2e/placement.e2e.spec.js' declared_by_test: >- the composed handler, the routes, the workflows, the stub participant, the pricing engine, the persistence services, the number seed and PostgreSQL. Doubled: the signing key pair and the other services' tables (local stand-ins). The persistence-level race under a lock-wait barrier is `modules/orders/tests/integration/services/persistence/orders.integration.spec.js`. --- # Placement, TX-P ## Verification Boundary The suite drives the composed local API dispatcher and its registered routes. ## What This Suite Proves The registered cases check placement, TX-P 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.