#7 Story 1.7: Legacy Schema Compatibility Validation Gate

Geschlossen
vor 3 Tagen von nano geöffnet · 0 Kommentare
nano hat vor 3 Tagen kommentiert

Imported from _bmad-output/implementation-artifacts/1-7-legacy-schema-compatibility-validation-gate.md.

# 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
Imported from [_bmad-output/implementation-artifacts/1-7-legacy-schema-compatibility-validation-gate.md](https://onefortheroadgit.sytes.net/dcovington/Campaign_Tracker/src/branch/main/_bmad-output/implementation-artifacts/1-7-legacy-schema-compatibility-validation-gate.md). # 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`
nano fügte das
Sprint 1
Label vor 3 Tagen hinzu
nano hat diesen Issue vor 3 Tagen zum Sprint 1 Meilenstein hinzugefügt
dcovington hat vor 2 Tagen geschlossen
Anmelden, um an der Diskussion teilzunehmen.
Kein Label
Kein Meilenstein
Niemand zuständig
1 Beteiligte
Fällig am

Kein Fälligkeitsdatum gesetzt.

Abhängigkeiten

Dieses Issue hat momentan keine Abhängigkeiten.

Laden…
Abbrechen
Speichern
Hier gibt es bis jetzt noch keinen Inhalt.

Powered by TurnKey Linux.