Add notification preferences and admin governance

docs/FORWARD_PHASE_PLAN.md

@@ -599,6 +599,17 @@ Provider-protection rules:
 - Critical work-order events should remain visible in app even if email/push is off.
 - No modal begging for notifications.
 
+Implementation status:
+
+- Completed first implementation pass alongside Phase 13A.
+- Added notification preference editing on the notifications page.
+- Added channel intent controls for in-app, email, and future push without enabling email/push delivery prematurely.
+- Added category controls for matching jobs, quote updates, work-order activity, reviews/reputation, and disputes/moderation.
+- Added event-level controls for specific notification types.
+- Added digest preference and quiet-hours fields for future email/push delivery policy.
+- Added notification gating in `ExchangeEventNotification` so existing send paths respect user preferences.
+- Verified with Windows `php artisan test`.
+
 ## Phase 13 - Moderation, Admin Operations, And Audit Logs
 
 Purpose:
@@ -648,6 +659,17 @@ Provider-protection rules:
 - A buyer should not be able to silently damage a provider's reputation.
 - A provider should be able to see what changed and why.
 
+Implementation status:
+
+- Completed first implementation pass alongside Phase 12A.
+- Added reusable `audit_logs` for admin and operational actions.
+- Added audit writes for review reports/moderation, imported-history verification, attachment deletion, work-order transitions, change requests, contact events, quote acceptance, and mobile API actions.
+- Added reusable `moderation_reports` for provider profiles, buyer profiles, jobs, and attachments.
+- Added report forms to public profile, job, and attachment surfaces.
+- Expanded the admin console with open moderation reports and a recent audit log panel.
+- Added admin triage controls for moderation reports.
+- Verified with Windows `php artisan test`.
+
 ## Phase 14 - Deployment, Scaling, And Reliability Hardening
 
 Purpose:
@@ -729,10 +751,10 @@ Provider-protection rules:
 
 ## Recommended Immediate Sequence
 
-1. Phase 12A: notification preference UI and event-channel controls.
-2. Phase 13A: audit logs and moderation/operations queues.
-3. Phase 14A: deployment/scaling hardening.
-4. Phase 15A: UX polish and accessibility pass.
+1. Phase 14A: deployment/scaling hardening.
+2. Phase 15A: UX polish and accessibility pass.
+3. Future mobile/API expansion after native app requirements are clearer.
+4. Future email/push delivery implementation after the sender and push providers are explicitly selected.
 
 ## Key Design Commitments
 

docs/ROADMAP.md

@@ -26,6 +26,8 @@ Provider Exchange is a Laravel application for a provider-centered field-service
 - Peer-review disputes with comments, evidence, structured recommendations, and public vote breakdowns.
 - Universal community ratings for buyers, providers, job posts, work orders, and disputes.
 - Database notification events and notification inbox.
+- Notification preference UI with category controls, event-level gates, digest/quiet-hours settings, and stored email/push intent for future channels.
+- Admin governance with moderation reports for profiles/jobs/attachments, expanded moderation queues, and reusable audit logs.
 - Versioned Sanctum API surface for future app clients, including mobile-safe work-order actions, token ability checks, action audit records, and optional geolocation evidence.
 - Baseline API/security hardening with rate limiting and HTTP security headers.
 - MIT license and no-payment/no-rate-setting guardrails.
@@ -59,11 +61,11 @@ Provider Exchange is a Laravel application for a provider-centered field-service
 
 ## Phase Checkpoint
 
-Phases 1-11A have been implemented locally through mobile-safe API actions and baseline security hardening. The next active planning block is:
+Phases 1-13A have been implemented locally through notification preferences, moderation reporting, and audit logging. The next active planning block is:
 
-8. Notification preference UI and event-channel controls.
-9. Admin operations, audit logs, and moderation queues.
-10. Deployment/scaling hardening and UX/accessibility polish.
+8. Deployment/scaling hardening.
+9. UX/accessibility polish.
+10. Future email/push delivery and native-app API expansion once providers are selected.
 
 Work-order safeguards to carry into the next implementation passes:
 
@@ -145,6 +147,16 @@ Phase 11A mobile API and security hardening completed:
 - API routes are throttled through an explicit `api` rate limiter.
 - Application responses include baseline security headers: content-type sniffing protection, same-origin frame policy, strict origin referrer policy, limited permissions policy, and HSTS on secure requests.
 
+Phase 12A/13A notification and admin governance completed:
+
+- Notification settings now live on the notifications page with in-app, email intent, push intent, digest, quiet-hours, category, and event-level controls.
+- `ExchangeEventNotification` gates database notifications through user preferences while defaulting existing users to enabled.
+- Email and push settings are stored as explicit intent, but no email/push delivery is enabled until those providers are selected.
+- Users can report provider profiles, buyer profiles, jobs, and attachments for moderation.
+- Admins can triage moderation reports from the admin console.
+- Audit logs record selected operational and moderation events, including review moderation, imported-history verification, attachment deletion, work-order actions, quote acceptance, and mobile API actions.
+- Admins can review recent audit activity from the admin console.
+
 Available-work safeguards to carry into directory and job-list phases:
 
 - Available jobs should expose pay type, provider terms, schedule type, work type, rough location, buyer reliability, support/contact certification, scope clarity status, and request/quote count.