#5 Story 1.5: Shared Audit Logging Infrastructure

Imported from [_bmad-output/implementation-artifacts/1-5-shared-audit-logging-infrastructure.md](https://onefortheroadgit.sytes.net/dcovington/Campaign_Tracker/src/branch/main/_bmad-output/implementation-artifacts/1-5-shared-audit-logging-infrastructure.md). # Story 1.5: Shared Audit Logging Infrastructure Status: ready-for-dev ## Story As a a system, I want all security-relevant and operational events captured by a shared logging service, so that audit history is uniformly available across all application features from day one without per-feature implementation. ## Acceptance Criteria 1. **Given** any security-relevant action occurs (auth event, permission check, privileged update) **When** the action completes **Then** the event is written to the audit log within 5 seconds including actor identity, timestamp (UTC), action type, resource identifier, and outcome (NFR7) 2. **Given** audit records are persisted **When** the retention policy is evaluated **Then** records are retained for at least 365 days and are not purgeable by standard application operations (NFR7) 3. **Given** any application feature calls the audit logging service **When** the call is made **Then** it succeeds using the shared service contract — the calling feature does not implement its own audit persistence 4. **Given** an audit record is written **When** retrieved for review **Then** it is append-only — no update or delete operations are available on audit records 5. **Given** the audit service is unavailable **When** an auditable action occurs **Then** the action is blocked or queued — auditable operations must not silently proceed without capture ## 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.5) - 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-5-shared-audit-logging-infrastructure.md`