Rhythm 2.0 Specifications

Appearance

FAS-MBR-MEM-02Member Connections to Chapters and Sections: Feature Acceptance Suite

Markdown

FAS-MBR-MEM-02

Member Connections to Chapters and Sections: Feature Acceptance Suite

Markdown
  • DocumentProposed
  • Product intentProposed

Planning

Feature
FEAT-MBR-MEM-02
Capabilities
CAP-MBR-MEM-007, CAP-MBR-MEM-008
Executed by
TST-MBR-MEM-022, TST-MBR-MEM-248

Product areaMembershipModuleMemberships, Applications and Membership BillingRevision1

Read atservices-membership 5994c270react-console baf6dae3

Member Connections to Chapters and Sections: Feature Acceptance Suite ​

What the Feature Must Do as a Whole ​

This suite tests the consistency of dated chapter connections across rosters, transfer and consolidation. It includes cases where a change to one row affects lineage, primary selection or officer reach.

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 ​

RevisionChangeScenarioWhy
1initialallEstablish cumulative feature coverage from the pinned specification and executable evidence.

Scenarios

5 scenarios proving FEAT-MBR-MEM-02 as a whole.

01 Read one multi-chapter member consistently across rosters behaviour test
Exercises
CAP-MBR-MEM-007
Relies on
ATS-MBR-MEM-007-12 ATS-MBR-MEM-008-09
Preconditions
One member has two chapters under common ancestors.
Steps
[object Object]
Expected
The same member appears once per applicable roster and the recorded primary chapter is returned.
Data
An isolated workspace, dated member fixtures, chapter and package configuration, and recording partner ports where the case requires them.
Bound to
Source
services-membership:tests/e2e/s05-multiple-chapters.e2e.spec.ts,services-membership:tests/e2e/s05-multiple-chapters.e2e.spec.ts#returns Jo in the Atlanta and in the Savannah roster,services-membership:tests/e2e/s09-restructuring.e2e.spec.ts#rewrites no affiliation: Jo’s row is the same row, version and unit
02 Keep the second chapter when the first transfers interaction proposed
Exercises
CAP-MBR-MEM-007 CAP-MBR-MEM-008
Relies on
ATS-MBR-MEM-007-08 ATS-MBR-MEM-008-03
Preconditions
A term holds Atlanta and Savannah; a permitted transfer continues Atlanta into San Francisco.
Steps
[object Object]
Expected
Only the transferred connection changes; Savannah retains its row and ancestor coverage while the primary follows the successor.
Data
An isolated workspace, dated member fixtures, chapter and package configuration, and recording partner ports where the case requires them.
Source
services-membership:modules/memberships/tests/integration/services/affiliation-withdrawal-continued.integration.spec.ts#refuses to withdraw the continued row, naming the affiliation that continues it, and keeps the row,services-membership:tests/e2e/s06-midterm-transfer.e2e.spec.ts#answers Atlanta and Savannah as of 2026-10-15, San Francisco and Savannah as of 2027-02-01, the primary moving
03 Preserve dated connections through chapter consolidation lifecycle proposed
Exercises
CAP-MBR-MEM-007 CAP-MBR-MEM-008
Relies on
ATS-MBR-MEM-007-12 ATS-MBR-MEM-008-04 ATS-MBR-MEM-008-07
Preconditions
Source and survivor chapters have open, duplicated, future and closed connections.
Steps
[object Object]
Expected
The merge accounts for every connection, current survivor rosters reflect moved members and retained historical references prevent deletion.
Data
An isolated workspace, dated member fixtures, chapter and package configuration, and recording partner ports where the case requires them.
Source
services-membership:tests/e2e/s05-multiple-chapters.e2e.spec.ts#returns Jo in the Atlanta and in the Savannah roster,services-membership:modules/memberships/tests/integration/services/affiliations-unit-merge.integration.spec.ts#answers what it did: one moved, one ended on the survivor, one left closed,services-membership:tests/e2e/s13-unit-merge.e2e.spec.ts#refuses to delete Savannah while affiliations name it (unit_has_affiliations)
04 Refuse a transfer that crosses the officer’s reach permissionnegative proposed
Exercises
CAP-MBR-MEM-007 CAP-MBR-MEM-008
Relies on
ATS-MBR-MEM-007-09 ATS-MBR-MEM-008-02
Preconditions
An officer reaches Atlanta but not a member’s other chapter or the target outside Atlanta.
Steps
[object Object]
Expected
The member remains readable while every unauthorized row change is refused and the existing rows stay intact.
Data
An isolated workspace, dated member fixtures, chapter and package configuration, and recording partner ports where the case requires them.
Source
services-membership:modules/memberships/tests/integration/services/affiliations.integration.spec.ts#makes an affiliation the primary of its type and the other one no longer,services-membership:tests/e2e/s06-midterm-transfer.e2e.spec.ts#refuses the console’s transfer 409 requires_amendment, naming the component_change amendment
05 Retain transfer lineage when withdrawal is attempted regression test
Exercises
CAP-MBR-MEM-007 CAP-MBR-MEM-008
Relies on
ATS-MBR-MEM-007-08 ATS-MBR-MEM-008-01
Preconditions
A permitted transfer has created a successor affiliation.
Steps
[object Object]
Expected
The refusal names the successor and both predecessor and successor remain stored.
Data
An isolated workspace, dated member fixtures, chapter and package configuration, and recording partner ports where the case requires them.
Bound to
Source
services-membership:modules/memberships/tests/integration/services/affiliation-withdrawal-continued.integration.spec.ts,services-membership:modules/memberships/tests/integration/services/affiliation-withdrawal-continued.integration.spec.ts#refuses to withdraw the continued row, naming the affiliation that continues it, and keeps the row,services-membership:modules/memberships/tests/integration/services/affiliations.integration.spec.ts#transfers to a chapter that sells no dues: the old row ends the day before, the new one continues it as primary

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