---
id: FAS-MBR-MEM-04
feature: FEAT-MBR-MEM-04
product_area: membership
module: memberships
revision: 1
status: proposed
product_intent: proposed
source_sha:
  services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
capabilities:
  - CAP-MBR-MEM-011
  - CAP-MBR-MEM-012
scenarios:
  - id: FAS-MBR-MEM-04-01
    title: Connect a configured application offer to its approved order
    kind: behaviour
    exercises:
      - CAP-MBR-MEM-011
      - CAP-MBR-MEM-012
    relies_on:
      - ATS-MBR-MEM-011-01
      - ATS-MBR-MEM-012-05
    preconditions: >-
      A reviewed process offers a package and a typed application chooses its
      chapter.
    steps:
      - do: >-
          Configure the offer, deliver approval, inspect the recorded decision,
          placed dues order and acknowledgement.
        expect: >-
          The approval records one decision and places the offered package with
          the chosen chapter dues while coverage remains pending.
        provenance: test
        source: >-
          services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts
    expected: >-
      The approval records one decision and places the offered package with the
      chosen chapter dues while coverage remains pending.
    negative: false
    data_needs: >-
      An isolated workspace, dated member fixtures, chapter and package
      configuration, and recording partner ports where the case requires them.
    bound_to:
      - TST-MBR-MEM-002
    provenance: test
    source:
      - >-
        services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts
      - >-
        services-membership:tests/acceptance/commerce/MBR-ACC-0346.acceptance.ts#MBR-ACC-0346
      - >-
        services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts#records
        an approval, places the dues order through the port (package and chapter
        dues), and acknowledges it
    binding_evidence:
      - suite: TST-MBR-MEM-002
        source: >-
          services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts
  - id: FAS-MBR-MEM-04-02
    title: Require the matching reviewed decision before checkout
    kind: interaction
    exercises:
      - CAP-MBR-MEM-011
      - CAP-MBR-MEM-012
    relies_on:
      - ATS-MBR-MEM-011-01
      - ATS-MBR-MEM-012-05
    preconditions: A process reviews the selected package and an application chooses it.
    steps:
      - do: >-
          Prepare checkout before a decision, then deliver approval through the
          handler that prepares and places the approved offer.
        expect: >-
          The initial checkout needs approval; the handler’s approved
          preparation permits the package and chapter dues order.
        provenance: test
        source: >-
          services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts
    expected: >-
      The initial checkout needs approval; the handler’s approved preparation
      permits the package and chapter dues order.
    negative: false
    data_needs: >-
      An isolated workspace, dated member fixtures, chapter and package
      configuration, and recording partner ports where the case requires them.
    bound_to:
      - TST-MBR-MEM-002
    provenance: test
    source:
      - >-
        services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts
      - >-
        services-membership:tests/acceptance/commerce/MBR-ACC-0346.acceptance.ts#MBR-ACC-0346
      - >-
        services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts#records
        an approval, places the dues order through the port (package and chapter
        dues), and acknowledges it
    binding_evidence:
      - suite: TST-MBR-MEM-002
        source: >-
          services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts
  - id: FAS-MBR-MEM-04-03
    title: Replace a decision without losing its typed application
    kind: lifecycle
    exercises:
      - CAP-MBR-MEM-011
      - CAP-MBR-MEM-012
    relies_on:
      - ATS-MBR-MEM-011-04
      - ATS-MBR-MEM-012-03
      - ATS-MBR-MEM-012-04
      - ATS-MBR-MEM-012-06
    preconditions: An application is in review and may have a pending purchase.
    steps:
      - do: >-
          Deliver revision required, approval, a superseding rejection and
          closing; read the application after each accepted delivery.
        expect: >-
          The same application follows the recorded outcomes; rejecting or
          closing decisions release applicable pending coverage without
          duplicating the record.
        provenance: proposed
        source: &ref_0
          - >-
            services-membership:tests/e2e/application-processes-api.e2e.spec.ts#answers
            each listed process with the packages it offers, in their order, as
            the read of the process does
          - >-
            services-membership:modules/applications/tests/unit/submissions-contracts.spec.ts#records
            a first decision
          - >-
            services-membership:modules/applications/tests/unit/submissions-contracts.spec.ts#leaves
            the application decided, awaiting the applicant or withdrawn by the
            decision’s kind
          - >-
            services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts#cancels
            the pending term of a rejected application whose purchase was placed
    expected: >-
      The same application follows the recorded outcomes; rejecting or closing
      decisions release applicable pending coverage without duplicating the
      record.
    negative: false
    data_needs: >-
      An isolated workspace, dated member fixtures, chapter and package
      configuration, and recording partner ports where the case requires them.
    bound_to: []
    provenance: proposed
    source: *ref_0
  - id: FAS-MBR-MEM-04-04
    title: Confine offer changes and application reads to their grants
    kind: permission
    exercises:
      - CAP-MBR-MEM-011
      - CAP-MBR-MEM-012
    relies_on:
      - ATS-MBR-MEM-011-01
      - ATS-MBR-MEM-012-05
    preconditions: >-
      An administrator, reader and two chapter officers have applications with
      reachable, unreachable and absent memberships.
    steps:
      - do: >-
          Create and change the process as each identity, then read and list the
          application records.
        expect: >-
          Only the manager changes the offer; scoped reads reveal only reachable
          records and unattached applications require workspace-wide authority.
        provenance: proposed
        source: &ref_1
          - >-
            services-membership:tests/acceptance/commerce/MBR-ACC-0346.acceptance.ts#MBR-ACC-0346
          - >-
            services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts#records
            an approval, places the dues order through the port (package and
            chapter dues), and acknowledges it
    expected: >-
      Only the manager changes the offer; scoped reads reveal only reachable
      records and unattached applications require workspace-wide authority.
    negative: true
    data_needs: >-
      An isolated workspace, dated member fixtures, chapter and package
      configuration, and recording partner ports where the case requires them.
    bound_to: []
    provenance: proposed
    source: *ref_1
  - id: FAS-MBR-MEM-04-05
    title: Keep repeated approval from placing or acknowledging twice
    kind: regression
    exercises:
      - CAP-MBR-MEM-011
      - CAP-MBR-MEM-012
    relies_on:
      - ATS-MBR-MEM-011-01
      - ATS-MBR-MEM-012-05
    preconditions: An approved application already has its placed order and acknowledgement.
    steps:
      - do: >-
          Redeliver the same approval and compare the recorded decision,
          order-port calls and acknowledgement-port calls.
        expect: >-
          The recorded result is returned and neither partner port receives
          another call.
        provenance: test
        source: >-
          services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts
    expected: >-
      The recorded result is returned and neither partner port receives another
      call.
    negative: false
    data_needs: >-
      An isolated workspace, dated member fixtures, chapter and package
      configuration, and recording partner ports where the case requires them.
    bound_to:
      - TST-MBR-MEM-002
    provenance: test
    source:
      - >-
        services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts
      - >-
        services-membership:tests/acceptance/commerce/MBR-ACC-0346.acceptance.ts#MBR-ACC-0346
      - >-
        services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts#records
        an approval, places the dues order through the port (package and chapter
        dues), and acknowledges it
    binding_evidence:
      - suite: TST-MBR-MEM-002
        source: >-
          services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts
evidence:
  - >-
    rhythm-v2-docs:specs/membership/memberships/planning/features/FEAT-MBR-MEM-04-membership-applications.md
  - >-
    rhythm-v2-docs:specs/membership/memberships/design/tests/: detailed
    capability scenarios and interaction cases.
  - >-
    services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts
---

# Membership Requests and Decisions: Feature Acceptance Suite

## What the Feature Must Do as a Whole

This suite tests the connection between a configured reviewed offer, the typed application and its delivered decisions. It distinguishes a recorded approval and placed purchase from committed membership coverage.

## Interactions Between Capabilities

The composite cases test the effect of a change in one capability on the records and answers of another. Detailed reliance links identify the supporting capability scenarios; an executable binding requires assertions for the complete feature case. Cases without such a binding remain proposed.

## Regression Record

| Revision | Change | Scenario | Why |
|---|---|---|---|
| 1 | initial | all | Establish cumulative feature coverage from the pinned specification and executable evidence. |