--- id: FAS-PFM-QRY-08 feature: FEAT-PFM-QRY-08 product_area: platform module: queries revision: 2 status: proposed product_intent: proposed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f rhythm-v2-docs: f946bdcc118035206f18109fbf69cd8e9e785aaf capabilities: - CAP-PFM-QRY-019 scenarios: - id: FAS-PFM-QRY-08-01 title: Plan and expose the completed local month kind: behaviour exercises: - CAP-PFM-QRY-019 relies_on: - ATS-PFM-QRY-019-01 - ATS-PFM-QRY-019-03 - ATS-PFM-QRY-019-04 preconditions: 'Eligible, disabled and loading workspaces occupy different time zones.' steps: >- Plan the completed months, admit eligible work, publish it and read periods from each workspace. expected: >- Eligible publication becomes the selected version while skipped months preserve their reasons and local period boundaries. negative: false data_needs: >- Use an isolated workspace, named fixture records and the caller grants described by the prerequisites. bound_to: [] provenance: proposed source: - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#lets the tenant’s own people read its periods - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#plans the eligible tenant's September in its own zone, as version 1 of a captured, scheduled run - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#plans one run and skips two, passing over none - id: FAS-PFM-QRY-08-02 title: Historical periods coexist with current record lookup kind: interaction exercises: - CAP-PFM-QRY-019 - CAP-PFM-QRY-017 relies_on: - ATS-PFM-QRY-019-11 - ATS-PFM-QRY-017-11 preconditions: Two workspaces contain retained snapshots and indexed contacts. steps: >- Delete one workspace, finish its open rebuild and inspect historical periods and search inventories for both. expected: >- The removed workspace retains neither history nor search resources; the surviving control retains both. negative: false data_needs: >- Use an isolated workspace, named fixture records and the caller grants described by the prerequisites. bound_to: [] provenance: proposed source: - >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#removes every snapshot row, run and override of the purged tenants, the run's version chain included - >- services-platform:modules/quick-search/tests/integration/services/maintenance/tenant-participant.integration.spec.js#purges the tenant once the rebuild has settled, the job’s own three tables included - id: FAS-PFM-QRY-08-03 title: Failed self-test validation leaves the last published version selected kind: lifecycle exercises: - CAP-PFM-QRY-019 relies_on: - ATS-PFM-QRY-019-05 - ATS-PFM-QRY-019-06 preconditions: >- The local user-status-counts self-test has a published first version and real database fixtures. steps: >- Add a user and publish a second version, corrupt the next attempt’s inserted counts through the test trigger, run final validation and read the retained period and versions. expected: >- The second version remains current and readable, the first stays retained, and the failed small attempt publishes no rows; the assertion does not cover committed chunks from other generators. negative: true data_needs: >- Use an isolated workspace, named fixture records and the caller grants described by the prerequisites. bound_to: - TST-PFM-QRY-472 provenance: test source: >- services-platform:modules/snapshots/tests/integration/lifecycle/pipeline/snapshot-pipeline.integration.spec.js#publishes version 2 as the current one and keeps version 1, published and readable - id: FAS-PFM-QRY-08-04 title: HQ readers can inspect without managing runs kind: permission exercises: - CAP-PFM-QRY-019 relies_on: - ATS-PFM-QRY-019-01 - ATS-PFM-QRY-019-02 - ATS-PFM-QRY-019-07 preconditions: >- Support, HQ administration and customer contexts can attempt their respective snapshot operations. steps: >- List periods and runs, request new runs as support and a customer, and write a ledger row under another service’s role. expected: >- Read access does not grant management, customer callers do not reach HQ and service writers cannot change another owner’s ledger. negative: true data_needs: >- Use an isolated workspace, named fixture records and the caller grants described by the prerequisites. bound_to: [] provenance: proposed source: - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#lets the tenant’s own people read its periods - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#lets a Rhythm Administrator list the runs - >- services-platform:modules/snapshots/tests/integration/db/snapshot-runs-accounting-writer.integration.spec.js#refuses a run whose owner_service is another service’s, in its own tenant - id: FAS-PFM-QRY-08-05 title: Repeated planning and reruns keep independent uniqueness kind: regression exercises: - CAP-PFM-QRY-019 relies_on: - ATS-PFM-QRY-019-05 - ATS-PFM-QRY-019-08 - ATS-PFM-QRY-019-14 preconditions: A period has a published version and another version is actively running. steps: >- Repeat planning, request overlapping work and try a second current or active row while retaining an inactive version. expected: >- Duplicate active or current versions are refused; retained inactive history is allowed and dispatcher admission remains bounded. negative: true data_needs: >- Use an isolated workspace, named fixture records and the caller grants described by the prerequisites. bound_to: [] provenance: proposed source: - >- services-platform:modules/snapshots/tests/e2e/snapshots.e2e.spec.js#plans a manual run as version 1 of a captured run, for the dispatcher to start - >- services-platform:modules/snapshots/tests/integration/db/snapshot-runs.table.integration.spec.js#refuses a second active run of the same tenant, type and period - 'services-platform:docs/snapshots/README.md#Configuration and the runbook' evidence: - >- rhythm-v2-docs:specs/platform/queries/planning/features/FEAT-PFM-QRY-08-monthly-snapshots.md - >- rhythm-v2-docs:specs/platform/queries/planning/capabilities/CAP-PFM-QRY-019-keep-monthly-snapshots-of-each-workspace-and-show-which.md --- # Monthly history: Feature Acceptance Suite ## What the Feature Must Do as a Whole Monthly history connects workspace eligibility and local calendar periods to publication and readable retained versions. The suite follows planning, reruns, failed validation and cleanup. Its small self-test case establishes a bounded publication result; larger chunked generators retain their separate cleanup finding. ## Interactions Between Capabilities Workspace removal joins historical cleanup to search-resource cleanup while a surviving workspace supplies the control. Within snapshots, the lifecycle case publishes a replacement and then fails the next attempt, checking which version remains selected. Permission and regression cases distinguish read access, run management and the uniqueness of active and published versions. ## Regression Record | Revision | Change | Scenario | Why | |---|---|---|---| | 1 | initial | all | Establish cumulative coverage from the pinned specifications and test assertions. | | 2 | continuation examination | failed rerun lifecycle | Activate the local pipeline binding with its small-run publication boundary. |