--- id: FAS-MBR-MEM-02 feature: FEAT-MBR-MEM-02 product_area: membership module: memberships revision: 1 status: proposed product_intent: proposed source_sha: services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f capabilities: - CAP-MBR-MEM-007 - CAP-MBR-MEM-008 scenarios: - id: FAS-MBR-MEM-02-01 title: Read one multi-chapter member consistently across rosters kind: behaviour 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: - do: >- Read both chapter rosters, the ancestor rosters and a chapter’s dated primary answer without moving any connection. expect: >- The same member appears once per applicable roster and the recorded primary chapter is returned. provenance: test source: 'services-membership:tests/e2e/s05-multiple-chapters.e2e.spec.ts' expected: >- The same member appears once per applicable roster and the recorded primary chapter is returned. 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-248 provenance: test 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 binding_evidence: - suite: TST-MBR-MEM-248 source: 'services-membership:tests/e2e/s05-multiple-chapters.e2e.spec.ts' - id: FAS-MBR-MEM-02-02 title: Keep the second chapter when the first transfers kind: interaction 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: - do: >- Transfer Atlanta at a selected date and inspect lineage, primary selection and chapter and ancestor rosters on each side of the date. expect: >- Only the transferred connection changes; Savannah retains its row and ancestor coverage while the primary follows the successor. provenance: proposed source: &ref_0 - >- 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 expected: >- Only the transferred connection changes; Savannah retains its row and ancestor coverage while the primary follows the successor. 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-02-03 title: Preserve dated connections through chapter consolidation kind: lifecycle 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: - do: >- Merge the source into the survivor, read the resulting rows and current rosters, then try to delete the referenced source. expect: >- The merge accounts for every connection, current survivor rosters reflect moved members and retained historical references prevent deletion. provenance: proposed source: &ref_1 - >- 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) expected: >- The merge accounts for every connection, current survivor rosters reflect moved members and retained historical references prevent deletion. 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-02-04 title: Refuse a transfer that crosses the officer’s reach kind: permission 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: - do: >- Read the member, attempt to end the other chapter, transfer the reachable row outside scope and change a primary affecting an unreachable row. expect: >- The member remains readable while every unauthorized row change is refused and the existing rows stay intact. provenance: proposed source: &ref_2 - >- 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 expected: >- The member remains readable while every unauthorized row change is refused and the existing rows stay intact. 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_2 - id: FAS-MBR-MEM-02-05 title: Retain transfer lineage when withdrawal is attempted kind: regression 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: - do: >- Attempt withdrawal of the predecessor and inspect the refusal and both affiliation records. expect: >- The refusal names the successor and both predecessor and successor remain stored. provenance: test source: >- services-membership:modules/memberships/tests/integration/services/affiliation-withdrawal-continued.integration.spec.ts expected: >- The refusal names the successor and both predecessor and successor remain stored. 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-022 provenance: test 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 binding_evidence: - suite: TST-MBR-MEM-022 source: >- services-membership:modules/memberships/tests/integration/services/affiliation-withdrawal-continued.integration.spec.ts evidence: - >- rhythm-v2-docs:specs/membership/memberships/planning/features/FEAT-MBR-MEM-02-chapter-and-section-affiliations.md - >- rhythm-v2-docs:specs/membership/memberships/design/tests/: detailed capability scenarios and interaction cases. - 'services-membership:tests/e2e/s05-multiple-chapters.e2e.spec.ts' - 'services-membership:tests/e2e/s06-midterm-transfer.e2e.spec.ts' - 'services-membership:tests/e2e/s08-cross-chapter-restrictions.e2e.spec.ts' - >- services-membership:modules/memberships/tests/integration/services/affiliation-withdrawal-continued.integration.spec.ts --- # 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 | Revision | Change | Scenario | Why | |---|---|---|---| | 1 | initial | all | Establish cumulative feature coverage from the pinned specification and executable evidence. |