--- id: FAS-MBR-MEM-07 feature: FEAT-MBR-MEM-07 product_area: membership module: memberships revision: 1 status: proposed product_intent: proposed source_sha: services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f capabilities: - CAP-MBR-MEM-018 - CAP-MBR-MEM-019 - CAP-MBR-MEM-020 scenarios: - id: FAS-MBR-MEM-07-01 title: Reconcile recorded membership changes with monthly reporting kind: behaviour exercises: - CAP-MBR-MEM-018 - CAP-MBR-MEM-019 - CAP-MBR-MEM-020 relies_on: - ATS-MBR-MEM-018-01 - ATS-MBR-MEM-019-02 - ATS-MBR-MEM-020-01 preconditions: A current membership has attributed writes and an enabled event receiver. steps: - do: >- Correct and close coverage, read its history, generate the affected month and inspect its committed business events. expect: >- History, dated monthly rows and the emitted outcomes refer to the same committed coverage changes. provenance: proposed source: &ref_0 - >- services-membership:modules/history/tests/integration/membership-history.integration.spec.ts#records the creation as one revision of the membership, its term and affiliation as collections - >- services-membership:modules/snapshots/tests/integration/snapshot-pipeline.integration.spec.ts#plans September’s first version for the tenant, once - >- services-membership:modules/events/tests/integration/business-events.integration.spec.ts#states membership.term.committed and the term’s affiliation for a staff creation, naming the person, the program and the term expected: >- History, dated monthly rows and the emitted outcomes refer to the same committed coverage changes. 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-07-02 title: Keep the old snapshot until a corrected version passes checks kind: interaction exercises: - CAP-MBR-MEM-018 - CAP-MBR-MEM-019 relies_on: - ATS-MBR-MEM-018-08 - ATS-MBR-MEM-019-05 - ATS-MBR-MEM-019-06 preconditions: A month is published and one member has a backdated correction. steps: - do: >- Inspect earlier-known and later-known answers, attempt a failing restatement, then generate a valid later-known version. expect: >- The failed attempt leaves the earlier publication current; the valid restatement changes the corrected member and related counts. provenance: proposed source: &ref_1 - >- services-membership:modules/history/tests/integration/membership-as-of.integration.spec.ts#answers the term as it was known before the correction, with a known_at before it - >- services-membership:modules/snapshots/tests/integration/membership-snapshot.integration.spec.ts#fails the run on the counts check, publishes nothing, and leaves the current version current - >- services-membership:modules/snapshots/tests/integration/membership-snapshot.integration.spec.ts#writes identical member, affiliation and count rows with the original known_at expected: >- The failed attempt leaves the earlier publication current; the valid restatement changes the corrected member and related counts. 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-07-03 title: Retry delivered terminations with stable event identity kind: lifecycle exercises: - CAP-MBR-MEM-018 - CAP-MBR-MEM-020 relies_on: - ATS-MBR-MEM-018-01 - ATS-MBR-MEM-020-06 - ATS-MBR-MEM-020-07 preconditions: >- A staff termination commits with attribution and a configured recording receiver. steps: - do: >- Read its revision, dispatch its event, fail the receiver once, then accept redelivery. expect: >- The revision remains committed and both delivery attempts identify the same termination event before settlement. provenance: proposed source: &ref_2 - >- services-membership:modules/history/tests/integration/membership-history.integration.spec.ts#records the creation as one revision of the membership, its term and affiliation as collections - >- services-membership:modules/events/tests/integration/change-events-dispatch.integration.spec.ts#hands Committees the termination alone, as { version: 1, stream, events } with data.contact_id and data.ends_on - >- services-membership:modules/events/tests/integration/change-events-dispatch.integration.spec.ts#returns the message to the queue when Committees answers failed, so SQS retries it expected: >- The revision remains committed and both delivery attempts identify the same termination event before settlement. 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 - id: FAS-MBR-MEM-07-04 title: Separate member inspection from history and dataset grants kind: permission exercises: - CAP-MBR-MEM-018 - CAP-MBR-MEM-019 relies_on: - ATS-MBR-MEM-018-05 - ATS-MBR-MEM-019-01 - ATS-MBR-MEM-019-09 preconditions: >- A reader has membership-read authority but lacks history and dataset query grants. steps: - do: >- Read the current member, request history and each live and snapshot dataset, then repeat with its specific grant. expect: >- Only separately granted reads succeed and each successful dataset remains within the requester’s workspace. provenance: proposed source: &ref_3 - >- services-membership:tests/e2e/history-api.e2e.spec.ts#refuses the history to a reader of memberships who does not hold membership.memberships.history - >- services-membership:modules/memberships/tests/integration/db/membership-functions.integration.spec.ts#answers the query layer’s picks from memberships_for_queries: status today, current type, episode count - >- services-membership:modules/snapshots/tests/integration/membership-snapshot.integration.spec.ts#reads the current published version alone through the published view, in the tenant expected: >- Only separately granted reads succeed and each successful dataset remains within the requester’s workspace. 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_3 - id: FAS-MBR-MEM-07-05 title: Reproduce the original month and restate only the correction kind: regression exercises: - CAP-MBR-MEM-018 - CAP-MBR-MEM-019 relies_on: - ATS-MBR-MEM-018-08 - ATS-MBR-MEM-019-06 preconditions: 'A generated month has saved member, affiliation and count rows.' steps: - do: >- Correct one member, rerun at the original recording instant, then rerun at a later instant and inspect published versions. expect: >- The original-instant rows reproduce; the later version differs only for the corrected member and its affected counts while earlier versions remain available. provenance: test source: >- services-membership:modules/snapshots/tests/integration/membership-snapshot.integration.spec.ts expected: >- The original-instant rows reproduce; the later version differs only for the corrected member and its affected counts while earlier versions remain available. 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-040 provenance: test source: - >- services-membership:modules/snapshots/tests/integration/membership-snapshot.integration.spec.ts - >- services-membership:modules/history/tests/integration/membership-as-of.integration.spec.ts#answers the term as it was known before the correction, with a known_at before it - >- services-membership:modules/snapshots/tests/integration/membership-snapshot.integration.spec.ts#writes identical member, affiliation and count rows with the original known_at binding_evidence: - suite: TST-MBR-MEM-040 source: >- services-membership:modules/snapshots/tests/integration/membership-snapshot.integration.spec.ts evidence: - >- rhythm-v2-docs:specs/membership/memberships/planning/features/FEAT-MBR-MEM-07-membership-history-reporting-and-events.md - >- rhythm-v2-docs:specs/membership/memberships/design/tests/: detailed capability scenarios and interaction cases. - >- services-membership:modules/snapshots/tests/integration/membership-snapshot.integration.spec.ts --- # Membership Accountability and Reporting: Feature Acceptance Suite ## What the Feature Must Do as a Whole This suite tests how committed membership changes remain explainable through history, monthly rows and delivered outcomes. It includes corrections that change later knowledge without erasing earlier recorded answers. ## 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. |