Campaign_Tracker/_bmad-output/implementation-artifacts/1-6-legacy-anti-corruption-data-access-layer.md

Story 1.6: Legacy Anti-Corruption Data Access Layer

Status: ready-for-dev

Story

As a a developer, I want a dedicated read-only data access layer for legacy Access-derived entities using fixed join keys, so that legacy data is available to all features without any risk of schema mutation or direct table coupling.

Acceptance Criteria

1. Given a feature requests municipality or jurisdiction data When the anti-corruption layer is called Then it returns data joined by ID, JCode/JurisCode, or KitID without modifying any legacy table structure or content (NFR12)
2. Given the anti-corruption layer executes any query When the operation is inspected Then only SELECT operations are permitted — INSERT, UPDATE, and DELETE on legacy entities are blocked at the layer boundary
3. Given legacy data is returned through the layer When mapped to the application domain Then it is converted to strongly-typed domain model objects before being returned to any calling feature
4. Given any application code outside the layer attempts to query legacy tables directly When reviewed in code Then no such direct access exists — the anti-corruption layer is the sole access point for legacy data

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: Campaign_Tracker.Server/
• Frontend: campaign-tracker-client/
• Story artifacts: _bmad-output/implementation-artifacts/

References

• Story source: _bmad-output/planning-artifacts/epics.md (Epic 1 / Story 1.6)
• 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-6-legacy-anti-corruption-data-access-layer.md