--- id: FAS-MBR-MEM-05 feature: FEAT-MBR-MEM-05 product_area: membership module: memberships revision: 1 status: proposed product_intent: proposed source_sha: services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f capabilities: - CAP-MBR-MEM-013 - CAP-MBR-MEM-014 scenarios: - id: FAS-MBR-MEM-05-01 title: Review a renewal plan before executing its work kind: behaviour exercises: - CAP-MBR-MEM-013 relies_on: - ATS-MBR-MEM-013-02 - ATS-MBR-MEM-013-06 - ATS-MBR-MEM-013-08 preconditions: A reusable template selects renewing and lapsed members. steps: - do: >- Create a run from the template, plan it, review counts and actions, then execute with recording partner ports. expect: >- The reviewed run keeps its copied settings and settles the planned orders, notices and drops with observable action outcomes. provenance: proposed source: &ref_0 - >- services-membership:tests/e2e/billing-api.e2e.spec.ts#creates a template - >- services-membership:modules/billing/tests/unit/run-plan.spec.ts#counts the candidates, their classes, the exclusions and the planned actions - >- services-membership:modules/billing/tests/integration/billing-runs.integration.spec.ts#executes on the jobs engine: one order per renewing candidate (Jo’s with both dues chapters), a notice and reminder each, one drop per lapsed term expected: >- The reviewed run keeps its copied settings and settles the planned orders, notices and drops with observable action outcomes. 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-05-02 title: Make a billing drop remove its expiry attention kind: interaction exercises: - CAP-MBR-MEM-013 - CAP-MBR-MEM-014 relies_on: - ATS-MBR-MEM-013-08 - ATS-MBR-MEM-014-07 preconditions: Publication is enabled and a lapsed candidate has an open expiry item. steps: - do: >- Plan a drop-only run, execute it, and inspect the closed period and original attention item. expect: >- The configured drop reason is recorded and the existing item resolves with the closing write. provenance: proposed source: &ref_1 - >- services-membership:modules/billing/tests/integration/billing-runs.integration.spec.ts#executes on the jobs engine: one order per renewing candidate (Jo’s with both dues chapters), a notice and reminder each, one drop per lapsed term - >- services-membership:modules/memberships/tests/integration/services/expiring-memberships.integration.spec.ts#resolves the item renewed in the staff renewal’s transaction expected: >- The configured drop reason is recorded and the existing item resolves with the closing write. 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_1 - id: FAS-MBR-MEM-05-03 title: Create one planned run for a repeated scheduled occurrence kind: lifecycle exercises: - CAP-MBR-MEM-013 relies_on: - ATS-MBR-MEM-013-10 - ATS-MBR-MEM-013-11 preconditions: An active recurring configuration has a due local occurrence date. steps: - do: >- Deliver the occurrence, redeliver it, then inspect the generated run and plan on the occurrence date. expect: >- Both deliveries refer to one run with one plan for the intended business day. provenance: test source: >- services-membership:modules/billing/tests/integration/billing-runs.integration.spec.ts expected: >- Both deliveries refer to one run with one plan for the intended business day. 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-004 provenance: test source: - >- services-membership:modules/billing/tests/integration/billing-runs.integration.spec.ts - >- services-membership:modules/billing/tests/integration/billing-runs.integration.spec.ts#creates and plans one run per occurrence of a recurring run, a redelivered occurrence finding it - >- services-membership:modules/billing/tests/integration/recurring-billing-run-concurrency.integration.spec.ts#applies one of two changes made at the same version and refuses the other with version_mismatch binding_evidence: - suite: TST-MBR-MEM-004 source: >- services-membership:modules/billing/tests/integration/billing-runs.integration.spec.ts - id: FAS-MBR-MEM-05-04 title: Allow billing inspection while refusing planning to a reader kind: permission exercises: - CAP-MBR-MEM-013 relies_on: - ATS-MBR-MEM-013-12 preconditions: >- A manager creates a template and its run; a reader has only billing-read authority. steps: - do: >- Read the manager’s run as the reader, then attempt planning with the same reader context. expect: The run reads successfully and planning returns a forbidden response. provenance: test source: 'services-membership:tests/e2e/billing-api.e2e.spec.ts' expected: The run reads successfully and planning returns a forbidden response. 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: - TST-MBR-MEM-238 provenance: test source: - 'services-membership:tests/e2e/billing-api.e2e.spec.ts' - >- services-membership:tests/e2e/billing-api.e2e.spec.ts#lets a reader read the run and refuses it the planning binding_evidence: - suite: TST-MBR-MEM-238 source: 'services-membership:tests/e2e/billing-api.e2e.spec.ts' - id: FAS-MBR-MEM-05-05 title: Leave planned renewal work stale after a term correction kind: regression exercises: - CAP-MBR-MEM-013 - CAP-MBR-MEM-014 relies_on: - ATS-MBR-MEM-013-07 - ATS-MBR-MEM-014-07 preconditions: A renewing member has a planned order action and an enabled expiry item. steps: - do: >- Correct the selected term, execute the plan, and inspect both the stale action and the unresolved item. expect: >- The stale action places no order and cannot resolve expiry attention as if a renewal had committed. provenance: proposed source: &ref_2 - >- services-membership:modules/billing/tests/integration/billing-runs.integration.spec.ts#refuses as stale an action whose term changed after planning - >- services-membership:modules/memberships/tests/integration/services/expiring-memberships.integration.spec.ts#resolves the item renewed in the staff renewal’s transaction expected: >- The stale action places no order and cannot resolve expiry attention as if a renewal had committed. 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_2 evidence: - >- rhythm-v2-docs:specs/membership/memberships/planning/features/FEAT-MBR-MEM-05-renewal-billing-and-expiry-alerts.md - >- rhythm-v2-docs:specs/membership/memberships/design/tests/: detailed capability scenarios and interaction cases. - >- services-membership:modules/billing/tests/integration/billing-runs.integration.spec.ts - 'services-membership:tests/e2e/billing-api.e2e.spec.ts' --- # Renewal Operations and Expiry Attention: Feature Acceptance Suite ## What the Feature Must Do as a Whole This suite tests the seasonal renewal plan and the work that follows review. Composite cases connect settled billing actions to the expiry attention staff use during that season. ## 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. |