Campaign_Tracker/_bmad-output/implementation-artifacts/1-8-legacy-identifier-linking-for-extension-records.md

Story 1.8: Legacy Identifier Linking for Extension Records

Status: ready-for-dev

Story

As a a system user, I want extension records to store and validate legacy identifier references on creation, so that all new capabilities join deterministically to legacy Access records in workflows and reports.

Acceptance Criteria

1. Given a new extension record is created (municipality profile, election job, service config) When it is saved Then it stores the appropriate legacy identifier (ID, JCode/JurisCode, or KitID) as a required foreign reference
2. Given an extension record references a legacy identifier When the anti-corruption layer executes a join Then it returns the correct legacy record with no ambiguity across all active records
3. Given an extension record is submitted with an invalid or non-existent legacy identifier When validation runs before save Then the save is rejected with a descriptive validation error identifying the invalid reference
4. Given the nightly integrity check runs When it evaluates all extension-to-legacy joins Then it reports referential consistency and flags any records that fail to resolve, targeting 99.9% consistency (NFR13)

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.8)
• 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-8-legacy-identifier-linking-for-extension-records.md