--- id: FAS-ACC-BKS-03 title: Calendar Coverage acceptance feature: FEAT-ACC-BKS-03 product_area: accounting module: books revision: 1 status: proposed product_intent: proposed source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f capabilities: - CAP-ACC-BKS-009 - CAP-ACC-BKS-010 scenarios: - id: FAS-ACC-BKS-03-01 title: Maintain coverage and resolve dates through it kind: behaviour exercises: - CAP-ACC-BKS-009 - CAP-ACC-BKS-010 relies_on: - ATS-ACC-BKS-009-01 - ATS-ACC-BKS-009-05 - ATS-ACC-BKS-010-02 preconditions: A July-start unit has its two initial years. steps: >- Generate the next year, rename it, inspect its periods and resolve dates in generated years and beyond coverage. expected: >- The explicit extension supports date lookup and renaming preserves period identities and dates. negative: false data_needs: >- Run-owned records and principals for the stated setup; record original shared settings and restore them after exclusive cases. bound_to: - TST-ACC-BKS-018 provenance: test source: - >- react-console:acceptance/accounting/playwright/journeys/configuration/ACT-ACC-0023.spec.ts#ACT-ACC-0023 binding_evidence: - >- react-console:acceptance/accounting/playwright/journeys/configuration/ACT-ACC-0023.spec.ts#ACT-ACC-0023 - id: FAS-ACC-BKS-03-02 title: Restore a scheduled roll by extending coverage kind: interaction exercises: - CAP-ACC-BKS-009 - CAP-ACC-BKS-010 - CAP-ACC-BKS-018 relies_on: - ATS-ACC-BKS-010-03 - ATS-ACC-BKS-009-01 - ATS-ACC-BKS-018-05 preconditions: A run-owned recurring subject has an occurrence after generated coverage. steps: >- Run the uncovered occurrence, explicitly generate the needed year and run a subsequent eligible occurrence. expected: >- The failed history remains visible and the later roll records a covered year and period. negative: false data_needs: >- Run-owned records and principals for the stated setup; record original shared settings and restore them after exclusive cases. bound_to: - TST-ACC-BKS-187 provenance: test source: - >- services-accounting:modules/maintenance/tests/integration/services/scheduling/schedules-end-to-end.integration.spec.js#fails the roll dated in no fiscal year of the unit, with the sentence naming the date and the unit binding_evidence: - >- services-accounting:modules/maintenance/tests/integration/services/scheduling/schedules-end-to-end.integration.spec.js#fails the roll dated in no fiscal year of the unit, with the sentence naming the date and the unit - id: FAS-ACC-BKS-03-03 title: Reflect period standing without rewriting coverage kind: lifecycle exercises: - CAP-ACC-BKS-009 - CAP-ACC-BKS-010 relies_on: - ATS-ACC-BKS-009-07 - ATS-ACC-BKS-010-01 preconditions: A year has twelve open periods and a following generated year. steps: >- Close all periods through their owning workflow, inspect year standing and current lookup, then reopen one period through that workflow and inspect again. expected: >- Year standing and period lookup agree after both lifecycle changes; generation records keep their dates. negative: false data_needs: >- Run-owned records and principals for the stated setup; record original shared settings and restore them after exclusive cases. bound_to: [] provenance: proposed source: - ATS-ACC-BKS-009-07 - ATS-ACC-BKS-010-01 binding_evidence: [] - id: FAS-ACC-BKS-03-04 title: Keep calendar maintenance separate from lookup access kind: permission exercises: - CAP-ACC-BKS-009 - CAP-ACC-BKS-010 relies_on: - ATS-ACC-BKS-016-01 - ATS-ACC-BKS-010-02 preconditions: A reader can inspect an isolated generated calendar. steps: >- Read years and both period lookups, attempt generation, rename and deletion, and compare the calendar. expected: >- Reader lookup remains available and each maintenance attempt is refused without changing coverage. negative: true data_needs: >- Run-owned records and principals for the stated setup; record original shared settings and restore them after exclusive cases. bound_to: - TST-ACC-BKS-047 provenance: test source: - >- services-accounting:modules/books/tests/e2e/configuration-security.e2e.spec.js#is refused a generation 403 permission_missing binding_evidence: - >- services-accounting:modules/books/tests/e2e/configuration-security.e2e.spec.js#is refused a generation 403 permission_missing - id: FAS-ACC-BKS-03-05 title: Preserve coverage after an excessive extension request kind: regression exercises: - CAP-ACC-BKS-009 - CAP-ACC-BKS-010 relies_on: - ATS-ACC-BKS-009-03 - ATS-ACC-BKS-010-02 preconditions: The latest generated year is near the permitted start-date horizon. steps: >- Record a date lookup, request a multi-year extension with one out-of-range year, then reread coverage and the original lookup. expected: >- The refused extension adds no partial year and preserves the previously resolved period. negative: true data_needs: >- Run-owned records and principals for the stated setup; record original shared settings and restore them after exclusive cases. bound_to: [] provenance: proposed source: - ATS-ACC-BKS-009-03 - ATS-ACC-BKS-010-02 binding_evidence: [] evidence: - provenance: documented source: >- specs/accounting/books/planning/features/FEAT-ACC-BKS-03-fiscal-calendar.md - provenance: test source: >- Pinned executable suites and their individual assertion references are listed in the suite register. regression_record: - revision: 1 change: initial scenarios: - FAS-ACC-BKS-03-01 - FAS-ACC-BKS-03-02 - FAS-ACC-BKS-03-03 - FAS-ACC-BKS-03-04 - FAS-ACC-BKS-03-05 why: >- Establish cumulative feature acceptance from the pinned specification and executable evidence. --- # Calendar Coverage: Feature Acceptance Suite ## What the Feature Must Do as a Whole The feature gives accounting work usable calendar coverage and a way to resolve dates within it. Acceptance follows explicit extensions, maintained names and the period standing supplied by Close. ## Interactions Between Capabilities A missing period changes the outcome of scheduled work. Extending coverage changes a later lookup without rewriting the failure already recorded. ## Regression Record | Revision | Change | Scenario | Why | |---|---|---|---| | 1 | initial | all | Establish the feature’s cumulative acceptance boundary and record unimplemented joined outcomes. |