# Story 1.7: Legacy Schema Compatibility Validation Gate Status: ready-for-dev ## Story As a an administrator, I want to run a compatibility check that confirms legacy table schemas are unchanged against the approved baseline, so that every release can be gated on legacy integrity before deployment. ## Acceptance Criteria 1. **Given** the compatibility check is triggered **When** it runs against the live database **Then** it compares all legacy table structures (column names, types, constraints) against the approved schema baseline stored at initialization 2. **Given** a structural change is detected on any legacy table **When** the check completes **Then** it returns a failure status with a detailed report identifying the affected table, column, and change type (NFR12) 3. **Given** no schema drift is detected **When** the check completes **Then** it returns a pass confirmation with timestamp, number of tables verified, and zero drift count 4. **Given** the check is integrated into the release pipeline **When** it fails **Then** the release is blocked automatically and a failure report is surfaced to the administrator 5. **Given** an administrator is logged in **When** they navigate to the compatibility check feature **Then** they can trigger the check manually and view the most recent check history with timestamps ## Tasks / Subtasks - [ ] Implement story behavior in aligned backend/frontend modules (AC: #1) - [ ] Add or update API/service/UI components required by the story scope - [ ] Keep legacy Access entities read-only and route writes to extension-layer structures - [ ] Cover acceptance criteria #2 in implementation and tests (AC: #2) - [ ] Add validation/error handling and UX state updates as needed - [ ] Cover acceptance criteria #3 in implementation and tests (AC: #3) - [ ] Add validation/error handling and UX state updates as needed - [ ] Cover acceptance criteria #4 in implementation and tests (AC: #4) - [ ] Add validation/error handling and UX state updates as needed - [ ] Validate and document completion evidence - [ ] Verify build/tests for touched modules - [ ] Capture changed files and any migration/config implications ## Dev Notes - Follow Epic 1 architecture constraints: ASP.NET Core + React separation, RBAC-aware patterns, and immutable legacy tables. - Reuse shared component and workflow patterns defined in UX and architecture docs; avoid parallel custom implementations. - Keep changes scoped to this story; do not pull forward Epic 2+ features. ### Project Structure Notes - Backend: `BriansClientRouteReports.Server/` - Frontend: `brians-client-route-reports-client/` - Story artifacts: `_bmad-output/implementation-artifacts/` ### References - Story source: `_bmad-output/planning-artifacts/epics.md` (Epic 1 / Story 1.7) - Architecture constraints: `_bmad-output/planning-artifacts/architecture.md` - UX patterns: `_bmad-output/planning-artifacts/ux-design-specification.md` ## Dev Agent Record ### Agent Model Used GPT-5 Codex ### Debug Log References - Story generated from epic source and architecture/UX planning artifacts. ### Completion Notes List - Story context created and marked ready-for-dev. ### File List - `_bmad-output/implementation-artifacts/1-7-legacy-schema-compatibility-validation-gate.md`