Rhythm 2.0 Specifications

Appearance

ATS-COM-FUL-001Choose delivery conditions for sold items: Capability Test Specification

Markdown

ATS-COM-FUL-001

Choose delivery conditions for sold items: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-COM-FUL-001

Design

Executed by
TST-COM-FUL-019, TST-COM-FUL-020, TST-COM-FUL-025, TST-COM-FUL-033, TST-COM-FUL-040, TST-COM-FUL-053

KindAcceptance test setProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision2

Read atservices-commerce c8b66a98react-console baf6dae3

Choose delivery conditions for sold items: Capability Test Specification ​

Coverage ​

The category map distinguishes available cases from missing proof. A covered category has a scenario; the lifecycle and permission audits retain gaps in exhaustive coverage. Proposed cases describe the intended verification and carry no execution result.

RuleScenarios
BR-CAP-COM-FUL-001-01ATS-COM-FUL-001-01
BR-CAP-COM-FUL-001-02ATS-COM-FUL-001-02
BR-CAP-COM-FUL-001-03ATS-COM-FUL-001-03
BR-CAP-COM-FUL-001-04ATS-COM-FUL-001-04, ATS-COM-FUL-001-10
BR-CAP-COM-FUL-001-05ATS-COM-FUL-001-04, ATS-COM-FUL-001-10
BR-CAP-COM-FUL-001-06ATS-COM-FUL-001-01
BR-CAP-COM-FUL-001-07ATS-COM-FUL-001-05
BR-CAP-COM-FUL-001-08ATS-COM-FUL-001-06, ATS-COM-FUL-001-11
BR-CAP-COM-FUL-001-09ATS-COM-FUL-001-07, ATS-COM-FUL-001-08
BR-CAP-COM-FUL-001-10ATS-COM-FUL-001-09

The interaction cases exercise authorize delivery from current order facts; understand and intervene in an order's delivery. They vary the upstream record or outcome and inspect the resulting work across the capability boundary. Workflow crossings also include stock, financial or application records when the flow depends on them. Existing test bindings retain their source anchors so a reviewer can distinguish supporting assertions from a complete workflow run.

Coverage

  • Rule covered
  • Transition covered
  • Validation covered
  • Permission covered
  • Edge covered
  • Failure gap: FND-COM-FUL-056
  • Boundary covered
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

11 scenarios proving CAP-COM-FUL-001; 8 bound to an existing test.

01 Invalid policy fields prevent creationvalidationapinegativetest
Proves
BR-CAP-COM-FUL-001-01 BR-CAP-COM-FUL-001-06 INV-DOM-COM-FUL-002-02
Preconditions
A policy administrator can create records.
Steps
Try a missing minimum amount, a percentage on a different condition and a negative amount.
Expected
Creation fails for each payload with its invalid field identified and no policy stored.
Data
Fixtures for invalid policy fields prevent creation.
Bound to
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#refuses a policy the contract refuses (400 naming the field), a second policy of one scope (400), a reader’s create (403) and the other tenant’s read (404)
services-commerce:modules/fulfillment/tests/e2e/fulfillment-paid-amount.e2e.spec.js#refuses a negative amount 400 naming financial_amount_minor
services-commerce:modules/fulfillment/tests/integration/services/persistence/fulfillment-policies.integration.spec.js#refuses a tenant default naming a scope, a scoped policy naming none, a policy the contract refuses, and a blank name
Source
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#refuses a policy the contract refuses (400 naming the field), a second policy of one scope (400), a reader’s create (403) and the other tenant’s read (404)
02 Scope uniqueness preserves the original policyinvariantapinegativetest
Proves
BR-CAP-COM-FUL-001-02 INV-DOM-COM-FUL-002-01
Preconditions
Product and workspace-default policies are already configured.
Steps
Attempt another policy for the product and another workspace default.
Expected
Both requests fail without replacing either existing policy.
Data
Fixtures for scope uniqueness preserves the original policy.
Bound to
services-commerce:modules/fulfillment/tests/integration/services/persistence/fulfillment-policies.integration.spec.js#refuses a second tenant default and a second policy of one scope, 400 naming the replacement
services-commerce:modules/fulfillment/tests/integration/db/register-tables.table.integration.spec.js#allows one tenant default (…_tenant_default_uidx), one policy per scope (…_scope_uq), a scope id exactly when not the default (…_scope_check), a named policy (NOT NULL once the trigger trimmed the blank)
Source
services-commerce:modules/fulfillment/tests/integration/services/persistence/fulfillment-policies.integration.spec.js#refuses a second tenant default and a second policy of one scope, 400 naming the replacement
03 Resolution chooses the closest active scoperuleunittest
Proves
BR-CAP-COM-FUL-001-03 BR-CAP-COM-FUL-001-11 INV-DOM-COM-FUL-002-03
Preconditions
Product, profile and default fixtures include an inactive policy.
Steps
Resolve delivery policy across the available scope combinations.
Expected
Selection follows product, profile, workspace and built-in precedence while ignoring inactive configuration.
Data
Fixtures for resolution chooses the closest active scope.
Bound to
services-commerce:modules/fulfillment/tests/unit/policies/policy-resolution.spec.js#takes the product’s policy over the ordering profile’s and the tenant default’s
services-commerce:modules/fulfillment/tests/unit/policies/policy-resolution.spec.js#takes the ordering profile’s when the product has none, and the tenant default’s when neither has one
services-commerce:modules/fulfillment/tests/unit/policies/policy-resolution.spec.js#falls back to the built-in default (paid in full, terms satisfy, reversal to review) with no version
services-commerce:modules/fulfillment/tests/unit/policies/policy-resolution.spec.js#passes over an inactive policy as if it were not configured
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#deletes the policies, after which the effective policy is the built-in default
Source
services-commerce:modules/fulfillment/tests/unit/policies/policy-resolution.spec.js#takes the product’s policy over the ordering profile’s and the tenant default’s
04 Saved gates retain policy and application requirementsinvariantapitest
Proves
BR-CAP-COM-FUL-001-04 BR-CAP-COM-FUL-001-05 INV-DOM-COM-FUL-002-04 INV-DOM-COM-FUL-002-05
Preconditions
A product policy applies and its application requires approval.
Steps
Place the sale and subsequently replace the configured policy.
Expected
The saved gate retains the original version and source together with required approval.
Data
Fixtures for saved gates retain policy and application requirements.
Bound to
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#freezes the product policy on the obligation with the row’s version and source, and the replacement changes nothing on it
services-commerce:modules/fulfillment/tests/unit/policies/policy-resolution.spec.js#ORs the participant’s approval and prerequisite onto the policy, and never waives what the policy asks
Source
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#freezes the product policy on the obligation with the row’s version and source, and the replacement changes nothing on it
05 Version and lock guards protect policy replacementconcurrencyapinegativetest
Proves
BR-CAP-COM-FUL-001-07 INV-DOM-COM-FUL-002-06
Preconditions
The policy's current version is two.
Steps
Submit version-one replacement, then lock the policy and attempt replacement again.
Expected
Neither request changes the policy.
Data
Fixtures for version and lock guards protect policy replacement.
Bound to
services-commerce:modules/fulfillment/tests/integration/services/persistence/fulfillment-policies.integration.spec.js#replaces a policy at the version read, refuses a stale version 409, and refuses a locked record
Source
services-commerce:modules/fulfillment/tests/integration/services/persistence/fulfillment-policies.integration.spec.js#replaces a policy at the version read, refuses a stale version 409, and refuses a locked record
06 Application updates differing pending gates without duplicationtransitionapitest
Proves
BR-CAP-COM-FUL-001-08
Preconditions
A waiting obligation retains the earlier policy.
Steps
Replace configuration, apply with an explanation and repeat application.
Expected
The changed gate and intervention are recorded on the first call; repetition leaves the gate unchanged.
Data
Fixtures for application updates differing pending gates without duplication.
Bound to
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#re-freezes the pending obligation to the replaced policy with a receipt, records the intervention, and re-freezes nothing on a repeat
Source
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#re-freezes the pending obligation to the replaced policy with a receipt, records the intervention, and re-freezes nothing on a repeat
07 Authorized work is excluded from policy applicationboundaryapinegativetest
Proves
BR-CAP-COM-FUL-001-09
Preconditions
The same scope contains pending and authorized work.
Steps
Apply its policy replacement.
Expected
The pending gate changes while authorized work keeps its gate.
Data
Fixtures for authorized work is excluded from policy application.
Bound to
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#re-freezes the gate of a waiting obligation, clearing its evaluation time, and never an authorized one
Source
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#re-freezes the gate of a waiting obligation, clearing its evaluation time, and never an authorized one
08 Application preserves blocks and prior safeguardsedgeapinegativeproposed
Proves
BR-CAP-COM-FUL-001-09
Preconditions
Pending work requires approval and another scoped obligation is blocked.
Steps
Apply a replacement without an approval requirement.
Expected
Blocked work is untouched and pending work retains its prior approval safeguard.
Data
Fixtures for application preserves blocks and prior safeguards.
Source
services-commerce:modules/fulfillment/services/policies/retroactive-policy.ts:applyPolicyRetroactively
09 Policy actions check their own permissionspermissionapinegativetest
Proves
BR-CAP-COM-FUL-001-10
Preconditions
Read-only staff and an administrator use the service.
Steps
Try reading, creating and applying as the reader, then creating as the administrator.
Expected
The reader can inspect policies but cannot create or apply them.
Data
Fixtures for policy actions check their own permissions.
Bound to
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#refuses a stale replacement 409, and the reader the apply 403
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#refuses a policy the contract refuses (400 naming the field), a second policy of one scope (400), a reader’s create (403) and the other tenant’s read (404)
Source
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#refuses a stale replacement 409, and the reader the apply 403
10 A changed payment threshold affects the next sale while the placed sale keeps its gateinteractionapiproposed
Proves
BR-CAP-COM-FUL-001-04 BR-CAP-COM-FUL-002-05
Preconditions
A product requires payment of 100 minor units. One accepted order already exists.
Steps
Replace the threshold with 200, place another order and pay 100 on both.
Expected
Compare the two gate snapshots and verdicts; only the first order is ready for delivery.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#freezes the product policy on the obligation with the row’s version and source, and the replacement changes nothing on it,services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#a minimum amount and a minimum percent are met by what was paid, never by the balance
11 Explicit policy application changes the staff-visible waiting gateinteractionapiproposed
Proves
BR-CAP-COM-FUL-001-08 BR-CAP-COM-FUL-005-01 BR-CAP-COM-FUL-002-12
Preconditions
A waiting order uses the earlier product policy. Staff can apply the replacement and inspect delivery.
Steps
Replace the policy, apply it with a reason, read the obligation, and run the eligible pending sweep.
Expected
The detail shows the replacement gate and intervention; the sweep evaluates the new condition. Reapplication adds no gate replacement.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#re-freezes the pending obligation to the replaced policy with a receipt, records the intervention, and re-freezes nothing on a repeat,services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#lists each order’s one pending obligation with the built-in default gate frozen on it, and refuses a portal member the register,services-commerce:modules/fulfillment/tests/integration/services/register/register-sweeper.integration.spec.js#finds no stale pending obligation and no overdue authorization, and nudges nothing

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software