--- id: ATS-COM-FUL-001 scope: CAP-COM-FUL-001 product_area: commerce module: fulfillment revision: 2 status: proposed approved_by: null approved_at: null source_sha: services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b react-console: baf6dae382d6f41dce976c7f848667ccc37e076f scenarios: - id: ATS-COM-FUL-001-01 title: Invalid policy fields prevent creation level: api 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. negative: true data_needs: 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 - TST-COM-FUL-020 - TST-COM-FUL-019 - TST-COM-FUL-033 provenance: test 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) category: validation - id: ATS-COM-FUL-001-02 title: Scope uniqueness preserves the original policy level: api 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. negative: true data_needs: 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) - TST-COM-FUL-033 - TST-COM-FUL-025 provenance: test 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 category: invariant - id: ATS-COM-FUL-001-03 title: Resolution chooses the closest active scope level: unit 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. negative: false data_needs: 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 - TST-COM-FUL-053 - TST-COM-FUL-020 provenance: test 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 category: rule - id: ATS-COM-FUL-001-04 title: Saved gates retain policy and application requirements level: api 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. negative: false data_needs: 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#freezes the picked policy with its version and source - >- 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 - TST-COM-FUL-020 - TST-COM-FUL-053 provenance: test 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 category: invariant - id: ATS-COM-FUL-001-05 title: Version and lock guards protect policy replacement level: api 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. negative: true data_needs: 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 - TST-COM-FUL-033 provenance: test 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 category: concurrency - id: ATS-COM-FUL-001-06 title: Application updates differing pending gates without duplication level: api 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. negative: false data_needs: >- 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 - TST-COM-FUL-020 provenance: test 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 category: transition - id: ATS-COM-FUL-001-07 title: Authorized work is excluded from policy application level: api 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. negative: true data_needs: 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 - TST-COM-FUL-040 provenance: test 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 category: boundary - id: ATS-COM-FUL-001-08 title: Application preserves blocks and prior safeguards level: api 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. negative: true data_needs: Fixtures for application preserves blocks and prior safeguards. bound_to: [] provenance: proposed source: >- services-commerce:modules/fulfillment/services/policies/retroactive-policy.ts:applyPolicyRetroactively category: edge - id: ATS-COM-FUL-001-09 title: Policy actions check their own permissions level: api 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. negative: true data_needs: 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) - TST-COM-FUL-020 provenance: test source: >- services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#refuses a stale replacement 409, and the reader the apply 403 category: permission - id: ATS-COM-FUL-001-10 title: >- A changed payment threshold affects the next sale while the placed sale keeps its gate category: interaction level: api proves: - BR-CAP-COM-FUL-001-04 - BR-CAP-COM-FUL-002-05 exercises: - CAP-COM-FUL-001 - CAP-COM-FUL-002 relies_on: - ATS-COM-FUL-001-04 - ATS-COM-FUL-002-04 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. negative: false data_needs: >- An isolated workspace with the products, records, authority and quantities described in the preconditions. bound_to: [] provenance: proposed 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 - id: ATS-COM-FUL-001-11 title: Explicit policy application changes the staff-visible waiting gate category: interaction level: api proves: - BR-CAP-COM-FUL-001-08 - BR-CAP-COM-FUL-005-01 - BR-CAP-COM-FUL-002-12 exercises: - CAP-COM-FUL-001 - CAP-COM-FUL-005 - CAP-COM-FUL-002 relies_on: - ATS-COM-FUL-001-06 - ATS-COM-FUL-005-01 - ATS-COM-FUL-002-09 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. negative: false data_needs: >- An isolated workspace with the products, records, authority and quantities described in the preconditions. bound_to: [] provenance: proposed 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 evidence: - repository: services-commerce tests: - >- 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 - >- 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) - >- 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 - >- 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#freezes the picked policy with its version and source - >- 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 - >- 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 - >- 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/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 - >- services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#refuses a stale replacement 409, and the reader the apply 403 - repository: react-console tests: [] 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 coverage_notes: failure: >- No scenario specifically isolates this dimension; the coverage finding retains the missing proof. transition_audit: [] permission_audit: - key: commerce.fulfillment-policies.read where_checked: api coverage: 'gap: FND-COM-FUL-056' note: >- Per-key positive and negative coverage is not separately mapped; permission scenarios retain the observed aggregate tests. - key: commerce.fulfillment-policies.create where_checked: api coverage: 'gap: FND-COM-FUL-056' note: >- Per-key positive and negative coverage is not separately mapped; permission scenarios retain the observed aggregate tests. - key: commerce.fulfillment-policies.update where_checked: api coverage: 'gap: FND-COM-FUL-056' note: >- Per-key positive and negative coverage is not separately mapped; permission scenarios retain the observed aggregate tests. - key: commerce.fulfillment-policies.delete where_checked: api coverage: 'gap: FND-COM-FUL-056' note: >- Per-key positive and negative coverage is not separately mapped; permission scenarios retain the observed aggregate tests. - key: commerce.fulfillment-policies.apply where_checked: api coverage: 'gap: FND-COM-FUL-056' note: >- Per-key positive and negative coverage is not separately mapped; permission scenarios retain the observed aggregate tests. related_audit: - capability: CAP-COM-FUL-002 scenarios: - ATS-COM-FUL-001-10 - ATS-COM-FUL-001-11 - capability: CAP-COM-FUL-005 scenarios: - ATS-COM-FUL-001-11 invariant_audit: - invariant: INV-DOM-COM-FUL-001-01 scenarios: - ATS-COM-FUL-004-07 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/db/obligations.table.ts:obligations_subject_uq - invariant: INV-DOM-COM-FUL-001-02 scenarios: - ATS-COM-FUL-004-07 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/services/persistence/obligations.ts:OBLIGATION_TRANSITIONS; db/migrations/20261018004016_obligation_register.sql:refuse_obligation_regression - invariant: INV-DOM-COM-FUL-001-03 scenarios: - ATS-COM-FUL-004-07 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/db/obligations.table.ts:obligations_authorization_state_check - invariant: INV-DOM-COM-FUL-001-04 scenarios: - ATS-COM-FUL-004-03 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/db/obligations.table.ts:obligations_quantity_check - invariant: INV-DOM-COM-FUL-001-05 scenarios: - ATS-COM-FUL-002-08 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/services/persistence/obligations.ts:openGate - invariant: INV-DOM-COM-FUL-001-06 scenarios: - ATS-COM-FUL-004-02 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/services/persistence/obligations.ts:recordObligationOutcome - invariant: INV-DOM-COM-FUL-001-07 scenarios: - ATS-COM-FUL-005-02 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/db/obligation-attempts.table.ts; modules/fulfillment/db/intervention-logs.table.ts (UPDATE, DELETE and TRUNCATE revoked) - invariant: INV-DOM-COM-FUL-001-08 scenarios: - ATS-COM-FUL-005-02 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/services/register/obligation-interventions.ts - invariant: INV-DOM-COM-FUL-001-09 scenarios: - ATS-COM-FUL-005-03 coverage: covered provenance: test source: >- services-commerce:docs/migrations/obligation-register/README.md#D-P4-16 (obligation-register.e2e five simultaneous approvals) - invariant: INV-DOM-COM-FUL-001-10 scenarios: - ATS-COM-FUL-006-03 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/db/enforcements.table.ts:enforcements_cause_uq - invariant: INV-DOM-COM-FUL-001-11 scenarios: - ATS-COM-FUL-002-07 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/services/facts/financial-facts-handler.ts - invariant: INV-DOM-COM-FUL-001-12 scenarios: [] coverage: 'gap: FND-COM-FUL-056' provenance: observed source: >- services-commerce:modules/fulfillment/db/obligations.table.ts (composite RESTRICT keys) - invariant: INV-DOM-COM-FUL-002-01 scenarios: - ATS-COM-FUL-001-02 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/db/fulfillment-policies.table.ts:fulfillment_policies_scope_uq,fulfillment_policies_tenant_default_uidx,fulfillment_policies_scope_check - invariant: INV-DOM-COM-FUL-002-02 scenarios: - ATS-COM-FUL-001-01 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/services/persistence/fulfillment-policies.ts:storedPolicy - invariant: INV-DOM-COM-FUL-002-03 scenarios: - ATS-COM-FUL-001-03 coverage: covered provenance: test 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 - invariant: INV-DOM-COM-FUL-002-04 scenarios: - ATS-COM-FUL-001-04 coverage: covered provenance: test 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 - invariant: INV-DOM-COM-FUL-002-05 scenarios: - ATS-COM-FUL-001-04 coverage: covered provenance: documented source: 'services-commerce:docs/migrations/obligation-register/README.md#D-P4-05' - invariant: INV-DOM-COM-FUL-002-06 scenarios: - ATS-COM-FUL-001-05 coverage: covered provenance: observed source: >- services-commerce:modules/fulfillment/services/persistence/fulfillment-policies.ts:updateFulfillmentPolicy --- # 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. | Rule | Scenarios | |---|---| | `BR-CAP-COM-FUL-001-01` | `ATS-COM-FUL-001-01` | | `BR-CAP-COM-FUL-001-02` | `ATS-COM-FUL-001-02` | | `BR-CAP-COM-FUL-001-03` | `ATS-COM-FUL-001-03` | | `BR-CAP-COM-FUL-001-04` | `ATS-COM-FUL-001-04`, `ATS-COM-FUL-001-10` | | `BR-CAP-COM-FUL-001-05` | `ATS-COM-FUL-001-04`, `ATS-COM-FUL-001-10` | | `BR-CAP-COM-FUL-001-06` | `ATS-COM-FUL-001-01` | | `BR-CAP-COM-FUL-001-07` | `ATS-COM-FUL-001-05` | | `BR-CAP-COM-FUL-001-08` | `ATS-COM-FUL-001-06`, `ATS-COM-FUL-001-11` | | `BR-CAP-COM-FUL-001-09` | `ATS-COM-FUL-001-07`, `ATS-COM-FUL-001-08` | | `BR-CAP-COM-FUL-001-10` | `ATS-COM-FUL-001-09` | ## Interactions With Related Capabilities 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.