Rhythm 2.0 Specifications

Appearance

ATS-COM-FUL-005Understand and intervene in an order's delivery: Capability Test Specification

Markdown

ATS-COM-FUL-005

Understand and intervene in an order's delivery: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-COM-FUL-005

Design

Executed by
TST-COM-FUL-021, TST-COM-FUL-022, TST-COM-FUL-025, TST-COM-FUL-039, TST-COM-FUL-040, TST-COM-FUL-054

KindAcceptance test setProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision2

Read atservices-commerce c8b66a98react-console baf6dae3

Understand and intervene in an order's delivery: 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-005-01ATS-COM-FUL-005-01, ATS-COM-FUL-005-08
BR-CAP-COM-FUL-005-02ATS-COM-FUL-005-02
BR-CAP-COM-FUL-005-03ATS-COM-FUL-005-03
BR-CAP-COM-FUL-005-04ATS-COM-FUL-005-04, ATS-COM-FUL-005-09, ATS-COM-FUL-005-11
BR-CAP-COM-FUL-005-05ATS-COM-FUL-005-04, ATS-COM-FUL-005-09, ATS-COM-FUL-005-11
BR-CAP-COM-FUL-005-06ATS-COM-FUL-005-05
BR-CAP-COM-FUL-005-07ATS-COM-FUL-005-06, ATS-COM-FUL-005-10
BR-CAP-COM-FUL-005-08ATS-COM-FUL-005-02
BR-CAP-COM-FUL-005-10ATS-COM-FUL-005-07

The interaction cases exercise choose delivery conditions for sold items; review and resolve operations findings. 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 gap: FND-COM-FUL-060
  • Failure gap: FND-COM-FUL-060
  • Boundary gap: FND-COM-FUL-060
  • Concurrency covered
  • Invariant gap: FND-COM-FUL-060
  • Interaction covered

Test Scenarios

11 scenarios proving CAP-COM-FUL-005; 7 bound to an existing test.

01 Only staff inspect the delivery registerpermissionapinegativetest
Proves
BR-CAP-COM-FUL-005-01
Preconditions
An order has delivery obligations and a portal identity is available.
Steps
List obligations and read detail as staff, then as the portal caller.
Expected
Staff receive gates and delivery history; the portal caller is denied.
Data
Fixtures for only staff inspect the delivery register.
Bound to
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/e2e/obligation-register.e2e.spec.js#answers the obligation whole with its authorization and the attempt, through the register’s read
Source
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
02 Interventions retain reasons and append-only attributionvalidationapinegativetest
Proves
BR-CAP-COM-FUL-005-02 BR-CAP-COM-FUL-005-08 INV-DOM-COM-FUL-001-07 INV-DOM-COM-FUL-001-08
Preconditions
A reader and administrator can access an order.
Steps
Try reader approval and reasonless approval, then hold and release with explanations.
Expected
Invalid actions fail; valid actions retain intervention, history and fixture audit records.
Data
Fixtures for interventions retain reasons and append-only attribution.
Bound to
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#refuses an approval to a reader, 403 permission_missing, and without a reason, 400
services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#refuses the hold to a reader (403) and without a reason (400), then places it: the obligation blocked by the staff hold
services-commerce:modules/fulfillment/tests/integration/db/register-tables.table.integration.spec.js#records an intervention of the catalogue (intervention_logs_intervention_check) and never lets the application change or remove it (42501)
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-holds.integration.spec.js#holds the unpaid obligation with the log row, the history line and the audit event, then releases it and evaluates: unpaid, it stays blocked
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#refuses an approval to a reader, 403 permission_missing, and without a reason, 400
03 Competing approvals leave one approved resultconcurrencyapitest
Proves
BR-CAP-COM-FUL-005-03 INV-DOM-COM-FUL-001-09
Preconditions
A paid obligation requires staff approval.
Steps
Submit five approvals concurrently.
Expected
One approval opens delivery and four conflicts identify that approval.
Data
Fixtures for competing approvals leave one approved result.
Bound to
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#releases the blocked obligation on one of five simultaneous approvals, which opens its gate at once since the line is paid, with the one intervention recorded; the other four are refused 409 naming it (DEF-COM-0869)
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#refuses the second once the first committed, 409 obligation_not_intervenable naming the first, whose approval stands
services-commerce:modules/fulfillment/tests/unit/register/obligation-approval.spec.js#names the approval that stands, who and when, in the message and the details
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#releases the blocked obligation on one of five simultaneous approvals, which opens its gate at once since the line is paid, with the one intervention recorded; the other four are refused 409 naming it (DEF-COM-0869)
04 Exceptional override and failed-work recovery remain distincttransitionapitest
Proves
BR-CAP-COM-FUL-005-04 BR-CAP-COM-FUL-005-05
Preconditions
One unpaid obligation waits and another has failed.
Steps
Override waiting work, then re-authorize failed work, fail it again and resolve it.
Expected
The override is attributed; recovery uses sequence two and resolution closes the failed work and exceptions.
Data
Fixtures for exceptional override and failed-work recovery remain distinct.
Bound to
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#overrides the gate of the unpaid obligation, authorizing it regardless of the facts, with the override on the obligation
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#re-authorizes the failed obligation at sequence two, which the participant fails again, then resolves it with its exceptions
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#issues the next authorization for a failed obligation, naming the previous and superseding it; refuses any other state
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#overrides the gate of the unpaid obligation, authorizing it regardless of the facts, with the override on the obligation
05 A paid obligation remains blocked by its holdruleapitest
Proves
BR-CAP-COM-FUL-005-06
Preconditions
Held pending work receives a payment.
Steps
Deliver the payment event, release the hold and attempt a hold on authorized work.
Expected
Payment does not defeat the hold, release evaluates eligibility and authorized work rejects holding.
Data
Fixtures for a paid obligation remains blocked by its hold.
Bound to
services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#keeps the gate shut while the hold stands, though the line is paid and Accounting’s event arrives
services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#releases the hold on its route, which evaluates at once and opens the gate, with the interventions, the history and the audit events
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-holds.integration.spec.js#blocks a pending obligation with the hold, keeps a blocked one blocked with the hold over its reason, and refuses an authorized one
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-holds.integration.spec.js#releases the hold (the reason and the evaluation time cleared, the state still blocked) and refuses a release of what is not held
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#keeps the gate shut while the hold stands, though the line is paid and Accounting’s event arrives
06 Manual evidence closes only work in flightvalidationapinegativetest
Proves
BR-CAP-COM-FUL-005-07
Preconditions
Fixtures contain pending and in-progress delivery.
Steps
Try completion without evidence, supply evidence, submit a late callback and try the pending work.
Expected
Only evidenced completion of in-flight work succeeds, and the later callback is rejected.
Data
Fixtures for manual evidence closes only work in flight.
Bound to
services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#refuses the manual completion without the evidence (400) and to a reader (403), then completes it with the records and the note
services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#refuses the participant’s late callback as not in flight, leaving the manual completion
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-holds.integration.spec.js#completes the in-flight obligation by hand with the evidence, closing its authorization, and refuses a pending one
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#refuses the manual completion without the evidence (400) and to a reader (403), then completes it with the records and the note
07 The delivery card respects per-action authoritypermissionbrowsernegativeproposed
Proves
BR-CAP-COM-FUL-005-10
Preconditions
Staff possess re-authorization authority alone.
Steps
Inspect Order 360 with failed and held obligations.
Expected
Re-authorization is available while resolution, hold release and override are unavailable.
Data
Fixtures for the delivery card respects per-action authority.
Source
react-console:lib/commerce/order-flows/__tests__/live.test.ts#re-authorizes an obligation on the register's route and answers the intervention it logged
08 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
09 A recovered membership releases the blocked purchase while staff retain the diagnosisinteractionapiproposed
Proves
BR-CAP-COM-FUL-003-07 BR-CAP-COM-FUL-003-06 BR-CAP-COM-FUL-005-05 BR-CAP-COM-FUL-008-03
Preconditions
Membership delivery failed permanently and its member-priced shirt is blocked. The failure is visible to staff.
Steps
Inspect and acknowledge the finding, re-authorize the membership, complete its new instruction, then inspect the shirt and retained history.
Expected
The shirt can open after membership completion; its original price remains visible. Acknowledgement alone does not release it.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/fulfillment/tests/integration/services/register/prerequisite-settlement.integration.spec.js#keeps the registration blocked when the sweep evaluates it again, and opens it once the membership is re-authorized and completes (05 §4),services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#overrides the gate of the unpaid obligation, authorizing it regardless of the facts, with the override on the obligation,services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#acknowledges then resolves the finding, with the interventions logged, the order’s history and the audit events recorded
10 Manual completion closes application delivery before a late callbackinteractionapinegativetest
Proves
BR-CAP-COM-FUL-004-07 BR-CAP-COM-FUL-005-07
Preconditions
An application left the authorized obligation in progress. Staff have manual-completion authority.
Steps
Complete with a reason and evidence, then send the application callback using the earlier authorization.
Expected
The recorded manual result remains and the late callback fails.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#refuses the manual completion without the evidence (400) and to a reader (403), then completes it with the records and the note
services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#refuses the participant’s late callback as not in flight, leaving the manual completion
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#completes the obligation and answers it as it stands; the repeat answers the same,services-commerce:modules/fulfillment/tests/e2e/obligation-holds.e2e.spec.js#refuses the manual completion without the evidence (400) and to a reader (403), then completes it with the records and the note
11 Operations intervention follows its delivery subject and refreshes the queueinteractionapiproposed
Proves
BR-CAP-COM-FUL-005-05 BR-CAP-COM-FUL-008-06
Preconditions
Operations shows a failed obligation and staff hold re-authorization authority.
Steps
Open the finding, re-authorize its obligation with a reason, and read both the new instruction and refreshed queue.
Expected
The obligation has a new authorization; the queue action does not resolve an unrelated subject.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#overrides the gate of the unpaid obligation, authorizing it regardless of the facts, with the override on the obligation,react-console:lib/commerce/operations/__tests__/rules.test.ts#asks each intervention for its own key, so holding one does not offer another

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