Campaign_Tracker/_bmad-output/implementation-artifacts/1-12-municipality-service-contacts.md

Story 1.12: Municipality Service Contacts

Status: ready-for-dev

Story

As a a client services staff member, I want to manage municipality service-contact records including primary and secondary contacts, so that the right people can be reached during election operations without consulting legacy records.

Acceptance Criteria

1. Given a municipality profile exists When a client services user adds a contact Then they can designate it as primary or secondary contact and save name, role/title, phone, and email
2. Given a municipality has both a primary and secondary contact When the profile is viewed Then both contacts are displayed with clear primary/secondary designation labels
3. Given a contact is updated or removed When the change is saved Then it is recorded in the audit log with actor identity and timestamp
4. Given a user attempts to save a contact without required fields (name, contact type) When the form is submitted Then the save is rejected with inline validation errors identifying the missing fields

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.12)
• 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-12-municipality-service-contacts.md