Campaign_Tracker/_bmad-output/implementation-artifacts/1-10-municipality-account-profile.md

Story 1.10: Municipality Account Profile

Status: ready-for-dev

Story

As a a client services staff member, I want to create and maintain municipality account profiles linked to legacy jurisdiction identifiers, so that permanent municipality data is managed in the extension layer without modifying legacy Access tables.

Acceptance Criteria

1. Given a client services user navigates to municipality management When they create a new municipality profile Then it is saved to the extension layer with a required link to a valid legacy jurisdiction identifier (ID/JCode)
2. Given a municipality profile is created When the profile is loaded Then the anti-corruption layer resolves the legacy join and displays combined extension and legacy data together in the workspace grid
3. Given a profile field is updated When saved Then the change is recorded in the audit log with actor identity and timestamp
4. Given a user attempts to create a profile without a valid legacy jurisdiction identifier When the form is submitted Then the save is rejected with a clear validation message identifying the required legacy link And no INSERT, UPDATE, or DELETE operations are performed on legacy Access tables at any point

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.10)
• 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-10-municipality-account-profile.md