Campaign_Tracker/_bmad-output/implementation-artifacts/1-11-municipality-operational-addresses.md

Story 1.11: Municipality Operational Addresses

Status: ready-for-dev

Story

As a a client services staff member, I want to store and update municipality operational mailing and delivery addresses, so that election services reference current address information without depending on legacy records.

Acceptance Criteria

1. Given a municipality profile exists When a client services user adds an address Then they can specify mailing or delivery address type, and the record is saved to the extension address table linked to the municipality profile
2. Given an address is updated When saved Then the previous address is preserved in history, the new address is marked as current, and the change is logged with actor and timestamp
3. Given an address record is saved When retrieved Then it includes address type, street, city, state, zip, and effective date fields
4. Given a municipality profile is viewed When addresses are displayed Then mailing and delivery addresses are shown with clear type labels and current/historical status

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.11)
• 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-11-municipality-operational-addresses.md