Rhythm 2.0 Specifications

Appearance

ATS-MBR-STR-015Determine a term’s start and end dates: Capability Test Specification

Markdown

ATS-MBR-STR-015

Determine a term’s start and end dates: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-MBR-STR-015

Design

Executed by
TST-MBR-STR-013, TST-MBR-STR-015, TST-MBR-STR-018, TST-MBR-STR-019, TST-MBR-STR-041

KindAcceptance test setProduct areaMembershipModuleOrganizational Structure, Membership Configuration and TermsRevision2

Read atservices-membership 5994c270react-console baf6dae3

Determine a term’s start and end dates: Capability Test Specification ​

Coverage ​

The coverage map distinguishes specified examples from missing proof. A covered category means an expected case is specified; executable bindings and their run results remain separate evidence. Each required rule has a proof link or an explicit coverage finding in the structured rule ledger.

Required RuleScenario or Finding
BR-CAP-MBR-STR-015-01ATS-MBR-STR-015-01, ATS-MBR-STR-015-11
BR-CAP-MBR-STR-015-02ATS-MBR-STR-015-02
BR-CAP-MBR-STR-015-03ATS-MBR-STR-015-03, ATS-MBR-STR-015-12
BR-CAP-MBR-STR-015-04ATS-MBR-STR-015-04
BR-CAP-MBR-STR-015-05ATS-MBR-STR-015-05
BR-CAP-MBR-STR-015-06ATS-MBR-STR-015-06
BR-CAP-MBR-STR-015-07ATS-MBR-STR-015-07
BR-CAP-MBR-STR-015-08ATS-MBR-STR-015-08
BR-CAP-MBR-STR-015-09Gap: FND-MBR-STR-068
BR-CAP-MBR-STR-015-10ATS-MBR-STR-015-09, ATS-MBR-STR-015-14
BR-CAP-MBR-STR-015-11ATS-MBR-STR-015-10
BR-CAP-MBR-STR-015-13Gap: FND-MBR-STR-068

Independent grants require a valid date rule. Submit a grant using its own anniversary rule but missing length, then correct the rule and calculate its period beside the primary term.

Calculated continuation dates avoid a standing gap. Compute a continuation from a term ending September 30 and evaluate coverage on September 30 and October 1.

Coverage

  • Rule covered
  • Transition gap: FND-MBR-STR-068
  • Validation covered
  • Permission covered
  • Edge gap: FND-MBR-STR-068
  • Failure gap: FND-MBR-STR-068
  • Boundary covered
  • Concurrency gap: FND-MBR-STR-068
  • Invariant covered
  • Interaction covered

Test Scenarios

14 scenarios proving CAP-MBR-STR-015; 11 bound to an existing test.

01 Invalid date rules report their combined problemsvalidationunitnegativetest
Proves
BR-CAP-MBR-STR-015-01
Preconditions
Explicit inputs or a recording fixture represent the cases exercised below.
Steps
Compute a calendar rule with month units, no start month and an anniversary-only threshold.
Expected
The refusal identifies the incompatible and missing settings together.
Data
Literal term, state or declaration fixtures for the described cases.
Bound to
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: what 2.0 decides › reports every problem of a rule at once
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: what 2.0 decides › refuses a calendar term counted in anything but years
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: what 2.0 decides › refuses a rule it cannot compute, naming what is wrong
Source
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: what 2.0 decides › reports every problem of a rule at once
02 Partial basis changes validate the resulting rulevalidationapinegativetest
Proves
BR-CAP-MBR-STR-015-02
Preconditions
An isolated Membership-licensed workspace contains the relevant records, with caller permissions selected for the case.
Steps
Change an existing package to calendar basis alone, then include the required calendar start.
Expected
The incomplete result fails and the complete result saves.
Data
The FAA example records or equivalent records prepared within the isolated workspace.
Bound to
services-membership:tests/acceptance/configuration/MBR-ACC-0101.acceptance.ts#MBR-ACC-0101: A package update is judged on the record as it will be after the change: switching the basis alone is refused, switching it with the dependent fields is accepted, and the renewal, reinstatement, seat and proration settings round-trip, clear and bound correctly
Source
services-membership:tests/acceptance/configuration/MBR-ACC-0101.acceptance.ts#MBR-ACC-0101: A package update is judged on the record as it will be after the change: switching the basis alone is refused, switching it with the dependent fields is accepted, and the renewal, reinstatement, seat and proration settings round-trip, clear and bound correctly
03 Continuation and restart use different starting pointsruleunittest
Proves
BR-CAP-MBR-STR-015-03
Preconditions
Explicit inputs or a recording fixture represent the cases exercised below.
Steps
Calculate early and late continuations and a rule with continuation disabled.
Expected
Continuations begin after the existing end, while the disabled case begins from the purchase basis.
Data
Literal term, state or declaration fixtures for the described cases.
Bound to
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: the rules of 1.0 beyond its spec cases › extends an early renewal from the current end, whatever the basis
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: the rules of 1.0 beyond its spec cases › back-dates a late renewal to the day after the current end
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: what 2.0 decides › starts a term fresh from the basis when the rule does not continue from the end (1.0 always continued)
services-membership:modules/terms/tests/unit/term-rules.property.spec.ts#term rules: generated cases › starts a continuation the day after the current end
services-membership:modules/terms/tests/unit/define-term-engine.spec.ts#defineTermEngine › computes a purchase’s period from the offering’s rule the hook reads
Source
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: the rules of 1.0 beyond its spec cases › extends an early renewal from the current end, whatever the basis
04 Reinstatement changes at its last permitted dayboundaryunittest
Proves
BR-CAP-MBR-STR-015-04 AS-JNY-MBR-STR-005-02
Preconditions
Explicit inputs or a recording fixture represent the cases exercised below.
Steps
Calculate a terminated period at its reinstatement boundary, the following day and after its end with no allowance.
Expected
The boundary continues; later and zero-allowance-after-end cases restart.
Data
Literal term, state or declaration fixtures for the described cases.
Bound to
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: the rules of 1.0 beyond its spec cases › continues a terminated term on the last day of its window
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: the rules of 1.0 beyond its spec cases › restarts a terminated term the day after its window closes
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: the rules of 1.0 beyond its spec cases › restarts a terminated term at once when the rule has no reinstatement window
Source
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: the rules of 1.0 beyond its spec cases › continues a terminated term on the last day of its window
05 Anniversary examples retain the expected roundingruleunittest
Proves
BR-CAP-MBR-STR-015-05
Preconditions
Explicit inputs or a recording fixture represent the cases exercised below.
Steps
Calculate the April annual purchase, its threshold-day variant and the January week case.
Expected
The resulting ends are April month-end, May month-end and seven days after the week start.
Data
Literal term, state or declaration fixtures for the described cases.
Bound to
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: 1.0 calculate-expiration-date.spec.js › 1.0 lines 284-292: anniversary in years, should calculate properly for a single year › ends a purchase of 2019-04-03 at the end of the anniversary month, 2020-04-30
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: 1.0 calculate-expiration-date.spec.js › 1.0 lines 327-337: anniversary in years, should respect sell after month › moves a new term bought 2019-04-15 with the threshold 15 a month on, to 2020-05-31
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: 1.0 calculate-expiration-date.spec.js › 1.0 lines 625-634: anniversary, should calculate properly for a single week › ends a month-end week bought 2019-01-01 seven days on, 2019-01-08, keeping the full count
services-membership:modules/terms/tests/unit/term-rules.property.spec.ts#term rules: generated cases › ends a month-end rule on the last day of a month
Source
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: 1.0 calculate-expiration-date.spec.js › 1.0 lines 284-292: anniversary in years, should calculate properly for a single year › ends a purchase of 2019-04-03 at the end of the anniversary month, 2020-04-30
06 Fixed windows cover ordinary and wrapping rangesboundaryunittest
Proves
BR-CAP-MBR-STR-015-06
Preconditions
Explicit inputs or a recording fixture represent the cases exercised below.
Steps
Calculate an in-window start, a February start in a wrapping range and a start immediately after a non-December window closes.
Expected
Each uses the selected fixed end, including the boundary-adjusted case.
Data
Literal term, state or declaration fixtures for the described cases.
Bound to
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: 1.0 calculate-expiration-date.spec.js › 1.0 lines 853-866: fixed expiration dates, simple in-year range › ends a purchase of 2023-04-03 in the window 03-01 to 05-31 on 2023-11-14
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: what 2.0 decides › finds a February purchase in the window that began the previous October: 2021-12-31 (1.0 fell through to the plain rule: 2022-02-28)
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: fixed term ends › places a renewal starting the day after a window’s end in that window (RB-2585)
Source
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: 1.0 calculate-expiration-date.spec.js › 1.0 lines 853-866: fixed expiration dates, simple in-year range › ends a purchase of 2023-04-03 in the window 03-01 to 05-31 on 2023-11-14
07 Calendar joins and continuations do not overlapruleunittest
Proves
BR-CAP-MBR-STR-015-07
Preconditions
Explicit inputs or a recording fixture represent the cases exercised below.
Steps
Compare a fresh April calendar purchase with a late continuation.
Expected
The fresh period can start in January, while continuation starts after its existing end.
Data
Literal term, state or declaration fixtures for the described cases.
Bound to
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: 1.0 calculate-expiration-date.spec.js › 1.0 lines 70-77: calendar, a standard year, should calculate properly for April › back-dates a purchase of 2019-04-03 to 2019-01-01 and ends it 2019-12-31
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: what 2.0 decides › starts a late calendar renewal of a term ending 2023-04-30 on 2023-05-01 (1.0 back-dated it to 2023-01-01, overlapping the old term)
Source
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: 1.0 calculate-expiration-date.spec.js › 1.0 lines 70-77: calendar, a standard year, should calculate properly for April › back-dates a purchase of 2019-04-03 to 2019-01-01 and ends it 2019-12-31
08 Leap-year February uses leap dayboundaryunittest
Proves
BR-CAP-MBR-STR-015-08
Preconditions
Explicit inputs or a recording fixture represent the cases exercised below.
Steps
Calculate a calendar period finishing in February 2024.
Expected
Its inclusive ending is the twenty-ninth of February.
Data
Literal term, state or declaration fixtures for the described cases.
Bound to
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: what 2.0 decides › ends a calendar period ending in February on its last day in a leap year: 2024-02-29 (decided by Andrew 2026-10-18: the real last day of the month; 1.0 added a year with Moment and ended it 2024-02-28)
Source
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: what 2.0 decides › ends a calendar period ending in February on its last day in a leap year: 2024-02-29 (decided by Andrew 2026-10-18: the real last day of the month; 1.0 added a year with Moment and ended it 2024-02-28)
09 Repeated computations leave inputs intactruleunittest
Proves
BR-CAP-MBR-STR-015-10
Preconditions
Explicit inputs or a recording fixture represent the cases exercised below.
Steps
Calculate twice from frozen inputs and again from equivalent copies.
Expected
All results match and input values remain unchanged.
Data
Literal term, state or declaration fixtures for the described cases.
Bound to
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: what 2.0 decides › gives the same result twice for the same frozen inputs (1.0 turned the fixed dates into Moments in place, so a second call read other inputs)
services-membership:modules/terms/tests/unit/term-rules.property.spec.ts#term rules: generated cases › gives the same result for the same inputs, computed again or from copies
Source
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: what 2.0 decides › gives the same result twice for the same frozen inputs (1.0 turned the fixed dates into Moments in place, so a second call read other inputs)
10 Import isolation detects a planted dependencyinvariantunittest
Proves
BR-CAP-MBR-STR-015-11
Preconditions
Explicit inputs or a recording fixture represent the cases exercised below.
Steps
Run the engine import inspection, then introduce an external module import in the isolated test fixture.
Expected
The ordinary engine passes and the planted dependency is reported.
Data
Literal term, state or declaration fixtures for the described cases.
Bound to
services-membership:modules/terms/tests/unit/isolation.spec.ts#term engine isolation › imports nothing of the repository outside modules/terms
services-membership:modules/terms/tests/unit/isolation.spec.ts#term engine isolation › refuses a planted file that imports another module, by name
Source
services-membership:modules/terms/tests/unit/isolation.spec.ts#term engine isolation › imports nothing of the repository outside modules/terms
11 Independent grants require a valid date ruleinteractionapiproposed
Proves
BR-CAP-MBR-STR-013-03 BR-CAP-MBR-STR-015-01
Preconditions
An isolated workspace contains the records and current versions needed for the case.
Steps
Submit a grant using its own anniversary rule but missing length, then correct the rule and calculate its period beside the primary term.
Expected
The invalid aggregate saves nothing; the corrected rule yields the separately expected period.
Data
Separate fixture records for the accepted and refused operations.
Source
services-membership:modules/configuration/services/configuration/configuration-records.ts:packageResource,services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: what 2.0 decides › reports every problem of a rule at once
12 Calculated continuation dates avoid a standing gapinteractionapiproposed
Proves
BR-CAP-MBR-STR-015-03 BR-CAP-MBR-STR-016-01
Preconditions
An isolated workspace contains the records and current versions needed for the case.
Steps
Compute a continuation from a term ending September 30 and evaluate coverage on September 30 and October 1.
Expected
The old term covers the first date and the continuation covers the next date without a grace interval.
Data
Separate fixture records for the accepted and refused operations.
Source
services-membership:modules/terms/tests/unit/term-rules.spec.ts#term rules: the rules of 1.0 beyond its spec cases › extends an early renewal from the current end, whatever the basis,services-membership:modules/terms/tests/unit/status.spec.ts#holding status: the precedence of §2 › puts suspended over grace
13 Workspace authority gates this capabilitypermissionapinegativeproposed
Proves
BR-CAP-MBR-STR-019-02
Preconditions
An isolated workspace contains the records and current versions needed for the case.
Steps
Exercise the capability’s exposed operations with its read-only and management callers, then repeat with application access removed, an unlicensed workspace and an unavailable workspace.
Expected
Each named operation requires its declared authority; admission failures occur before any record or calculated result is exposed.
Data
Separate fixture records for the accepted and refused operations.
Source
services-membership:tests/unit/route-authorization.spec.ts#route authorization: every Membership operation names its permission › requires membership.structure.read of every structure read and membership.structure.manage of every change,services-membership:modules/configuration/aws/api/configuration.routes.ts:configurationModuleRoutes,services-membership:tests/e2e/terms-api.e2e.spec.ts#the terms API, end to end in process › refuses a caller who holds no key in the tenant
14 Generated periods preserve repeatable datesinvariantunittest
Proves
BR-CAP-MBR-STR-015-10
Preconditions
An isolated workspace contains the records and current versions needed for the case.
Steps
Calculate every generated valid rule twice using equivalent inputs and inspect the resulting period bounds.
Expected
Each repeated result agrees and every finite end is on or after its start.
Data
Separate fixture records for the accepted and refused operations.
Bound to
services-membership:modules/terms/tests/unit/term-rules.property.spec.ts#ends every term on or after its start, and only a term of a none rule never ends
services-membership:modules/terms/tests/unit/term-rules.property.spec.ts#gives the same result for the same inputs, computed again or from copies
Source
services-membership:modules/terms/tests/unit/term-rules.property.spec.ts

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